This contempt is misplaced. It is obviously better in one sense to generate an animation on the fly using a short program instead of encoded its literal pixels in a much larger amount of data even after compression.
The ecosystem has largely moved towards that abstraction because it scales better for virtually every purpose, particularly for rendering in different formats.
Now web developers are brought up inside the abstraction and so don't even think to go outside of it by default. Which would be fine, except that the abstraction isn't designed very well: the browser is massively underpowered at building applications in an foolproof way. Part of that is historical cruft and part of it is (imo) a lack of vision--there should have been a (not-backwards-compatible) replacement for html/js/css years ago which solves its fundamental abstraction problems.
But anyway the present is still much better than the past. You must be nostalgic for the era when all monitors were the same size and websites weren't expected to do anything without reloading the page.
The problem is that everyone (browsers + developers) need to agree on a replacement, which is notoriously hard to do. Chrome got laughed out of the room with Dart/Flutter.
Well they don't really. What ought to happen is someone just makes a new browser (or adds support in an existing browser) unilaterally on an experimental basis. If it's good enough I imagine it would catch on. The limiting factor is presumably that that's a lot of investment for an experiment, but getting anyone else on board without a successful experiment is going to be impossible. (well, also, you have to have a good enough plan to be worth switching. I don't think dart/flutter was that.)
A nice starting place would be if one of the major browsers added an easy to use extension point for swapping out languages. (at least I'm not aware of this existing, nor that I've looked)
> A nice starting place would be if one of the major browsers added an easy to use extension point for swapping out languages. (at least I'm not aware of this existing, nor that I've looked)
What would that actually mean in practice that would be different from how Dartium did it?
Well I don't know how dartium did it really, but it seems to me like "add a new website implementation language to Chromium" would be a tutorial on Chrome/Chromium's home page.
Such that one could throw together, I dunno, news.ycombinator.com/index.z and see if they can do a better job than HTML/CSS.
As far as the actual solution to try for, table stakes is a native implementation of something that looks like React (but presumably reimagined from scratch).
> Such that one could throw together, I dunno, news.ycombinator.com/index.z and see if they can do a better job than HTML/CSS.
What would be the use of that? It would help people who want to make prototypes of a different web with no hope of it ever getting adopted, but that's not a huge market.
> table stakes is a native implementation of something that looks like React (but presumably reimagined from scratch)
Like a component layer? Browsers have tried with e.g. XUL or WebComponents, how would you avoid the problems of those?
So people can experiment with it. Creating a good place to experiment is the best way to make lots of good ideas happen. If 10000s of people can play with ideas instead of the 10 groups with enough time and energy and expertise, you get a much richer exploration of the space. Heck if it was easy I'd be doing it right now.
> Like a component layer?
I'm not aware of anyone creating a component layer that is even passable for abstraction compared to React's programming paradigm. Usually because they stay imperative-first when all signs seem to point to declarative-first being the more scalable model.
> how would you avoid the problems of those?
Umm... they're terrible, so I would just not copy them? Look at XUL for seconds and try not to vomit. WebComponents adds abstraction of HTML in Javascript, rather than in HTML / declaratively, which is obviously never going to work as a foundational technology. It is far too imperative-first. I would start by copying React... but then doing everything differently because most of React's design is forced by being implemented in JS and having to work around CSS being quirky. The greenfield version would do a much better job.
Dart/Flutter was never a technical issue, but a political/monopolistic issue. The underlying monopoly has not changed, so I don't really see a path forward unless the chromium team magically changes leadership.
I guess my point is, if the big Chromium team couldn't pull something like this off, who else would? At this point major web updates tend to get born in one of the big tech companies funding web development, either directly or indirectly (Mozilla being funded by Google)
I personally don't think dart/flutter was good enough of a solution to be worth everyone's time. When this actually happens it will be more of a paradigm shift than that.
That's why (which I said in the other comment) what needs to happen is that innovating in this space needs to become a lot easier.
The ecosystem has largely moved towards that abstraction because it scales better for virtually every purpose, particularly for rendering in different formats.
Now web developers are brought up inside the abstraction and so don't even think to go outside of it by default. Which would be fine, except that the abstraction isn't designed very well: the browser is massively underpowered at building applications in an foolproof way. Part of that is historical cruft and part of it is (imo) a lack of vision--there should have been a (not-backwards-compatible) replacement for html/js/css years ago which solves its fundamental abstraction problems.
But anyway the present is still much better than the past. You must be nostalgic for the era when all monitors were the same size and websites weren't expected to do anything without reloading the page.