Live data from Hacker News

WebKit.js: Pure JavaScript Port of WebKit

github.com

71–80 of 96 posts

Re: WebKit.js: Pure JavaScript Port of WebKit

#71
post #70
post #67

Earlier quoted context omitted.

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. WebKi…

This further hits my curiosity on whether or not there are any examples of "cleanly designed" systems that have "won" in the long run. Am I just growing cynical?

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.)

Re: WebKit.js: Pure JavaScript Port of WebKit

#72
post #71
post #70

Earlier quoted context omitted.

> 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. WebKi…

This further hits my curiosity on whether or not there are any examples of "cleanly designed" systems that have "won" in the long run. Am I just growing cynical? 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 understan…

I would point out Qt as a very well and cleanly designed project that "won" as in it's one of the if not the top GUI frameworks out there.

http://qt-project.org/

Re: WebKit.js: Pure JavaScript Port of WebKit

#75
post #66

Wow. 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…

The link stage is pretty huge. It currently won't compile with emscripten with debug symbols, in-fact the entire obj-pre-link stage is 8.9GB of "bytecode".

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.

Re: WebKit.js: Pure JavaScript Port of WebKit

#76
post #67
post #66

Wow. 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?

There's two next steps:

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 :/)

Re: WebKit.js: Pure JavaScript Port of WebKit

#77
post #71

Earlier quoted context omitted.

This further hits my curiosity on whether or not there are any examples of "cleanly designed" systems that have "won" in the long run. Am I just growing cynical? 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 understan…

I would point out Qt as a very well and cleanly designed project that "won" as in it's one of the if not the top GUI frameworks out there. http://qt-project.org/

Is it actually all that widespread if you consider the full set of all apps on all platforms? The impression I get is that the majority of apps don't use any cross-platform GUI framework and instead use the native API of the platform - Win32 for pre-XP Windows, .NET for Vista+ Windows, Cocoa for Macintosh, GTK or KDE for Linux, HTML/CSS/JS for the Web, native Android for Android, native iOS for iOS, etc.

Re: WebKit.js: Pure JavaScript Port of WebKit

#78
post #71
post #70

Earlier quoted context omitted.

> 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. WebKi…

This further hits my curiosity on whether or not there are any examples of "cleanly designed" systems that have "won" in the long run. Am I just growing cynical? 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 understan…

I think the causation runs the other way. When something becomes popular, there's pressure to improve it (or, arguably, "improve" it). That leads to more features, which leads to more code, which leads to a messier, more complicated codebase. This is all good for users - it takes complexity out of the usage of a feature and puts it inside the software, where it belongs.

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.

Re: WebKit.js: Pure JavaScript Port of WebKit

#79

Earlier quoted context omitted.

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.

seconded. this stuff is my bread and butter yet I often think, this is the best we can do?

Re: WebKit.js: Pure JavaScript Port of WebKit

#80
post #31

Earlier quoted context omitted.

Arbitrarily running x86 machine code fetched over the net? Pass.

This is different than Chrome or whatever autoupdating how exactly?

It isn't that different, and I don't trust proprietary auto updating software either.
Post reply on HN