
WebKit.js: Pure JavaScript Port of WebKit - bpierre
https://github.com/trevorlinton/webkit.js
======
TheMakeA
I 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 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)

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

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

~~~
angersock
This is different than Chrome or whatever autoupdating _how_ exactly?

~~~
neeee
It isn't that different, and I don't trust proprietary auto updating software
either.

------
sigil
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 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...](http://blogs.gnome.org/diegoe/2012/09/23/webkitgtk-failing-to-
build-argument-list-too-long/)

~~~
taeric
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?

~~~
azakai
> 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.

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

~~~
nostrademons
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.

~~~
taeric
I wasn't trying to imply any causality. Merely somewhat surprised that it
isn't better designed. We get into a fair number of arguments over "clean
design" at work. I have grown weary of all of the "cleanly designed partial
solutions" I have seen. Just as I've grown weary of complaints on how crappy a
system is and how it should all be done from scratch.

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.

------
rubiquity
I remember this being an April Fools' Day joke[0] in 2012. Interesting to see
it coming alive. I imagine it will be a pretty large file size so it might not
be practical for a little bit longer, especially for mobile devices.

0 - [http://badassjs.com/post/20294238453/webkit-js-yes-it-has-
fi...](http://badassjs.com/post/20294238453/webkit-js-yes-it-has-finally-
happened-browser)

~~~
devongovett
Yup, author of that post here. I was pretty surprised to see the vaporware of
2 years ago come alive this morning.
[http://badassjs.com/post/73526882798/webkit-js-its-
happening...](http://badassjs.com/post/73526882798/webkit-js-its-happening-
for-real-with-emscriptens)

~~~
egeozcan
I can't tell you how much I was disappointed to realize that it was a joke =)

------
dlubarov
I wrote a JS port of JavaScriptCore:

    
    
      eval

~~~
elwell
Doesn't pass JSLint, moving on...

------
SteroidsLove
Quick 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.

~~~
randallu
We're already half way there:
[http://kripken.github.io/clangor/demo.html](http://kripken.github.io/clangor/demo.html)
(Clang compiled by Emscripten).

~~~
JetSpiegel
JS is getting out of hand!

------
sathishmanohar
Now firefox can run chrome inside firefox, but chrome can't run firefox inside
chrome.

~~~
dikei
Firefox cannot run chrome until they implement v8.js

~~~
elwell
Yeah. Maybe Safari?

------
talles
[ insert obligatory Atwood's Law quote here ]

~~~
tlrobinson
[ insert obligatory tlrobinson's Law quote here ]

(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](https://twitter.com/tlrobinson/status/395636386671235072))

~~~
thatthatis
throw StopIteration; //For the love of god, please no more laws. I know it's
tempting to coin a law about tlrobinson being brought up whenever atwood's law
is brought up, but enough is enough already

~~~
Helianthus
[ insert obligatory thatthatis's recursive-reference-escape coining reference
here ]

------
msoad
I remember when Google forked Webkit and started Blink. They had a video
explaining why and how. I remember they said they might port DOM to JavaScript
if it makes sense. Apparently it doesn't make sense.

------
fidotron
This will eventually mean anyone engaged in getting data off the web for
machine processing (i.e. scraping) is probably looking at needing to run
headless browsers and using OCR to get the information out in future. I kind
of wonder if Google etc. do this already to extract information based on
layout.

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.

------
elwell
All in a 50KB js file.

1\. Why?

2\. How is this humanly possible?

~~~
eseehausen
It's 50MB. That probably revises #2. As for #1, isn't this a good thing in
itself?

~~~
elwell
Oh meant to write 50MB; doesn't revise #2.

~~~
mikeash
Looks like it uses Emscripten to convert from C++ to JS, so it's not really
humanly possible.

~~~
elwell
Ah, that's the answer to my questions then.

------
javajosh
Also excited about this: but it's also clearly a very ambitious project that
will need a lot of help.

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

------
jokoon
Everyone hates javascript ! Quick, let's all use javascript !

~~~
alan_cx
While I do get lost as to where the current hate is, is it not Java, rather
than javascript, which is currently hated?

~~~
jokoon
I don't know, but I hate both

