Hacker News Reader

Comment by TheMakeA | Hacker News Reader

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)

View on HN

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>

http://en.wikipedia.org/wiki/Internet_time

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

Check out the Embassies project: http://research.microsoft.com/en-us/projects/embassies/

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

Reply on news.ycombinator.com