Good write up and the entire website is pretty tight, good design and smooth
Modern SPAs without bundlers, CDNs, or Node.js
151–160 of 170 posts
Re: Modern SPAs without bundlers, CDNs, or Node.js
#152Neat idea. My initial concern with this approach is that dependency versions are nowhere to be had, which feeds my second concern which is that a build / ci system would struggle and deployment of this approach would have to be done manually, barring building out custom ci / cd to accommodate.
Re: Modern SPAs without bundlers, CDNs, or Node.js
#153I was recently playing around with a similar approach using Alpine.js and it was really fun just hacking on an html file. Didn't know about importmap, but I'm excited to try it out. There's a time and a place for bundlers. But if you're just spending a lazy weekend on a toy project for fun, this is a really satisfying environment for prototyping
Re: Modern SPAs without bundlers, CDNs, or Node.js
#154Earlier quoted context omitted.
I think the criticism is exactly of that ability to scale though. This setup is ineffective but manageable at the individual scale, but it's going to get more complicated as soon as anyone else is involved, or if the project lives longer than six months and needs to be updated, or if you wanted to add any dependency more complicated than a single file. The other side of it is it's not really clear what the author is…
My objection is that the author is quite clearly describing this as a bottom-up, small scale approach. Criticizing it as an inadequate approach for something much larger is unwarranted, as nowhere was the claim made that this scales up infinitely. What is gained? No build step, as the article also clearly mentions. Your alternative approach goes against the goal of the author. Which is to not have a tool chain. "You…
I don't disagree that it's small scale approach, it's just the language of "bottom up" and "scaling gracefully" that I disagree with. The setup in the article will work only at very small scales, and then you'll probably have to rewrite most of it. The setup I provided works at very small scales as well (arguably better), but can be progressively updated as needed (but only as needed - for example, there's no JSX support for now, but it could be added later if it became necessary).
And in a situation like this, I don't know that I understand the value in avoiding a build step simply for the sake of being able to say you don't have one. This isn't one of those situations where you're saving time by removing the build step because it's not actually building anything here, just rewriting a few paths and adding essentially the same import map. It's probably even quicker overall because it does the reload for you.
Likewise, you're overstating what tools are actually necessary here. It's not "17 tools and 30 dependencies", it's two: one (NPM) to manage dependencies, and the other (vite) to provide the dev server and set the imports up correctly. Everything apart from that is up to you to install as you wish.
Re: Modern SPAs without bundlers, CDNs, or Node.js
#155Earlier quoted context omitted.
> Likewise, Babel isn't important either. You don't need to use some futuristic JS feature on your simple project, you can just stick to well supported ones, thus not needing Babel. I would say even many moderately complex sites/apps have no need for [shiny new feature X]. These days new JS features tend more towards nice-to-have than they do essential. Back in the days when jQuery was ubiquitous it was a different s…
Agree, Babel is bullshit in most cases these days. It's for people wanting to use some syntactic sugar that they just learned about 3 days ago.
I think a lot of Babel is for people who haven't kept up with caniuse statistics and don't realize that the "low water mark", the "well supported baseline", has moved to something very close to ES2021 or more recent. To be fair, Babel is explicitly targeting some of those developers that prefer ignorance and don't want the mental overhead of actually knowing what browsers support and like having "just use the presets!" attitude. I think some of them would be surprised how extremely little most of the standard presets do in 2023 because there are increasingly few things to downlevel.
I have especially long been of the strong opinion that you never need Babel and Typescript. There's nothing that Typescript supports that it can't downlevel itself and tslib is a much tinier runtime dependency (if you choose to have Typescript import it rather than embed it in place) than any of Babel's runtimes (including their core-js dependencies) even when a bundler is tree shaking most of it out today (because caniuse statistics say yagni).
It still amuses that for instance the create-react-app "best practice" in its Typescript template is to use Babel for type stripping and downleveling and delegate the Typescript compiler only to type checking. No wonder people find modern pipelines bloated. To be fair, I get why CRA likes the conceptual simplicity that both of their core templates use the same Babel presets and pipelines given to them Typescript is still the opt-in "extra".
(Also, I have no problem with esbuild doing my Typescript type stripping and running tsc as a separate pass in esbuild pipelines, but esbuild isn't pretending to do a lot of unnecessary downleveling in 2023 and adds no further runtime beyond the parts of tslib it bundles for you. It's mostly just Babel's extreme complexity that I find redundant and unnecessary and its labyrinth of presets that don't actually do much in 2023 but give the impression that they do.)
Re: Modern SPAs without bundlers, CDNs, or Node.js
#156Earlier quoted context omitted.
The historical context is web development became popular and developers from other disciplines moved over and brought their practices from those other areas of programming with them. We compile apps for the desktop, we should compile apps for the web too. They brought their complexity with them and forced it onto web development instead of stopping to consider if that was a good idea. Now we have developers who never…
Have you worked with old, medium to large sites filled with jQuery and custom ad-hoc scripts? In the past year I helped maintain a site exactly like this - it's a huge pain. So many problems that should've been caught sooner are noticed far later, leading to long feedback loops that cost time and money. Sure, I would agree that the current JS ecosystem has its issues, but work can happen at either compile/design time…
I still remember why I moved to Typescript.
Typescript was still 0.x "public preview" and I was knee deep in a codebase that was a massive amount of jQuery scattered across mostly inline script blocks in a huge number of ASP.NET templates many of which were "components" subcluded by other templates (meaning who knows how many final inline DOM-blocking script blocks per final output page). I had helped invest a ton of effort into an AMD infrastructure to start to modularize all those inline script blocks, but the conversion was pretty slow going (AMD modules were a pain to write by hand) even though the clear performance win of it helped keep it a clear priority project. Typescript even in 0.x made all of that so much better and easier if for no other reason that it made writing and managing AMDs so much simpler (and type checking helped code quality so much as bonus).
A lot of compile time tooling didn't fall out of the sky because they were solutions looking for problems. They solved real problems at the time. It's amazing to think how few developers today remember "the bad jQuery days" and "server-side template inline script block hell" and AMDs (good riddance, though they too solved important problems in their time). I don't think they can understand how much "our compile times are slow" is a better problem to have. I'm not sure if I envy some of them having missed some of the worst of those past problems.
Re: Modern SPAs without bundlers, CDNs, or Node.js
#157Import maps strike me as a huge win for making prototypes, or things where you control what exactly you're importing (eg from a private registry instead of NPM), but throwing out the bundler and more importantly the tree-shaking and minification steps of bundling, will result in a massive about of unused code being delivered to the user. You'll be relying on maintainers putting minified, unbloated assets in their pac…
This is where ES Modules come into their own and why importmaps are very much an ESM thing, predominantly. ESM was built with "natural" tree shaking in mind in a browser context. Only URLs that are actually imported in a module are loaded. (importmaps are not prefetch maps.) Modules themselves are loaded in a such a way that unused exports in them may be lazy-JITted "weak references" and easily garbage collected (a form of tree-shaking).
You get better "natural" tree-shaking from that library of lots of small little ESM modules, you don't need to rely on maintainers building their own minified bundles.
The obvious trade-off, of course, is that HTTP 1.0 wasn't optimized well for lots of little files and even HTTP 1.1 servers haven't always been best configured for connection reuse and pipelining. Bundling is still sometimes useful for a number of reasons (whether or not minification matters or compile-time treeshaking makes a noticeable difference from "natural" runtime treeshaking). Of course, all the browsers that support importmaps and script type="module" all support HTTP 2 and most support HTTP 3 and that trade-off dynamic shifts again with those protocols in play (the old "rules" that you must bundle for performance stop being "rules" and everything becomes a lot more complex and needs "on the ground" performance eyeballs).
Re: Modern SPAs without bundlers, CDNs, or Node.js
#158Earlier quoted context omitted.
The last couple days there's been a lot of negativity towards the build step, but it's like everyone's forgotten the historical context that made the build step so popular to begin with. I'll give credit to the post about the fragility of certain build tools long-term in the npm ecosystem, but I don't think that's a reason to shrug off build tools period. We just need better, more stable ones (and I think we're start…
The historical context is web development became popular and developers from other disciplines moved over and brought their practices from those other areas of programming with them. We compile apps for the desktop, we should compile apps for the web too. They brought their complexity with them and forced it onto web development instead of stopping to consider if that was a good idea. Now we have developers who never…
> We compile apps for the desktop, we should compile apps for the web too.
I don't think this is true at all. The key reason you see build steps are to solve problems that you don't even have to worry about in desktop apps. If you have an app on the web, its bundle size needs to be small so that it downloads over the internet in a few hundred ms or so. So you get a minification step. You want a good type system, you end up with a build step. You want broad compatibility with older browsers? You end up with polyfills. Need to do some asset processing? You end up with some scripts that have to run at build time.
Build steps aren't some arbitrary complexity people make them out to be. They solve performance and compatibility issues, which impact real users in the real world. Running full-blown desktop apps over HTTP comes with a different set of problems compared to any local native app.
Of course most of this isn't important for small side projects. But for many, side projects are a way to learn about different technologies they might end up using for larger projects or in a professional context.
Re: Modern SPAs without bundlers, CDNs, or Node.js
#159Earlier quoted context omitted.
I’ve been doing it professionally for 20 years, and I agree. Modern front end development with TypeScript, Vite, Preact, and even the much maligned npm are so much better than anything that preceded them for building complex front end applications. I like having a build step for code that I write. I build C, I build Go, I build C#. I don’t ship debug builds of those things. I don’t know why I’d want to forego all of…
I don't mind those things. I do mind that they install 2000 packages, though.
> $ echo '{}' > package.json && npm i --save-dev typescript vite preact
> added 17 packages, and audited 18 packages in 1s
You're off by two orders of magnitude. I get not wanting a lot of transitive dependencies, but you can get a modern toolchain without having a lot of transitive dependencies.
Re: Modern SPAs without bundlers, CDNs, or Node.js
#160Earlier quoted context omitted.
Agree, Babel is bullshit in most cases these days. It's for people wanting to use some syntactic sugar that they just learned about 3 days ago.
I think a lot of Babel is for people who haven't kept up with caniuse statistics and don't realize that the "low water mark", the "well supported baseline", has moved to something very close to ES2021 or more recent. To be fair, Babel is explicitly targeting some of those developers that prefer ignorance and don't want the mental overhead of actually knowing what browsers support and like having "just use the presets…
Es6 arrow functions are a good example of this. They have been around for a long time and work in most browsers, but people learned they need babel to transpile them out for internet Explorer. People dropped ie support but the knowledge "we need babel for browser compatibility " remained an entrenched fact.