WebKit.js: Pure JavaScript Port of WebKit
github.com
github.com
I imagine a future where a "web browser" is just a WebGL + Networking + JS API, and you just load in HTML5.js. The benefit of something like this is that it puts the power back in the hands of the people. You don't have to worry about Microsoft ignoring standards, you just load in the HTML5.js that you know works. Want a new feature? Fork HTML5.js on GitHub.
One other benefit that interests me is for games. Games badly need a free, standardized way to do UI. Porting v8 + WebGL is far easier than porting an entire web browser. There's a chance for greater performance too, since frameworks like ChromiumEmbedded typically only provide a memory buffer of the rendered frame, which you then have to copy (back) to vram.
(reposted because the other thread was killed)
> The ExoBrowser is a scriptable platform designed to ease the experimentation with new concepts for the Web Browser.
> The ExoBrowser exposes its API (parts of the Chromium Content API + a Simple View Model) in Javascript and enables the implementation of a fully functional browser entirely out of it (as a Javascript/HTML/CSS app)
I imagine a future where an "operating system" is just a OpenGL + Networking + JS API, and you just load in HTML5.exe. The benefit of something like this is that it puts the power back in the hands of the people. You don't have to worry about Google and Apple restricting what you can do, you just load in the HTML5.exe that you know works. Want a new feature? Fork Firefox on GitHub.
(I don't want to belittle the technical achievement here - it sounds pretty cool! But I can't help but wonder wheter using the CLR or the Java VM wouldn't be better for many use cases, or even plain x86 machine code with virtualization.)
I think this future is mega interesting, and I hope it comes to pass.
I encourage all developers to watch that talk and do some thinking about the current state of our practice and where we want to go from here.
Though that's all in theory. It could be a pie-in-the-sky ideal that doesn't exist yet.
Kind of like the JVM?
It would also make it much more difficult to peek at the source code for web pages since there wouldn't be a working DOM inspector in your browser.
No native font rendering
no right-clicking text selection to choose from a dozen OS-provided services, no user-based keyboard shortcuts in text fields like this comment field, and so on.
there wouldn't be a working DOM inspector in your browser
There would be differences for sure, but I think the benefits would outweigh the downsides.
[0] http://research.microsoft.com/en-us/um/people/cloop/LoopBlin...
It's like the ultimate "solution" to all those useless anti-view-source javascript efforts.
(Imagine this taken to the extreme - encrypted home-grown markup and stylesheet languages that barely resembles html anymore.)
Also, accessibility would take a major hit.
Also, a huge amount of web sites will never update their html5.js.
Sounds like the anti-web.
Ah well, this stuff is added into the browser engine already in Firefox OS.
Yes, that would give a lot of flexibility. Usability would suffer, though. It would be like the old (1) times of X Windows, where there were zillions (read: > 1) ways to handle a clipboard, multiple conventions for the format of the data on the clipboard, where one application could find your TrueType fonts, while another couldn't, etc.
(1) some people will feel I'm being polite here. Maybe I am, but that is something for another discussion, and I know too little about modern X applications to contribute there.
Basically they reduce the browser to a VM where everything except a few core things run in the page's context (including the protocol implementations, layout and scripting) which enables a few nice things.
Hmm... I'm not sure the solution for standards is having more of them.
http://www.slideserve.com/illias/atlantis-robust-extensible-...
Of course this is not something that is going to be useable anytime soon, but it hints at an interesting architecture.
First off, man is it huge. There's a link stage that uses ~4GB of memory. The command line for that link is so long I needed a patched version of make [1]. Why the WebKit devs haven't knuckled under the pain and broken out multiple smaller libraries is beyond me. They must be tough.
Second off, if you dive into the code -- say you're looking to change something about the layout algorithm -- you quickly discover that there is no layout algorithm. Or at least, no one place that articulates the algorithm, which is instead spread like pixie dust over dozens of objects. Each one contributes a little bit of the logic. (You're in a twisty maze of classes, all alike...)
Perhaps some of this is a reasonable separation of concerns that helps the whole thing scale. But it made me step back and wonder if we're approaching these kinds of problems right, architecturally. Does WebKit really need so much code? If we could go back and write a browser in a functional language, what would that look like? Would performance necessarily doom it from the start?
[1] http://blogs.gnome.org/diegoe/2012/09/23/webkitgtk-failing-t...
Anyone have any good pointers on an analysis of the code base? Any easy way to just "dive in" to the code other than the obvious checkout and look around?
Sadly being widespread is no guarantee of clean design ;)
WebKit, like other browser engines, was originally designed in the 90's, and evolved over a long period of time. Again like the others, it's a large and complex C++ codebase, with all the good and bad that comes with that.
WebKit does have some advantages over other browser engines though, specifically it is the most embeddable, and I would say that is the main reason for its being widespread today.
I still harbour feelings that something in the discipline of webkit offers lessons. I just don't know if I can see it myself. Outside of the lessons of brute force being a good tool. (Where I'm assuming there is a lot of force behind webkit.) (I do understand that they have a lot of tests that are fairly complex. Mayhap that is the true lesson. Get a good handle on how to run complicated test cases.)
http://dot.kde.org/sites/dot.kde.org/files/kf5_big_0.png
Qt is also used by a few "big" software and as the default toolkit for BB10, Jolla and Mer (totaling a nice 1% market share ;) ). It is also seen as the successor to Motif for large scientific applications.
The problem occurs because this process continues until the equilibrium point is reached, where it is no longer economical to add features to the software. Given the high usage and low marginal cost of software, this is usually when the software has become so inscrutable that nobody knows how to modify it anymore, at which point it is replaced by something else.
It isn't even that I disagree. Just that "everything is terrible" is not a recipe for a happy day for me. For the most part, everything is bloody awesome. The details just aren't as clean as some would have hoped.
The Linux kernel comes to mind.
That is to say, in my mind it was one of the counter examples to the idealistic "cleanly designed" solutions.
A good build system/toolchain with GYP that generates Xcode, VS C++, and ninja project files. That would be mega awesome. QtWebkit already has some gyp files, probably could repurpose those.
Also, you can read up on embind on emscripten's website, you can use c++filterjs and the derived object WebCore.exp on the build to create javascript API's from the C++ export symbol table.
I just need to actually have a few days free to finish that and hopefully can have SOME functional demos from the API (that and hopefully I can throw away 90% of the symbols being exposed in the current version and cut the code size down :/)
There really isn't a layout algorithm but it does seem like overtime they began to contain it as to make it not platform dependent (thank god).
I think that the major achievement of webkit wasn't in the code they took from KHTML ;) but in the unit tests that were created and the robust amounts of work that went in to focus on making things pixel perfect. Prior to webkit a margin meant whatever the hell the damn implementers felt like. If it worked at all.
I should say much of the code in WebKit is no-mans-land, or essentially greatest common denominator work to make webkit portable to multiple architectures. That's why the linking takes so long and you can go from >1/2 GB of source code, 4GB of linker memory down to a 20MB object file.
WebKit's entire Source directory is 247MB, and more than 100MB of that is ChangeLog files.
0 - http://badassjs.com/post/20294238453/webkit-js-yes-it-has-fi...
evalfor the win!
(tlrobinson's Law: any submission to Hacker News about a novel JavaScript program will contain a comment referencing Atwood's Law. https://twitter.com/tlrobinson/status/395636386671235072)
(I wish I had a law and/or a unit named after me).
Somewhere along the way we need a better way to exchange data between websites before this comes along and sets us back by a couple of decades. The semantic web stuff (sadly) hasn't really worked, but something of that ilk is needed to get us to the future.
1. Why?
2. How is this humanly possible?