One one hand, I think this makes total sense from a technical perspective. Don't load code you don't need, right? That's what we're doing with JS in SPA frameworks like Next.js, NuxtJS, SvelteKit, etc.

The problem with splitting code like this is it isn't aligned with the developer's thought process. It's a step back from where we've been headed over the past decade of web development. Current major JS frameworks like React and Vue are basically JS in HTML and newer CSS frameworks like Tailwind are basically CSS in HTML. The reason these frameworks have gained so much traction is because they don't break the developer's concentration.

The whole "separation of concerns" mantra from a decade ago was misguided. Web developers don't naturally think about code in terms of "let's do the HTML, then the CSS, then the JS". They think, "let's make a button that does something when I click it". And with the current frameworks, that button is often a single (albeit long) line of code. Semantics, layout, animation, interaction—everything. A decade ago, that button was spread across three files in three separate locations.

The problem with the approach outlined in the article is developers don't think, "let's do mobile, then tablet, then desktop". They think, "this box is always blue and it lives in a column that's a third the width of the container on larger screens".

The reason the code splitting works in the JS frameworks I mentioned earlier is because it's completely automatic. Unless this code splitting requires zero effort on behalf of the developer, it's never going to catch on. The DX just isn't there, even if it is certainly more performant.