Is it really a good idea to link to a 47MB raw JS file hosted on github's server so most visitors to the blog post will click through without any actual interest? Seems a bit rude (and a great way to hang a browser/tab for a minute or two.)
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.
5 comments
[ 0.21 ms ] story [ 31.5 ms ] threadIf you want to communicate the size of the output, link to the github summary: https://github.com/trevorlinton/webkit.js/blob/master/WebKit...
But could anyone summarize the real interest of such a project? I really cannot see it.
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.