Hacker News new | ask | show | jobs
by roca 2321 days ago
> tiled dynamically-loading images, as in maps applications. That should be a tag, and... that's all. Just a tag.

You say that, and then you disprove your point by going on to list a bunch of extra features that that tag would have to have. And even with those features, major map sites wouldn't use it because they render map content client-side using vectors, not map tile images, and have lots of other features your tag wouldn't support.

Implementing your vision would mean a massive increase in the API surface of browsers, with concomitant increase in browser bloat, and browser and standards development effort ... while there's a strong argument that browsers are already too complicated.

Even so, when we've tried to implement declarative features on the Web we've seen over and over again that it's impossible to satisfy everyone's needs without scripting. (See e.g. HTML5 form validation, SVG vs canvas, VRML vs WebGL, ...) That is why stuff like the Extensible Web Manifesto emerged.

1 comments

I’m pretty sure CSS, JavaScript, and the way both interact with each other and with HTML are the main reasons writing a useful browser engine is rapidly becoming impossible—and we’ll end up replacing it with Wasm rendering to a canvas for most things while not cleaning up HTML to be something simpler and delightfully less-capable, sadly. I think you could significantly increase the richness of just HTML without making it, per se, 1/10 the challenge of implementing all of those together.
The interactions between JS, CSS and HTML are not the main problem. The main problems are:

Feature interaction complexity between CSS features is a huge problem. Some of that could have been avoided if CSS had been designed differently, but some of it seems unavoidable (e.g. laying out text with mixed directions, mixed writing modes, ruby, font substitution, modern font features, etc etc --- at speed --- is just really complex).

Modern high-performance JS is really complicated to implement.

The plethora of APIs exposed to JS --- WebXYZ --- is incredibly complicated.

HTML is pretty complicated, e.g. HTML forms.

But if you take away JS, CSS/HTML don't get a whole lot easier, assuming you're still supporting interaction in some way. I mean, for your proposed map API, if the user can manipulate the functionality and you have lots of features that can be customized declaratively, it's not much more complicated to expose those controls to JS.

If you can simplify the problem so that CSS and HTML don't need to support incremental relayout/DOM changes, that would help a lot, but removing JS isn't enough for that. Things like zooming, window resizing, incremental loading, and any kind of editing put a lot of the same requirements on the engine.