Comment by andrepd | Hacker News Reader

Comment by andrepd | Hacker News Reader

Parent Full thread

About your last paragraph, I would say that that is even more important to optimize and to make low level layers for than graphical game engines (believe it or not :)).

The thing is while gaming is seen as a "performance critical" application, where it is natural to want the maximum performance to be squeezed out of your hardware, Web development is just a behemoth of inefficiency, and we think that that is the norm, an inevitable drawback of developing for the web, an inescapable trait of web applications. Web apps are dozens or even hundreds of times slower than native applications, and we think nothing of it, because it seems to be an inherent characteristic of the web about which we can't do anything.

Your comment made me reconsider that. Maybe it doesn't have to be so. What if there was a Vulkan for the web, instead of the layers upon layers of inefficiency which are all the rage these days? What if I could run a medium complexity web page or app without it bogging my computer several times harder than a comparable native app?

Maybe you're optimizing for the wrong thing?

Let's imagine a world where a browser is just a secure place to execute code. You get vulkan, io, networking, input, camera access in a cross platform way.

So, how do search engines find any info? How do you share links to content? How do you support braille readers? Browser extensions?

I'd argue those things are pretty essential to the web as we know it (well maybe not the extensions) and I might also argue that some of the inefficiencies of the web environment are a direct result of making the decisions that the most important part of the web is a common semi scannable and linkable format, HTML.

The web these days is very clearly diverging into two separate things: a portable application runtime/platform, and the document publishing system it started as. I don't see any way to accomplish a clean split between the two, but it looks increasingly necessary.

The split you speak of has already happened on mobile, that's why we have "apps."

The new medium has been born, but the old one is still being abused, so the split isn't complete and won't be until this no longer happens: http://xkcd.com/1174/

The worst is LinkedIn, which will send you an e-mail with article links it it, and if you click the links it takes you to your browser, which does the thing that xkcd comic describes if you don't have the app installed, but if you do have the app it just launches the app and leaves you at the home screen, and the context of the link you clicked on is gone.

I'm wondering about the "can't zoom" bit. I can't zoom on many websites - because Mobile Safari has sold out control to the web developers, instead of acting as my user agent.

Disabled zoom is one of my pet peeves too. I use this bookmarklet on my iPhone, you may find it useful...

  javascript:document.querySelector('meta%5Bname=viewport%5D').setAttribute('content','width=device-width,initial-scale=1.0,maximum-scale=10.0,user-scalable=1');

Thanks!

> So, how do search engines find any info?

Desktop integrated search.

> How do you share links to content?

Extensions, contracts and intents.

> How do you support braille readers?

OS Accessibility APIs

> Browser extensions?

Plugins

Hi, I'm working on a library to allow something like this (rendering web UI's with a WebGL backend).

It's in very early stages. Feedback is very welcome:

https://github.com/davedx/lustro

Good luck. Efficient 2D using OpenGL is very difficult. It will never approach the speed of a well designed 2D API. Microsoft gave a lot of insight about the hard it was to get Direct2D to be competitive with GDI/GDI+.

If you do see any performance benefits it likely will be because you support less features than what a modern day browser supports with HTML/CSS. But in my opinion you could probably achieve faster speeds with Canvas in a similar manner.

> Efficient 2D using OpenGL is very difficult.

It depends on what you are doing. Rendering thousands of sprites with independent rotation and scale is easy. Rendering text is a lot of work, but once you do it you can do all sorts of things with the text. Rendering simple things like bezier curves is very difficult. There are some things in the 2D world that HTML/CSS/GDI/GDI+ are very bad at, compared to OpenGL, and vice versa.

Efficient 2D using OpenGL is very difficult. It will never approach the speed of a well designed 2D API.

All web content on OS X and iOS is rendered using OpenGL. That's not to say it was easy to make efficient, but it definitely outperforms the default CoreGraphics implementation on most content.

I agree it will be very difficult. I'm working with WebGL as my day gig and understand how hard it is, as we're working with embedded devices there. That's actually what motivated me to start this project, so web developers can build fast, rich and interactive UI's on the same level as those you see in current generation video game consoles.

You have to be ambitious, right? :)

(How) do you intend to handle accessibility?

I don't. The target segment is people building rich, interactive video-game-like UI's, for things like mobile/embedded devices.

Though as an aside, I think voice control is very underutilized in modern GUI development...

Please don't. It sounds like you're recreating flash and we all know how annoying flash guis were.

Sounds like the guy is doing entertainment systems where a gamey UI is fine. You don't want your car entertainment system looking like bootstrap.

I hope it works out well. A whole new class of apps and performance might become real.

I just wonder how well text performance will be. Would be awesome to get near native speed with editors like Brackets and Atom.

Yes, text is a big challenge. Got to get maximum efficiency from your sprite batching and triangle strips!

Write your whole webapp in WebGL?

Edit: Seriously, how feasible is that? Creating a GUI framework on top of WebGL and creating an abstraction layer (which the original article advises against) would be a huge performance boost comparing to current webpages, wouldn't it?

It's definitely feasible! A goal for my side project is to give developers a React-like declarative UI with a WebGL rendering backend that abstracts away the graphics programming.

Except that it would all still be done via a layer of javascript (using asm.js may mitigate this)

Native JavaScript performance is not generally what makes web apps slow.

Just because it isn't the bottleneck today doesn't mean it isn't slow.

Someone did this with their WebGL Terrain demo [0]. You can find a detailed post-mortem in the author's blog [1].

[0] http://zephyrosanemos.com/windstorm/current/live-demo.html

[1] http://zephyrosanemos.com/

To be fair, I think the takeaway isn't don't make/use abstraction layers, but don't make a one-size-fits-all abstraction and then hide the lower level stuff. A targeted abstraction that correctly supports the domain you are in is still a good thing. That's what the engine developers end up being here, an abstraction on top of this low level API that gives many devs exactly what they want.

Edit: To be clear, I don't think writing a web rendering engine meant to do the same think as the browser on top of WebGL will be faster in any respect, as really the HTML and CSS are just inputs fed into super optimized low level rendering engines. I don't see how JS could compete in that domain.

Reminds me of MIT's Exokernel- make the lower level interfaces as low-level as possible (while still providing security) and let user-level libraries provide various abstractions suited to different use cases.

No file systems, no network protocols, no processes; just a very thin layer that lets userspace implement those if/how it wants to.

Parts of CSS3 are already faster to implement "by hand" in javascript rather than using the browser's "native" implementation.

HTML/CSS was designed for requirements that don't apply to many modern websites. I would not be surprised if it were possible to implement a rendering engine that performed better for relevant use cases, e.g. perhaps assuming a grid as a first-class part of the layout.

Take a look at what Flipboard did recently, with their whole mobile site built in JS and canvas

http://engineering.flipboard.com/2015/02/mobile-web/

WebGL should never have been invented, at least on current architectures. It's a ticking bomb, precisely for the reasons this articles explored - drivers are complex and buggy black boxes that lie in kernel space so ring 0 access is never too far from reach for many exploits. WebGL has a potential to be exploit vector much more severe than what we've seen with other auxiliary web technologies like JavaScript or Java applets. Why not confine web to (mostly) nicely behaved x86 VMs?

Personally I think browsers will become service layers that expose the underlying OS in controlled and specific ways. Not a completely sandbox, but not a free for all either.

We've started creeping that way with a lot of the newer HTML5 stuff, but we have a long way to go.

Looking at the bug bounty record from Chrome and Mozilla it seems that fuzzing-for-bounties vulnerability research has largely moved away from WebGL. Must be at least partly due to WebGL reaching a reasonable level of robustness. Bounties may be harder to claim since bugs can be hardware/os/driver ver etc dependent, but still there used to be a lot more WebGL bounties dealt out.

Wouldn't that kill accessibility, selectable text, being able to call system services (i.e., on OS X hitting cmd+shift+D to get a dictionary definition of a word), any extensions which modify the page hierarchy, automatic translation/localisation, and so on.

Exactly; bypass this entire service layer maintained by thousands of engineers and try to do it in Javascript?! I think that's probably not a good idea.

Isn't Google's Native Client the Vulkan of the web? Or rather wasn't it, given adoption outside of Chrome is unlikely to ever happen.

http://www.zerovm.org/

yup. i have started to see the same as well. having a simpler web solution is hard to achieve, over the time, it get messier and messier. i'm now doing small and simple examples in newer language such as go to see if it is any easier there to keep software simple to 1)run 2)maintain 3) code.

Reply on news.ycombinator.com