> What I'm curious is why the platforms don't adapt to how the developers have found works best?
Here's my take:
- The web was visualized as a way to publish academic documents in a hyperlinked document system. Librarians and academics live in this world. We hear the word "semantic" from them a lot.
- The visual web was visualized as a way to publish documents that had a precise look. Graphic designers live in this world. They don't care about semantics. They do care about pixel perfect layouts and cool effects.
- The web app was visualized as a way to deliver software to users with lazy, "click link to install"-like behavior. What this crowd cares about is providing server functionality to users, and other concerns like semantics or pixel perfect are often secondary.
- The single page web app is also visualized as as a way to deliver software to users with lazy, "click link to install"-like behavior. They differ from the web app group in that they try to have more server functionality right in the client. Again semantics and pixel perfect are secondary. App complexity is a big problem that this group contends with, and this is what the article discusses.
Given these different ways of visualizing the web (and I'm sure I've left a few out), it's no wonder that we're stuck with the mess that is today's web development. The right solution is a sensible runtime for app development, that doesn't force you to render UI through the DOM and doesn't make it hard for you to get access to basic things like the local file system. We've known this forever (anyone remember Flash?).
WASM feels like it might finally allow app developers to do all of the software things that native platform developers get to do easily, and with the added bonus of strong sandboxing. It's early days yet, I think the "Ruby on Rails"-moment has not yet arrived there yet, i.e. a very popular, easy way for devs to create whatever app-de-jour everyone's excited about.
But WASM is weirdly allergic to the DOM and to javascript. The core, fundamental interfaces are terrible and highly disputed, so it will be restricted to mainly-WASM apps for some time.
That’s only a problem if your goal is to keep on doing the same old web apps the same old way, just delegating part of the program logic to WASM which, I agree, will be more complicated. But if you’re going to use WASM why limit yourself to using the DOM and JavaScript? Why not use a programming environment that lets you use more sophisticated tools?
Firstly, you can’t break what is already there, so any evolution of the general platform often has to make wider guarantees than a single framework.
Adopting ideas from any single framework too quickly may put you in a worse position. A framework can evolve and choose when to break compatibility, a language or platform standard has a tougher job in that regard.
Some things that front end frameworks have settled on are now being looked at for standardisation, but I’m personally still wary about changing something like the ecmascript for. It would be an easier call if there were a standard library which simply needed an implementation, but we aren’t quite there yet.
> What I'm curious is why the platforms don't adapt to how the developers have found works best?
Because standards committees are also made out of people. They have their own agendas, experiences, biases, company loyalties etc.
And in the past ten or more years all standards have been taken over by a very small number of very prolific people from Google. Prolific as in: writing dozens and hundreds of specs and having their fingers in all standards.
The developers look for ergonomics in maintaining the code base, that can scale to larger team and websites.
This requires a lot of customers JS framework code to offer, but in a sense, it's because the platform doesn't natively support it no.
Would there be ways to evolve the web platform to better align with the React style for example?