holy mother of pearl this is the disruption I've been waiting for on the javscript front. I'd love to contribute but I'm not talented on how to implement the unsupported features.
WebKit.js: Pure JavaScript Port of WebKit
61–70 of 96 posts
Re: WebKit.js: Pure JavaScript Port of WebKit
#62Earlier quoted context omitted.
Leaving HTML5 rendering implementation up to each website, while only providing a "dumb" 2d or 3d pipeline (webgl), would make for a terrible non-native browsing experience. 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. It would also make it much more difficult to peek at the s…
No native font rendering True, but you can render some pretty good looking fonts[0]. 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. Could be part of a JS api exposed and used by HTML5.js. there wouldn't be a working DOM inspector in your browser FireBug, and the Chrome Dev Tools are written in HTML. Coul…
That's assuming everyone is on the official html5.js branch. Seems like it would be pretty easy for a million variants to be developed with all kinds of quick one-off hacks, that would make an off-the-shelf DOM inspector incompatible.
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.
Re: WebKit.js: Pure JavaScript Port of WebKit
#63Re: WebKit.js: Pure JavaScript Port of WebKit
#64Re: WebKit.js: Pure JavaScript Port of WebKit
#65I may be the only one excited about this, but I think it's awesome. 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…
> 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.
Hmm... I'm not sure the solution for standards is having more of them.
Re: WebKit.js: Pure JavaScript Port of WebKit
#66Wow. Good luck there. For the last year or so I've had the distinct pleasure of patching and building WebKit for a project. Some observations about the WebKit codebase...
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...
Re: WebKit.js: Pure JavaScript Port of WebKit
#67Wow. Good luck there. For the last year or so I've had the distinct pleasure of patching and building WebKit for a project. Some observations about the WebKit codebase... 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…
This actually surprises me some. With how widespread the use of webkit is, I would have thought it was among the more cleanly designed pieces of software out there.
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?
Re: WebKit.js: Pure JavaScript Port of WebKit
#68Quick someone make Emscripten.js! Emscripten compiled down to JS. A js web-app that takes C code as an input and creates JS code out of it.
Re: WebKit.js: Pure JavaScript Port of WebKit
#69I may be the only one excited about this, but I think it's awesome. 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…
Yeah, but 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 belittl…
i really hope i'm not just part of a distinct few, that think html, and js are not the future at all, but some old junk, that is unnecessarily being blown up out of proportions, just because at the time the wasn't anything better as an alternative.
Re: WebKit.js: Pure JavaScript Port of WebKit
#70Wow. Good luck there. For the last year or so I've had the distinct pleasure of patching and building WebKit for a project. Some observations about the WebKit codebase... 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…
This actually surprises me some. With how widespread the use of webkit is, I would have thought it was among the more cleanly designed pieces of software out there. 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?
> With how widespread the use of webkit is, I would have thought it was among the more cleanly designed pieces of software out there.
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.