[drzaiusapelord]

Why is this pissing away performance? A web browser isn't some luxury. It affords them flexibility with ease of development and being compatible with the entire www. I really don't see the old days of proprietary junky interfaces being superior, especially on hardware that is close to what a modern desktop PC is today.

Not to mention, my crappy phone runs Chrome. If it can do that, certainly a device that uses up to 100 watts, has 16x the ram, 100x the graphics/cpu can too without it being considered a drain.

[kllrnohj]

I never said anything about performance? I specifically mentioned RAM. Although it is pissing away performance because WebGL is slower than running GLES directly, thanks to the sanitation of the GLES shaders that the browser does.

But this is still a proprietary, "junky" interface. If it's WebGL, it's still entirely custom, with entirely custom event handling, and entirely custom accessibility (or lack thereof), and entirely custom everything. If you are just using WebGL, which is what they said, then the browser is a massive chunk of dead weight that's doing jack shit. All the browser did is setup the EGL context, create a GLES context from that, and then handed it to you. This is basic hello world stuff, that's the entirety of the browser's involvement in this scenario.

[bri3d]

The G+ comments seem to indicate that they're using the browser's event handling in some way.

Plus the browser runtime still gives you things even if you're going the pure-GL UI route: networking, a JSON parser, a database (Local Storage), cookies and session management, a (arguably awful) security model... how is the browser "dead weight"?

[kllrnohj]

All those things are easily provided by libraries for every language with every API imaginable. The strength of a browser is HTML & CSS.

And I called it dead weight because we're talking client-side offline UI here, so things like cookies and session management are irrelevant. But the dead weight is going to come from the bulk of the browser code that is HTML/CSS parsing, webkit/blink, the graphics model that's not being used, font support that's not being used, etc... Those things you list are all really small pieces.

[bri3d]

I strongly suspect the PS4's UI is neither truly client-side nor offline.

I don't disagree that there's a lot wasted but I'd probably have made the same trade-off given the circumstances.

The PS4's UI isn't particularly resource-constrained as far as I know and it's often easier to start with a familiar environment with everything and the kitchen sink than to start with nothing and hand-pick blocks along the way. Plus based on Sony's past in-house UI performance, the "glue libraries together from floor 0" approach wasn't working out for them.

So far the PS4's UI is getting good reviews and is generally described as "responsive" so it sounds like they didn't really lose - in a modern device where you'll end up porting a browser anyway I don't see why using it for UI is such a sin.

[anonymouz]

> I really don't see the old days of proprietary junky interfaces being superior, especially on hardware that is close to what a modern desktop PC is today.

As a cynic, I would say web apps are all about proprietary junky interfaces instead of using my platforms standard GUI. Reminds me a bit of the VB6 days where every program used to define its own true button color... (except the modern web apps look a lot nicer, of course).