Hacker News new | ask | show | jobs
by jacquesm 4047 days ago
Have an upvote, dissenting opinions should at least be legible.

That said, I really can't agree with you.

Browsers can re-compile their input into whatever intermediary format they desire subject to the usual space/speed trade-offs. By the looks of it (judging by the space they need) they use that trade-off rather liberally in the 'speed' direction and they still run quite slow. I just can't imagine that laying out some text and images in 2d (which I've done for limited contexts) is that much harder than rendering a 3D scene (in software, not using a bunch of GPU power to do the heavy lifting) (which I've done, but not recently and definitely not with this kind of detail, roughly at the level of the original 'Doom' with a slightly better lighting model and right around the time it came out).

Games may not have security issues in the input data that they consume when it comes to graphics and such, so that's a valid point but games do have to run on a wide variety of hardware and they typically adjust really gracefully.

The one thing I think that really differentiates game rendering engines from browsers is that game engines tend to model some physical process whereas browsers attempt to implement a massive spec to allow any server it chooses to contact to send it a bunch of bytes the rendering result of which is not known ahead of time so arguably the games people have a relatively limited possible space of outputs they can generate whereas browsers theoretically can display anything including that game.

That still doesn't excuse them for the crappy performance they deliver, that simply means we've moved too fast in adding layers before getting lower layers to perform adequately. The original web did not seem sluggish to me, it seemed about as fast as what you could expect from the hardware of the day, whereas the 'modern' web seems to be (to me) terribly slow and inefficient.

The ratio of content:markup+eye candy has deteriorated and I suspect that that is part of the answer here (and of course that would not be the browsers fault per-se).

2 comments

Notice that webapps using famo.us actually break that stereotype you described by using the GPU and a Physics engine.
The web doesn't deliver crappy performance, though--apps written by bad developers deliver crappy performance.

The complaints about the abstractions and everything honestly remind me of the complaints about Java, and look how that turned out over the same time period.

As for the engine vs. browser thing--you can totally render a DOM super efficiently if you are sure that it remains relatively static. That's very much, in fact, how the game engines do so well. They have the task of "throw as much as we can in triangle buffers onto the card, and occasionally draw with uniforms set to our desired transform matrices, and let the Z-buffer and pixel shaders sort it out."

By contrast, the DOM may have any number of properties twiddled at any time, and the layout engine is forced to deal with that. A random float or something could cause hundreds and thousands of nodes to reflow.

There is a cost to such flexibility, to be sure, but it's not inefficient for no good reason--the tradeoff was made to lower the entry to program it and to allow maximum malleability.

> By contrast, the DOM may have any number of properties twiddled at any time, and the layout engine is forced to deal with that. A random float or something could cause hundreds and thousands of nodes to reflow.

So the problem is that DOM is a bad abstraction for building GUIs, as it is necessarily inefficient.

Desktop apps have been more efficient than web apps forever. The reason is that desktop GUI toolkits were, y'know, actually designed to be GUI toolkits.

Inefficient != bad.

Frankly, I think that the design tools and document model for the web knocks the stuffing out of any native apps, especially if you are trying to make something work quickly or on multiple platforms. I'd take CSS over Qt any day.

Amen. It's like people think the existence of a facade undermines the merit of the underlying architecture. There is no "moving too fast". If you're looking for a curated set of panacea tech then get off the frontier and wait for it to be a class. The people designing what will eventually be its content need a place to iterate. If you're butthurt about the web dominating app distribution you can use emscripten and canvas or circumvent the web entirely and use steam. The highest level interfaces of the web aren't trying to be everything for everyone. They're just standardized solutions to common problems. Look at how lodash improved performance relative to native browser methods by implementing only a useful subset of their behavior. It's not all or nothing.
I don't care about application development personally (although I'm sad that the dominant programming environments are much worse than they were 20 years ago), but I do care about the performance of the applications that I use every day. When you consider what my browser actually does it uses a tremendous amount of resources. Computers are so fast but yet most applications feel slower than the ones I used on my 100MHz Pentium in the 90s. That's broken.
They were developed with significantly less effort than applications from the 90s. Many are just experiments someone published after mere hours of work. A large number of people exist who would trade performance for more content. That's not broken it's just a difference in preference. There are high performance webapps you can use, albeit fewer of them. That and higher performance apps if you don't mind waiting to download and install.

I'd love to have the dynamism of the web and the performance of native all on one platform. We're not there yet.

Computers are so fast but yet most applications feel slower than the ones I used on my 100MHz Pentium in the 90s. That's broken.

How many multiple-megabyte images could you display in 24-bit color at 1080p on that Pentium while scrolling? How good was the support for Unicode and non-English languages? How many streaming videos and ads could you see at one time? When you downloaded kilobytes of markup, and in turn request a dozen more things from a server on the other side of the planet, how long exactly did it take to parse and load? How many times did you chat with people and embed pictures in your conversation, while listening to streaming internet radio?

Hint: computers are actually doing quite a bit more in apps these days than they used to, and its only through the good luck of hiding this fact most of the time that you can make such silly complaints.

> The complaints about the abstractions and everything honestly remind me of the complaints about Java, and look how that turned out over the same time period.

I don't think that supports your argument that poor performance is the developers' fault.

Java got fast as its VM improved and it got JIT compilation.