Rethinking the Modern Web—by Oxford Harrison
https://dev.to/oxharris/rethinking-the-modern-web-5cn1
Featuring this gem:
[HTML, CSS, JS] ➡️ Build Step ➡️ [JS, JS, JS](e.g. Svelte, Vue)
[JS, JS, JS] ➡️ Build Step ➡️ [JS, JS, JS] (e.g. React)
10 replies
@zachleat Unfortunately they get the purpose of a few proposals I worked on around modules wrong.
The immediate goal of being able to import HTML and CSS into JS isn't to make JS the center of the universe, but to reduce the need for build steps to transform files into JS in the first place. It's *less* JS centric this way.
Then I think we can let HTML import non-JS modules directly. ie, HTML page imports HTML module with declarative custom element definitions and no actual JS involved.
@justinfagnani hmm—a few thoughts:
1. Does this repeat the same platform defaults mistake that React made?
“We had SSR from the beginning!” they cry, but few folks used it that way for *years* because the oxygen was being consumed by client rendering patterns.
2. Personally, I don’t want to trade away a build step for more client JavaScript. I have no problem with build-only server-only JS being the center of the universe—as long as the output of that build is HTML-first.
@zachleat @justinfagnani As I remember using HTML imports it wasn't particularly about reducing builds steps to zero, but to cut out a level of transpilation because the platform layers understand each other. You could just have HTML without needing a DSL like JSX and all of its compromises.
@McNeely @justinfagnani ah, when I hear HTML imports, I think of the ability to import HTML using HTML. If your usage here is referencing the ability to import HTML in JS that makes sense to me—and don’t get me wrong it sounds like a worthwhile goal!
But on a priority list I’d put the HTML to HTML feature higher
@zachleat From memory HTML Imports got scrapped because no other browser would support it
There were also some performance concerns but not sure they were any worse than render blocking JS or CSS @import
@andydavies @zachleat There weren't really rendering concerns, it was just a desire to not have two separate module systems. We can have one module system for an JS, CSS, and HTML, we just have to finish ...
@justinfagnani @McNeely Looking forward to testing the options—but I will say that importing HTML via `<script>` is a progressive enhancement code smell for me. Hopefully that’s just an academic complaint and irrelevant practically.
> 1. Does this repeat the same platform defaults mistake that React made?
What does that mean?
> 2. Personally, I don’t want to trade away a build step for more client JavaScript.
CSS and HTML modules don't mean more client-side JS, they mean less of it as you can import CSS and HTML instead of... JS.
@justinfagnani importing CSS and HTML into JS wasn’t something I was doing before, though—so this feature may not be meaningful to me as it stands (which is fine!)