More than a decade´ of experience as a software developer. Software architecture, team coaching, working with all technologies and on all platforms used for web-facing products.
Overall, I think you're very right that these current (branded) platforms of web development (like React) are taking away from good adoption of more web-native approaches. And that the native web platform is actually very good, albeit under-tooled, today.
I am seeing a bigger picture than just the web here, too. The current situation, where lots of developers know only React and not web development coincides with a significant and global relative shortage of senior competences in general in the industry---largely due to the huge amounts of developers being trained globally, while there are often too few opportunities for junior developers to develop truly senior skills, or be trained by truly senior developers.
In a world where deep platform understanding (and deep software engineering knowledge) is a bit too sparse, big and powerful tools become an easy way to keep developers productive. Developers only have to learn one tool.
Not too long from now, companies will start to realize the damage that can quickly be done by software developers with an extremely limited purview. You've pointed out several of them in this post: teams build solutions that perform poorly in real-world conditions. We're not there yet, but when companies start realizing in general, developers will be pushed to change with changing demands.
I think it's interesting to observe how these changes are slowly starting. Svelte's CSS outputs to CSS files, and you can get similar results with plugins for React etc. The emergence of HTML-first frameworks (Astro, Eleventy), as you mention, are another important data point. Eleventy 2's .webc format leans heavily into (HTML-like) web component syntax, enabling complex static-site generation from HTML-like data.
React is like a powerful hammer, and a lot of developers have learned that most things can be hammered in. With experience and changing requirements we will see a shift towards a more analytical approach, where the right tool is used for the job. I hope.
On the whole, I agree with your observations and I am very aligned with your hopes for the future. I look forward to following your posts on this.
On a more granular note, I think there are a few of the data points you pull together that miss the mark a little bit---but there's a real chance that I'm just missing the exact point you are making.
For example, as I mentioned above, Svelte outputs its CSS natively as CSS files, rather than Javascript. That nuance is important because Svelte is a part of the tendency towards a more web-native world. There's still a long way to go, and your other criticisms (e.g. it requires learning a wholly new syntax - even as that syntax is closer to native Javascript) are still valid.
Also, while HTML imports are a really cool way to import web components for use in a page, there is no HTML-native way to embed an external HTML resource inside another---a case which HTML modules support very well within the context it is run in. In my opinion, HTML and CSS modules are an obvious extension of ES modules, which are now standard. I would like to also see more powerful HTML imports, but I can understand why the standards are currently coalescing around a single standard.
As a point against HTML and CSS support in ES module imports, you quote (source unclear) a paragraph saying that Javascript is supposed to be a "DOM-agnostic programming language". It is unclear to me where that idea comes from, seeing as Javascript includes all the abstractions that make up the DOM in the bundled standard library. This seems like a misrepresentation of what Javascript is, has always been, and will continue to be.
Your post makes me reflect on the bigger picture of how the web is evolving. I remember when jQuery was all the rage, and I remember when youmightnotneedjquery.com launched and blew my mind. Heck, I remember when ActiveX, Flash or Java Applets were trying to take over as the primary platforms for interactivity on the web, and I remember how the standards-based approach won.
In all these cases the branded, private alternatives to the standards disappeared after the best of their ideas were included into the standards.
In a way that's the history we're still seeing repeating here. The web enables incredible exploration and innovation, even in ways that are not well-supported by or even run parallel with the intentions of the standards. That has historically been a great advantage, leading to a lot of innovation, and most of the bad ideas being discarded.
I'm confident that the standards are (generally) moving in the right direction (even if there are some missteps), and we're getting an even more powerful web platform. And I'm very excited about that!
To me the real question is how much damage React has done through trying to make itself synonymous with web development - just like Flash or Java applets did. Some people will eventually have to retrain, but in the process I think they will learn how to become better and more versatile developers. Hopefully.
Full-time web tooling dude making cool concept cars for the web. I work on frameworks, compilers, CLIs and browser APIs. Currently building the world's most advanced Reactive Programming runtime!
Plus one that Svelte outputs to CSS and we should care about that detail. So that leaves us with half of the charges against Svelte. Lol. (But should we really get into saving our individual frameworks?) Generally, there are some of these derails that exist at a drilled-in level but which don't really help the overarching philosophy nor move the web forward to new possibilities.
Re: HTML Imports: having put the problem statement well this way...
while HTML imports are a really cool way to import web components for use in a page, there is no HTML-native way to embed an external HTML resource inside another
...what constitutes a corresponding solution? A JavaScript-native way or indeed a HTML-native way? Aren't there credible standards for loading subresources to converge on in the HTML space?
Re: JavaScript and the DOM: am I missing your point? Is the DOM part of the JavaScript programming language or rather the other way around?
More than a decade´ of experience as a software developer. Software architecture, team coaching, working with all technologies and on all platforms used for web-facing products.
Re: Frameworks: Yeah---the note on Svelte is perhaps a bit pedantic in the big picture. I agree with your overall thoughts, and I don't mean to detract from them! I'm sure something even better than Svelte will come along (but I think we're a good ways away from standards so good we don't need frameworks)!
Re: HTML Imports: Agreed - a fully native import in HTML would be really cool. I'll point again to .webc as a format that could have relevance, by leaning into the (already established) Web Component syntax. Imagine <my-component src="/my-component.webc"></my-component> or somethink like this, off the top of my head:
<linkrel="component"name="my-component"href="/my-component.webc"><!-- ... --><my-component><h1>This is placed inside the component.</h1><p>.webc supports slots, too.</p></my-component>
Re: Javascript and the DOM: I think the two are so intertwined that it is nonsensical to consider them as separate in any way :-) The DOM is designed to be manipulated by Javascript. Javascript is designed to manipulate the DOM.
Full-time web tooling dude making cool concept cars for the web. I work on frameworks, compilers, CLIs and browser APIs. Currently building the world's most advanced Reactive Programming runtime!
Really great thoughts you've shared in all. I fully embrace them. And we might even have more to converse on in my next piece in this series. Looking forward to that. (I'd love to bring the .webc idea up in that article where we can play with it alongside other ideas.)
Regarding JavaScript and the DOM, this MDN reference might be what I really have in mind. TL;DR: these two things just happen to meet each other in the browser (and browser-like environments), whereas they're really independent standards. You can expect to see DOM implementations in other languages like Java, and you can even more so find JavaScript runtimes that have no idea of the DOM. E.g. node.js
More than a decade´ of experience as a software developer. Software architecture, team coaching, working with all technologies and on all platforms used for web-facing products.
I understand your view on Javascript, and I agree that it has uses where the DOM is not present. And that the standards for the two are separate.
The context of my original comment was this sentence, which seems to imply not just different standards, but a lack of coupling between the DOM and Javascript:
And notice how this comes even at the risk of tight-coupling a supposed general-purpose, DOM-agnostic programming language with the DOM!
To zoom out a bit, this sentence comes in the context of critique of HTML modules, e.g. import htmlData from '/someFile.html';. I don't think supporting common formats for imports really ties Javascript any closer to "the web" or "the DOM" than e.g. support for importing JSON files does.
(JSON is not the same as Javascript objects---and you could just write your files as Javascript files if you wanted a more clean/less tightly-coupled to web technologies approach to Javascript.)
I would also welcome import of e.g. XML data in a standardized way, and across environments (web, Node.js, deno).
Perhaps I am just reading too much into "DOM-agnostic", or the idea that Javascript isn't already (in design terms) quite tightly coupled to the design of the DOM. It would be incredibly hard to change one without consideration for the other, c.f. backwards compatibility to 1995 (for both the language and the DOM classes), having co-evolved with the web platform, etc.
The Chrome rendering engine and the Javascript V8 engine are both written in C++, so I suppose there is no "natural" connection between the two. But the HTML-DOM-API opens the DOM for any kind of manipulation, including creation of the whole DOM tree. So I suppose, the API is mainly an interface to the rendering core.
So, if we build websites mainly with Javascript, using Javascript to create HTML to let the rendering engine create the DOM might possibly not be the most clever thing we can do. In any case it is not the fastest...
More than a decade´ of experience as a software developer. Software architecture, team coaching, working with all technologies and on all platforms used for web-facing products.
Overall, I think you're very right that these current (branded) platforms of web development (like React) are taking away from good adoption of more web-native approaches. And that the native web platform is actually very good, albeit under-tooled, today.
I am seeing a bigger picture than just the web here, too. The current situation, where lots of developers know only React and not web development coincides with a significant and global relative shortage of senior competences in general in the industry---largely due to the huge amounts of developers being trained globally, while there are often too few opportunities for junior developers to develop truly senior skills, or be trained by truly senior developers.
In a world where deep platform understanding (and deep software engineering knowledge) is a bit too sparse, big and powerful tools become an easy way to keep developers productive. Developers only have to learn one tool.
Not too long from now, companies will start to realize the damage that can quickly be done by software developers with an extremely limited purview. You've pointed out several of them in this post: teams build solutions that perform poorly in real-world conditions. We're not there yet, but when companies start realizing in general, developers will be pushed to change with changing demands.
I think it's interesting to observe how these changes are slowly starting. Svelte's CSS outputs to CSS files, and you can get similar results with plugins for React etc. The emergence of HTML-first frameworks (Astro, Eleventy), as you mention, are another important data point. Eleventy 2's .webc format leans heavily into (HTML-like) web component syntax, enabling complex static-site generation from HTML-like data.
React is like a powerful hammer, and a lot of developers have learned that most things can be hammered in. With experience and changing requirements we will see a shift towards a more analytical approach, where the right tool is used for the job. I hope.
On the whole, I agree with your observations and I am very aligned with your hopes for the future. I look forward to following your posts on this.
On a more granular note, I think there are a few of the data points you pull together that miss the mark a little bit---but there's a real chance that I'm just missing the exact point you are making.
For example, as I mentioned above, Svelte outputs its CSS natively as CSS files, rather than Javascript. That nuance is important because Svelte is a part of the tendency towards a more web-native world. There's still a long way to go, and your other criticisms (e.g. it requires learning a wholly new syntax - even as that syntax is closer to native Javascript) are still valid.
Also, while HTML imports are a really cool way to import web components for use in a page, there is no HTML-native way to embed an external HTML resource inside another---a case which HTML modules support very well within the context it is run in. In my opinion, HTML and CSS modules are an obvious extension of ES modules, which are now standard. I would like to also see more powerful HTML imports, but I can understand why the standards are currently coalescing around a single standard.
As a point against HTML and CSS support in ES module imports, you quote (source unclear) a paragraph saying that Javascript is supposed to be a "DOM-agnostic programming language". It is unclear to me where that idea comes from, seeing as Javascript includes all the abstractions that make up the DOM in the bundled standard library. This seems like a misrepresentation of what Javascript is, has always been, and will continue to be.
Your post makes me reflect on the bigger picture of how the web is evolving. I remember when jQuery was all the rage, and I remember when youmightnotneedjquery.com launched and blew my mind. Heck, I remember when ActiveX, Flash or Java Applets were trying to take over as the primary platforms for interactivity on the web, and I remember how the standards-based approach won.
In all these cases the branded, private alternatives to the standards disappeared after the best of their ideas were included into the standards.
In a way that's the history we're still seeing repeating here. The web enables incredible exploration and innovation, even in ways that are not well-supported by or even run parallel with the intentions of the standards. That has historically been a great advantage, leading to a lot of innovation, and most of the bad ideas being discarded.
I'm confident that the standards are (generally) moving in the right direction (even if there are some missteps), and we're getting an even more powerful web platform. And I'm very excited about that!
To me the real question is how much damage React has done through trying to make itself synonymous with web development - just like Flash or Java applets did. Some people will eventually have to retrain, but in the process I think they will learn how to become better and more versatile developers. Hopefully.
Plus one that Svelte outputs to CSS and we should care about that detail. So that leaves us with half of the charges against Svelte. Lol. (But should we really get into saving our individual frameworks?) Generally, there are some of these derails that exist at a drilled-in level but which don't really help the overarching philosophy nor move the web forward to new possibilities.
Re: HTML Imports: having put the problem statement well this way...
...what constitutes a corresponding solution? A JavaScript-native way or indeed a HTML-native way? Aren't there credible standards for loading subresources to converge on in the HTML space?
Re: JavaScript and the DOM: am I missing your point? Is the DOM part of the JavaScript programming language or rather the other way around?
Re: Frameworks: Yeah---the note on Svelte is perhaps a bit pedantic in the big picture. I agree with your overall thoughts, and I don't mean to detract from them! I'm sure something even better than Svelte will come along (but I think we're a good ways away from standards so good we don't need frameworks)!
Re: HTML Imports: Agreed - a fully native import in HTML would be really cool. I'll point again to .webc as a format that could have relevance, by leaning into the (already established) Web Component syntax. Imagine
<my-component src="/my-component.webc"></my-component>or somethink like this, off the top of my head:Re: Javascript and the DOM: I think the two are so intertwined that it is nonsensical to consider them as separate in any way :-) The DOM is designed to be manipulated by Javascript. Javascript is designed to manipulate the DOM.
Really great thoughts you've shared in all. I fully embrace them. And we might even have more to converse on in my next piece in this series. Looking forward to that. (I'd love to bring the .webc idea up in that article where we can play with it alongside other ideas.)
Regarding JavaScript and the DOM, this MDN reference might be what I really have in mind. TL;DR: these two things just happen to meet each other in the browser (and browser-like environments), whereas they're really independent standards. You can expect to see DOM implementations in other languages like Java, and you can even more so find JavaScript runtimes that have no idea of the DOM. E.g. node.js
I look forward to reading your next piece :-)
I understand your view on Javascript, and I agree that it has uses where the DOM is not present. And that the standards for the two are separate.
The context of my original comment was this sentence, which seems to imply not just different standards, but a lack of coupling between the DOM and Javascript:
To zoom out a bit, this sentence comes in the context of critique of HTML modules, e.g.
import htmlData from '/someFile.html';. I don't think supporting common formats for imports really ties Javascript any closer to "the web" or "the DOM" than e.g. support for importing JSON files does.(JSON is not the same as Javascript objects---and you could just write your files as Javascript files if you wanted a more clean/less tightly-coupled to web technologies approach to Javascript.)
I would also welcome import of e.g. XML data in a standardized way, and across environments (web, Node.js, deno).
Perhaps I am just reading too much into "DOM-agnostic", or the idea that Javascript isn't already (in design terms) quite tightly coupled to the design of the DOM. It would be incredibly hard to change one without consideration for the other, c.f. backwards compatibility to 1995 (for both the language and the DOM classes), having co-evolved with the web platform, etc.
The Chrome rendering engine and the Javascript V8 engine are both written in C++, so I suppose there is no "natural" connection between the two. But the HTML-DOM-API opens the DOM for any kind of manipulation, including creation of the whole DOM tree. So I suppose, the API is mainly an interface to the rendering core.
So, if we build websites mainly with Javascript, using Javascript to create HTML to let the rendering engine create the DOM might possibly not be the most clever thing we can do. In any case it is not the fastest...
As an example of this, when Flutter builds for web, it renders everything in a canvas - no DOM.
It has a lot of other downsides. HTML/the DOM is a really good model for supporting accessibility needs, for example.