Do you know of any independent rendering engines? That's something I'd truly be interested in seeing. It seems like a herculean task to undertake.
Edit: Thanks very much for the links. This will be a lot of fun testing out. Just responding here to avoid triggering the anti-flamewar protection.
Re:Ōryōki Web Browser
by vertex-four on Wednesday June 29, 2016 @03:46PM
(#12004248)
Depends on what you mean by independent. If you just mean not any of the big three and their derivatives, you've got Servo[0], although that's still a herculean effort with direct support from Mozilla in terms of paying people to work on it. On the other end of the spectrum, you've got things like Dillo[1], which don't support much modern HTML/CSS/scripting, but do seem to get on by with far less effort.
These days it seems most pages are more JS and CSS than HTML...
Well, you know how long you've been hearing about Servo, and how it still, to a first approximation, can't render the web? Yeah, they're also bringing up Rust next to it, but... yeah, that's how long it takes.
It wasn't easy ten years ago, and a modern browser is at least an order of magnitude more complicated (WebGL, more complicated CSS, JS support, heck I'm not even really counting JS JIT here...).
Re:Ōryōki Web Browser
by fiddlerwoaroof on Wednesday June 29, 2016 @04:09PM
(#12004419)
Not really maintained recently, but there is:
There is Cocktail written Haxe (can compile to C++):
Microsoft uses its own EdgeHTML in the new "Edge" IE
I wish they'd open source EdgeHTML. I suspect it's far lighter than Gecko or WebKit, given that its development basically started with “let's rip out half of Trident”.
It probably only compiles on Windows, though.
There's h-smile (commercial) from Terra Informatica, that's used by a lot of antivirus vendors to implement desktop GUI software in HTML. The latest commercial branding for it is called Sciter.
Re:Ōryōki Web Browser
by vermontdevil on Wednesday June 29, 2016 @03:57PM
(#12004330)
uzbl, the one I've used the most, primarily consists of a pile of code to map callbacks to a protocol on stdin/stdout, and a handful of example scripts to communicate over that protocol - it's certainly no more "from scratch" or smaller than any other WebKit-based browser.
I expect that the other two similarly focus on UI code rather than pointlessly fiddling with WebKitGTK+'s internals - how are they not just skins (albeit of WebKitGTK+, not Chromium) as well?