Hacker News new | past | comments | ask | show | jobs | submit login
WebKit.js: Pure JavaScript Port of WebKit (github.com)
157 points by bpierre on Jan 16, 2014 | hide | past | web | favorite | 89 comments



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)


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


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?


Yes


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.


Chrome's updates are signed with a reasonably trustworthy certificate.


No fan of NaCl?


I'm posting this comment from a ChromeBook Pixel...

I think this future is mega interesting, and I hope it comes to pass.


Isn't that sort of what Google did with ChromeOS inside Windows 8?


True, but, deployment.


An operating system that has more fundamental concept of "URI access" than "file system"; and which does zero-install of any application you type in the URL of, temporarily for as long as you visit the site, isn't really not a web browser, is it?


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 source code for web pages since there wouldn't be a working DOM inspector in your browser.


I think the idea would be that there would not be native font rendering or OS-provided services. All that would move up a layer.

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.


  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. Could be integrated into HTML5.js.

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


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.


> no right-clicking text selection to choose from a dozen OS-provided services

Ah well, this stuff is added into the browser engine already in Firefox OS.


So, your browser is reduced to a language interpreter and sandbox, executing a text based bytecode.

Kind of like the JVM?


Very exciting indeed. This is exactly what I wanted back in the day: http://alertdebugging.com/2011/09/22/the-promise-of-the-web/ (last paragraph).


"back in the day" 3 years ago? Are you 10 years old? <grin>



Excellent read, thank you.


You should check out Alan Kay's OOPSLA keynote "The Compute Revolution Hasn't Happened Yet" at http://www.youtube.com/watch?v=oKg1hTOQXoY specifically about 20 mintues in where he says that a browser should be exactly what you say here. On the one hand, he was talking about this almost 20 years ago, on the other hand you're in good company because he's a pretty smart guy!

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.


Have you checked out http://breach.cc/ and http://breach.github.io/exo_browser/ ?

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


Thanks Julien for sharing Breach. If anybody interested feel free to contact me (@spolu)!



What you propose there reminds me of Atlantis: http://research.microsoft.com/apps/pubs/default.aspx?id=1546... – James Mickens did a talk as well: http://www.youtube.com/watch?v=4c0DdOvH6lg

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.


I don't know about a WebGL API on node.js, but I'm currently updating a set of bindings for SDL to SDL2. (https://github.com/Freezerburn/node-sdl) Theoretically, you could use the same WebGL code, and add a few lines of code to open up a window, plus possibly some slightly different code for loading images, and re-use the rest of your logic on the client side. Change the code a little bit more, and it could optionally open a WebGL window in the DOM or an SDL2 window depending on the environment. Presto, you have a game which is easily portable. (not counting for oddities in drivers for different OSes)

Though that's all in theory. It could be a pie-in-the-sky ideal that doesn't exist yet.


Thank you for sharing that. That is a really interesting vision for the future of browsers.


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


For games, instead of ChromiumEmbedded I suggest "node-webkit" developed by Intel:

https://github.com/rogerwang/node-webkit


You should look at some reasearch done ny James Mickens: http://research.microsoft.com/apps/pubs/default.aspx?id=1546...

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.


Glad to see more people share this idea. Personally, I would go even further and separate JS as well, and make PNaCl the standard.


IE JS API would still be outdated.


You could probably reduce the browser to just WebGL + BSD Sockets JS APIs. Far less surface area for vendors to screw up.


So no sound, no storage, no access to peripherals (e.g. webcam, geolocation, accelerometer)... ?


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


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.


>1/2GB of source code?

WebKit's entire Source directory is 247MB, and more than 100MB of that is ChangeLog files.


There's Servo from the Mozilla team, written in Rust -- not a pure functional language but an interesting step. (Not that there are strong guarantees it'll be less complex overall, though it may have other properties like memory safety)


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.


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


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.


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.


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.


KDE is the community, not the toolkit. Most KDE specific widgets have been merged/replaced in Qt over time. KF5 mostly is a bunch of small libraries using Qt.

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.


"...any examples of "cleanly designed" systems that have "won" in the long run"

The Linux kernel comes to mind.


Does this count as "cleanly" designed in the way most software engineering types put it forward? I mean, it flat out went against what was seen as "cleanly designed" when it was created. And even now espouses a monolithic code base over the microkernel designs.

That is to say, in my mind it was one of the counter examples to the idealistic "cleanly designed" solutions.


Just another reason I found it strange that Opera dumped their browser engine for webkit. I suppose it might look even worse..


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


These concerns resonate a bit with Google's explanation for Blink. Really excited to see what comes out of that.


I'm a bit late to the party here, but figured I'd chime in with my own experiences. I spent a many days staring into WebKit and can honestly say that finding your way around does get easier. When you are searching for things, it helps to have a good base grasp of what IS, and what is NOT WebKit. Webkit is many, many things, but people make some common mistakes about what it is. Unfortunately, to get anything done with WebKit, it requires a huge amount of work, and platform specific implementations and support, which add the the general confusion.


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


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


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


I wrote a JS port of JavaScriptCore:

  eval


Doesn't pass JSLint, moving on...


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.


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


JS is getting out of hand!



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


You could probably turn Firefox into a NaCl app that would run inside Chrome.


Firefox cannot run chrome until they implement v8.js


Yeah. Maybe Safari?


until gecko.js


[ insert obligatory Atwood's Law quote here ]


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


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


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


If this browser-in-browser trend catches on, we can start measuring apps in units of meta-Atwoods!

(I wish I had a law and/or a unit named after me).


This is one very obvious instance I failed to anticipate though.


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.


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.


All in a 50KB js file.

1. Why?

2. How is this humanly possible?


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


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


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


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


50 MB is still pretty small


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


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.


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


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


I don't know, but I hate both




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: