Simple Modern JavaScript Using JavaScript Modules and Import Maps
vue-mjs.web-templates.io
vue-mjs.web-templates.io
Another example, I recently had to upgrade a Vue 2 application to Vue 3, because Vue 2 is going EOL this year. Well, apparently that means I also had to change the build system from Webpack to Vite, the test library also was a "recommended change", the state store library was different and wasn't backwards compatible, and half the vue plugins required an update or a replacement for a Vue 3 compatible alternative.
I have not seen this pace in other languages/environments. For example, in Python, there are different "build" systems (old setuptools, pip, poetry...) and yet they are all compatible. In C/C++ I still haven't heard of a framework that forces you to upgrade your build system when they push a new version.
I've done react, vue, and old school jquery and miss the days when javascript was just something you had a script tag for in your website.
"Building" js projects and all of the other weird ... garbage ... that gets thrown in is just totally frustrating. The best I have been able to manage is to use esbuild + react + typescript in a very conservative fashion to keep things manageable for someone like my self: has a life and doesn't want that life to be consumed by yet-another-new-node-js-build-this-perpetually-differently-and-forever-and-with-much-pain system.
What's to stop you from doing this now?
In fact, in between all the fluff in the article, mentions of browser support for ES Modules makes this pretty straight forward. I used it recently for a small repro and i was surprised at how well it worked https://idb-perf-repro.netlify.app
The modern web industry isn't that old yet. Give it time. We've been writing C++ since 1985.
React is 10 years old. Vue is 9 years old. Angular is 11 years old. The only "real" new kid on the block is Svelte, which is 7 years old now.
The web constantly strives towards simplicity. React was developed because AngularJS was this huge enterprise framework of global state. React includes immutability to make things simpler. Vue was developed because its developers saw React (then with classes) as too complicated. It's loved to this day even by the HN crowd for its simplicity. Svelte again was developed because their developers saw the possibility to make updating the DOM simpler. Again, the HN crowd and its users love it, because Svelte really is dead simple. It's been my drug of choice for 2 years now and I'm seeing unbelievable productivity among friends and colleagues which choose to use it.
The amount of libraries you see can be explained because of JS huge open source crowd, perhaps the largest among any language. There is no controlling entity, so people are free to write their own open source abstractions. We as an industry should see this as a good thing, because there are mountains of code now available for everyone, free of charge with MIT licensing. Startups can write applications that reach millions and generate billions, without worrying about QT licensing costs or paying for a Delphi compiler toolset. They need one codebase for an application that runs virtually the same on every device, mobile, tablet or desktop alike.
> Another example, I recently had to upgrade a Vue 2 application to Vue 3, because Vue 2 is going EOL this year. Well, apparently that means I also had to change the build system from Webpack to Vite
Again, Vite strives for simplicity. Vite is so simple that it took the industry by storm. Gone are the days of webpack 4 era configuration files that made you want to rip your hair out. Vite was written by Evan You, the man behind Vue, which could give you an indicator of the quality of the tool.
I hate working on our C++ / QT enterprise product, because each change takes ages for me to see and verify. If that product was a web app (which we are currently looking into), I could see changes instantly, with application state persisting through recompilations.
Grizzled seasoned developers have longed for a native application toolset that runs on every device for decades. Some just miss that web browsers do exactly that, with the added benefit of being a near perfect sandbox. Of course it's not perfect (yet?), but perfect is the enemy of good.
1985
It's been 5 years since initiating that investment. Reflecting on it I'm frankly amazed at the amount of technology that we don't need. The standard type of UI we build really hasn't changed but the time code and overall cost continues upward.
Looking back to 2018 we might have been collectively beguiled by the self-perpetuating marketing machine of single page application technology. We've decided unless there's a very clear and specific justification to write a thick client on a web page we're avoiding it going forward.
Tools such as HTMX are perfectly effective substitutes at far lower cost. At least for what we need
IMO the important thing is to find what works for you. I’d be wary of every other article out there that offers their ideas of the best way of doing anything web.
Personally I wouldn’t consider the article’s solution “simple”.
Creating beginners is important.
Having more attention to spend on the user than maintaining the brittleness that can be present is a real tax.
I think it's a combination of the front-end needing more boilerplate than back-end, and developers struggling with accounting. Maybe your cool new framework will save you 10% dev time, but you'll lose that 10% ten times over with the learning and error-bashing you and your teammates and future team members will have to go through.
My policy is that you can use pure JS where a framework is overkill (I'll also accept jQuery), and React otherwise. React has emerged as the winner, and trying other things isn't worth the cost if you're paying (which employee developers are not).
I recently built a small app using pure JS, just to remind myself how it used to be. It's definitely too verbose to avoid frustration. But HotNewFrameworkX vs React is never going to be big enough a benefit to be justified.
As far as not blindly following the advice of web advocates, I agree - they live on the bleeding edge. Unfortunately these are the people the new and impressionable devs come across on social media and hold their words like gospel because look how many followers they have and look at who they worked for, they must be right! Web tech moves fast, especially the shiny frontend stuff, and that generates discussion and leads people to believe that everything else is obsolete when in reality it's not.
React and Vue for example have been super stable for almost 10 years, and they don't really need anything other than one or two packages to work. CDN + alternative syntax is enough to make React as boilerplate-free as jQuery. Add another package (htm) if you want the good syntax back.
The problem has always been the ancillary stuff: JSX, Vue SFCs, wanting to use "import from" in the browser, IE11 compatibility, testing, linting, converting CSS, removing typescript types.
For those things we need tools like Webpack, Babel, ESLint, etc. And those just aren't "as good" as React, Vue, or even Typescript. Some of them break compatibility constantly, need a lot of boilerplate, need pulling several packages to do the most basic things, are the source of frustration for a lot of people and the source of the overkill you mention.
IMHO think part of the issue is that a lot of those ancillary projects are optimizing for cases that aren't significant in practice.
My best suggestion to those developing JS apps is to not get carried away with the noise, pick a solid framework (React, Vue, Svelte, etc), pick some solid libraries, stay away from the experimental stuff, and just run with the tools you've got. There will always be a new tool around the corner that claims to be better than the existing tool, forget about it and stick with what you got, then revisit that tool if you hear alot of noise around it.
With Vite everything just basically works out of the box with no or very little configuration. And it's pretty fast.
And it works with Rollup plugins, which are easy to write.
It makes having a relationship with a stable piece of code challenging to move on to the next big function.
Over time, maintaining anything too old or too new can drag momentum and progress.
Still it’s one of the most universal technologies. Some of the more recent simple frameworks like alpine.js, or lit as I rediscovered today on HN may have more merit than initially realized.
It happens in Python too. For example in ML, in 2015 everybody was using torch, then Keras, then TensorFlow, then PyTorch.
Pandas now being replaced by Polars.
If you look at MLOps, every 3 months there is a new hot library.
In other words, it happens in the active parts of the ecosystem (data-science), not in the old stable ones (standard library, reading files, ...)
Python ML maybe. That's a different community to Python in general. The only place where there's been churn in general Python is probably package management.
The fact that JavaScript front-end is going through so much churn just shows that it's not obvious yet what the proper design looks like.
Rust is going through the same thing now with GUI frameworks, every couple months a new approach appears. Because it's not obvious yet what's the proper design for a Rust GUI API.
That doesn't fit my recollection. Only Django and Flask had much mindshare.
> Now that space is pretty much stable (dead).
Do you mean stable or dead?
That's the status today.
A few other major ones back then - Zope, Tornado, Bottle.py, Pylons, TurboGears, CherryPy, web.py, Werkzeug.
Is Tornado even a web framework?
There was some interest in the others you mention but I don't remember them ever being major contenders.
I guess my point was that it never felt like the javascript situation where there was genuine paralysis of choice on many fronts. You generally either went Django or Flask depending on your preference for "batteries included". All the other choices were pretty niche.
Javascript has stabilized a bit in the last few years but the number of choices needed to start a project are still much higher than anything I experienced in Python web dev.
But it was not clear at all that Flask would be the other winner. There were a lot of articles discussing Flask vs Bottle vs web.py.
> like the javascript situation where there was genuine paralysis of choice on many fronts.
I think that's the perception from the outside. If you start a project, it's pretty clear what's the recommended stack of the day. Sure, next year might be different, but today it's React/Vite/Tailwind/...
JS frontend seems to have been going through churn for over a decade now. It's a messy language, and because we've been forced to use it as the sole frontend language for a while people have been trying to figure out how best develop with it. Hopefully, with more language support in Wasm, JS will finally be replaced.
What we really need is an end to end echo-system with funding, adoption and vision. Deno and Bun are both getting in this direction
Ala https://en.m.wikipedia.org/wiki/Coffee_Talk_(Saturday_Night_...
commonjs to esm is a massive shift. esbuild in place of babel is a ground breaking achievement.
Vite, which leverages ESM and esbuild, is very different, and better than webpack.
The ecosystems which haven't changed, I. E. react and angular, are either in middle of transition or suffering from not doing it.
We haven't had a breaking change to the current version since August 2018: https://github.com/elm/compiler/tags In fact, the single most frequent criticism of our community is, "Is Elm dead? It hasn't been updated in years". The truth of the matter is that it's not dead; it's just really stable.
Everything still works. You can use a bundler, like Vite or Parcel, but you don't really have to. You can use whatever Javascript library you like, through ports or web components, but again: you don't really have to, unless you need to do interop with another service (i.e., Google reCAPTCHA or Stripe) - and in that case, you're at their mercy regardless of whether you're building your application in Elm, or in something else.
Compared to the rest of the JS ecosystem, we have virtually zero dependencies on outside tools or infra, other than Github; but if Github "goes away", I'd be willing to bet that the rest of the Javascript ecosystem would be in a lot of trouble, too.
We are a small but passionate developer community. Enough of us - myself included - do this full time for it to feel like it's a safe bet and that it's not going anywhere anytime soon. Join us. https://elmlang.slack.com/
Am I the only one who thinks this idea is somewhat contradicted by the TODOs that are still in the official docs, and seem to have been for years?
<text-input :status="store.error" id="text" label="" placeholder="What needs to be done?" v-model="store.newTodo" v-on:keyup.enter.stop="store.addTodo()">
<input
id="text"
placeholder="..."
onChange={event => setText(event.target.value)
onKeyUp={keyEvent => keyEvent.key === "Enter" && addTodo(text)}}
/>
<script>
let text = '';
function onEnter(key){
if(e.keyCode === 13) addTodo(text)
}
</script>
<input
id="text"
placeholder="..."
bind:value={text}
on:keydown={onEnter}
>Unlike Vue templated components which is just JavaScript that's executable as-is and only requires the Vue runtime library to run.
That is true. But the syntax is much closer to native JavaScript.
They're just stylistic preferences, both have valid JavaScript expressions inside their component event handlers, the difference is syntactical, React went with JSX whilst Vue/Angular/Alpine.js/Aurelia adopted a HTML (valid) centric syntax.
I don't know what this is supposed to mean. The logic in Vue 3 components is maintained in its JavaScript setup function. The template syntax is just HTML based template syntax that can be parsed natively by browser's HTML parsers for binding component functionality to the DOM. Behind the scenes it compiles down to JavaScript functions like React does, where in addition to its template syntax Vue also supports Render Functions [1] and JSX/TSX [2].
The template can be maintained in a string, in the HTML DOM or in a SFC. Templates in a string or DOM don't need a preprocessor whereas Vue SFC's does as compiles down into more optimal JavaScript functions than React's and its template syntax is non-existent at runtime as it never makes it to its compiled .js builds.
Both Vue and React use their view functions to construct a Virtual DOM that they use to calculate which DOM modifications need to be made, i.e. they both serve the same function and their differences is largely cosmetic, effectively just a stylistic preference.
[1] https://vuejs.org/guide/extras/render-function.html
[2] https://vuejs.org/guide/extras/render-function.html#jsx-tsx
You can do better than both though by just using JS template literals, like Lit / lit-html does. Here you have only valid JS syntax, JS for the expressions, and no compiler:
html`<input
id="text"
placeholder="..."
@change=${event => setText(event.target.value) }
@keyup=${keyEvent => keyEvent.key === "Enter" && addTodo(text)}}
>`
You can always chose Not to use them. "v-on:keyup" also works but you need to move logic for checking enter and stopping event propagation to event handler
const Edit = { template:/html/`<SlideOver @done="close" title="Edit Contact"> <form @submit.prevent="submit">
at this point, anything not react and bundled is a niche approach. so it doesn't detract- to me- that this post comes off as trying to expand a view of options.
> Tailwind isn't a panacea, and that Vue3 Form template string (excerpt below) is kind of gross
what is a panacea? is your standard to only adopt systems which are a panacea? what qualifies for this bar? personally the template-string seems unoffensive & direct enough to me. it's a go at trying to meld html and programming together, and it seems basically fine. template strings are, in general, pretty great, and we should learn to use them, train ourselves to find them natural.
being able to type-hint with a comment seems like a great zero-cost way to get most of the benefit of much more heavy-weight compiled systems, without having to do any actual work to set-up & maintain build-tools and build-pipelines. it might not instantly have appeal, but to me, 6 little letters in the code are kind of not really a big deal, for how much ridiculous maintenance & pain it could alleviate.
> reinforcing my perception that the attempted philosophical purity here is neglecting DX / ergonomics.
this feels like browbeating. you don't really have any arguments anyone can contest before this; you've leveraged your opinion that this isn't to your liking, without saying why. now you're insulting & degrading the attempt on the grounds that it's too philosophical & pure, again without substantiating how or why. this doesn't feel like a fair conversation.
> When it comes to modern webdev embracing standards and leveraging web platform fundamentals, Remix.run (with TSX) makes a lot more sense to me
right uh huh. can we not make quite such a zero-sum game out of what right now you perceive as working for you, having never tried this other thing? can we make some permission for "i don't know"?
part of what i like about this article is that all the standards present in it are usable on the web platform itself. using tagged template strings, using es modules. using type hints removes the need for compilation. nothing here feels bad to me. it feels like a free alternative that does the same jobs as well, but which most people just aren't accustomed to.
personally, this article was doing pretty good for me in general. i stumbled pretty bad at the @servicestack/client section, which seemed like a lot of generic jquery like magic binding glue, that probably works fine & helps, but felt like a bit more wild-cat a direction of data-handling than i personally wanted to go in for.
Then you've never built a large serious production JS frontend using something like Vue.
Saying that JS template strings are a sufficient replacement for SFC Vue files or JSX (or any popular templating system) sounds crazy to me. This would depend very heavily on IDE integrations [1] but even then it would be extremely messy and only add more complexity than removing transpliers gain.
Sure it's fine for small niche usecases but if it was a serious option it would have been pushed long ago. JS templates have been around for 7yrs now.
[1] getting the whole team to just use VSCode is a big ask or getting HTML+Vue formatting/syntax highlighting working across Vim/Webstorm/etc. Then there's losing Prettier + Elint for linting and autoformatting. There's so much tooling lost with template strings,
The Vue component used for its working CRUD Example is at [1] which is the verbose version, a more capable example [2] with a lot more functionality is available at [2] which uses the new AutoQueryGrid component to reduce the functionality down to 1 line.
The point of adopting a traditional Multi Page App approach is that you don't need to build a large serious JS SPA frontend as the separate pages provides natural isolation where you only need to build isolated components for the functionality each page needs which is typically glue code that makes use of external libraries & components.
[1] https://github.com/NetCoreTemplates/vue-mjs/blob/main/MyApp/...
[2] https://vue-mjs.web-templates.io/bookings-auto
[3] https://github.com/NetCoreTemplates/vue-mjs/blob/main/MyApp/...
The examples in this article are using vanilla template strings to author raw html, but that only misses a couple of nicities JSX has. There are tagged template string libraries like htm[1] that do include some of the few nicities JSX has, but which are actually compatible with the official language.
Anything you shove into a string and then parse yourself is "compatible with the language". Doesn't make it better or significantly different from systems that do this step earlier.
Anything you do with JSX isnt compatible with the language. So that makes it worse & significantly different.
Diving way into technics, tagged template strings, if called from a function, will have reference equality for the literals array. The optimizations might not be ahead of time, but the net is, even if the tagged template string is inline and single-phase (as opposed to moving your tagged template strings to the top level & having them "compile" & return a function to accept variables/children), there's still a lot of room for reusing the same "compiled"/parsed work.
Most JS frameworks are written in JS. You can run React, Svelte, Vue etc. directly from the browser without a build step.
> Anything you do with JSX isnt compatible with the language. So that makes it worse & significantly different.
So, this is an artificial and absolutely arbitrary line that only looks good because you chose it to be so.
Also, JS world is probably unique among all programming languages with such aversion towards anything even remotely resembling compilation. Which is ironic, given that transpilation (aka converting from non-existent and future syntaxes to existing one) is Javascript's bread and butter.
> The optimizations might not be ahead of time, but the net is
> there's still a lot of room for reusing the same "compiled"/parsed work.
As opposed to what? To compilers/transpilers that can, and do, the same thing? And can do significantly more things like run whole-program optimisations. Or, like Solid, can just remove the need for components in the resulting code.
The world already agreed about 40-50 years ago that programming with strings is a bad idea. And now JS purists are willing to die on this hill (while inventing bizarre justifications and increasingly bizarre DSLs for anything remotely complex, see lit-html).
And of course there's nothing wrong, or "worse" with DSL, or compilation. As evidenced by compiled frameworks being blazingly fast: https://krausest.github.io/js-framework-benchmark/2023/table... and
incredibly fantastically hugely incorrect. JSX is not supported in EcmaScript! Vue3 is not supported. the way we in fact do use these tools is not supported. i've said that so many times already & you keep making these absurd claims otherwise. it's just not so (not unless you take extreme & vast detours off the mainstream & hand author lower non-JSX react, which no one and few libraries do).
it's not in any way unclear that you've been wrong the whole time but you keep generating longer & longer posts & making more and more noise each time. but you've been in the wrong this whole time & it's just obvious & clear.
JSX is not supported in EcmaScript. again and again and again I keep having to say it. it requires tooling to reduce a superset of the language down; the browser's js engine is not capable of parsing code with jsx in it. this is intensely self-evident yet you protest & make a large hard to deal with confusing scene here.
again: jsx is not valid ecmascript!
> So, this is an artificial and absolutely arbitrary line that only looks good because you chose it to be so.
so now you seemingly maybe actually sideways-admit the truth, but you want to defend the other side... after having repeatedly made confusing claims there is no such line... please man, it hurts to get dragged through this. your whole first arguments seem dishonest & misrepresentative. and this second half admits the truth, but tries to smokescreen & cloak the basic obvious truth in painful new contorted ways.
i meam, really, omg, what? are you frakking kidding? this isnt "arbitrary". this is a quite clear line: things the language can do, and things that require outside tooling to do. jsx and vue3 (im unsure about vue2) require tooling, because as I have said multiple times already the language does not support them. as much as you protest, that's for sure how it is.
> As opposed to what? To compilers/transpilers that can, and do, the same thing?
fuggin exactly; holy heck, yes! a thing in the language as opposed to something that has to rewrite your code because the language cant do that thing (jsx, vue).
frelling heck dmitiriid, nearly everytime you show up in my replies it's full of huge long dissembling. you are telling lie after lie after lie, sowing absurd confusion & doubt over basic assertions, flooding the zone with shit. like this hummdinger of an overstated opinion-as-fact:
> The world already agreed about 40-50 years ago that programming with strings is a bad idea.
get off it man. this vastly overrepresents a particular chosen preferred view, & is nothing more than a malice-ful way to browbeat & condescend. if there's a tagged template string that works just as well as jsx, but actually works inside the language, you're ready to browbeat & bully it... because there's quotes around the content? i've already cited htm, which seems basically to prove this potential, but you're just gonma use nastiness & snark to degrade that potential, to disregard it out of hand? dimitiriid, this is how your replies to me keep going. i really really hate it. your words show intense favoritism towards what you want to believe time & time again & are just incredibly callous & short & browbeating against anything you dont want to think about. this dogmatism is intensely unpleasant to deal with; i'd really like to see a reformed & much more honest & engaged form of discussion when you reply to folks/myself, where other people are allowed to also have opinions, or I'd really appreciate you opting out of replies to me, to reduce these ultra long winded back & forths that feel so vastly unpleasant & infinitely useless. you never ever acknowledge that maybe perhaps other views are possible.
> And of course there's nothing wrong, or "worse" with DSL, or compilation.
they can have be worth it for some people, at some time. but.
i think there's room for people to express a desire not to deal with this shit. just authoring code & having the browser run it has attraction, has some merits. needing more work- external build processes- is in many ways clearly & obviously worse; we just shouldnt have to be taxed like that every single time we want to do anything. these are worse, in many (but not all) dimensions.
Says the person who goes on a rambling rant with cussing, personal attacks, and little to no substance.
Every time you show in anyone's replies this really is all anyone can expect.
I believe you've already had multiple warnings on that from HN moderators.
So, at this point, adieu.
They're just a few lines helper [1] to avoid needing to verbose boilerplate of `document.querySelector()` and `Element.addEventListener()` everywhere when wanting to use old-school jQuery dev model without a jQuery dependency.
I'd personally lean on a Reactive JS FX for anything remotely complex, but these helpers work well to demonstrate simple functionality without a JS FX.
[1] https://github.com/ServiceStack/servicestack-client/blob/d47...
Otherwise its contents is pure Vue 3 that's runnable without a preprocessor. You could also maintain the Vue component inside a HTML `<template>` [1] but that would force additional considerations due to DOM constraints like forcing usage of explicit end tags, kebab-case attributes & components, using expanded `v-on:` instead of '@' which is special char in Razor, etc.
Given it's just using Vue 3 syntax, I'm assuming the critique is more a stylistic preference for React & TSX over Vue.
[1] https://github.com/NetCoreTemplates/razor-tailwind/blob/main...
- the <a> was a react element (a dependency in 1 million diff places)
- href value was a prop coming from an API
- footnote (to which the anchor goes) was a handlebar template in different repo
- the ID of footnote required modifying a seperate JS util which handles numerical increments (also updating test, and PR comments)
- the <a>, href, and footnote are all joined and bundled together using variety of complex scripts
this is normally a 10 second task. but thanks to simple modern javascript it took me best part of a week and a lot of complexity fatigue & depressive thoughts.
If the href needed to come from the api and the ID needed to be incremented and unknowable ahead of time then there were always going to be complexities. But it’s not like React stops you from hardcoding href URIs (said as someone who generally avoids using React whenever I can).
it really wasn't. been doing this for 15 years. seen all the trends.
cargo-culting mentality. a lot of new-ish folks really really don't know any better. first instinct is to hit npm i.
the idea of static html is alien to many.
The Enterprise Java solutions never seem to get as much discussion but we all recognize it also as being equally if not more so absurd[1]. This is true of every language and framework that gains mass adoption and use. Scala projects are crazy complex, the python 2 to python 3 migration was a mess, none of these are problems. They reflect the improvements in every metric to the underlying platforms and systems - end user experience, developer experience, reliability, testability etc.
JavaScript is in a phenomenal place today - we have come "full circle" in the same way that streaming has come "full circle" with cable - better tooling, new capabilities, improved experiences etc.
There's a lot of keeping up with the jones' - that's partly nice as its job security and partly nice as a reflection of engineers improving our own ecosystem.
[1] https://github.com/Hello-World-EE/Java-Hello-World-Enterpris...
Javascript is not getting hate because it is now famous so people are jealous and are hurling non-sensical abuses. The problem many of us see is that Javascript is famous, a critical piece of tooling and Javascript evangelists are still working in the teenager I-will-just-type-it-again mode.
By now, things should have progressed to a stage where doing simple things was simple.
Regardless of what you think about the maintainability of tailwind, Tailwind is someone else’s postcss CSS processor classes.
The post talks about how it’s using JavaScript Modules and Import Maps to avoid needing an npm build system, how it’s gone back to traditional MPA server rendered pages to avoid SPA client routing and heavy state, how that approach lets you use any JS library in each page without affecting deps or build sizes of other pages, which libraries are good for use without a build system, the productivity features of its client and Vue component library and techniques it uses to load components fast with embedded JSON and pages fast with htmx’s boost feature which is a popular pjax implementation that’s a common performance technique that websites like GitHub uses.
None of this is framework dependent and is achievable with any server html framework.
> ServiceStack is a simple, fast, versatile and highly-productive full-featured Web and Web Services Framework
The page itself also serves as a working demonstration for the features it talks about.
Edit: importmaps is also in this entry, I found it straighter to the point: https://news.ycombinator.com/item?id=34829039
Effectively we can use modern browsers native support of JavaScript Modules and Import Maps to create modular JavaScript Apps without a bundler.
DHH has a good post of the benefits of this approach in "Modern web apps without JavaScript bundling or transpiling" [1]
Which HEY has been running off for more than a year [2].
[1] https://world.hey.com/dhh/modern-web-apps-without-javascript...
[2] https://world.hey.com/dhh/hey-is-running-its-javascript-off-...
I thought that was the main benefit of "bundling" multiple modules together.
Using JavaScript Modules means the browser can traverse the matrix of dependencies needed to efficiently download & execute just the modules it needs.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sc...
The opposite of large JS bundles is a framework like Qwik [1] which achieves perfect PageSpeed scores by downloading the least JS possible, both initially and then at runtime by only downloading the JS needed per interaction, resulting in very small downloads over a lot more requests.
Where you get into trouble is resources pulling in others with a dynamic import mechanism, which can start a slow cascade. There are various solutions, like preload tags, import maps, http/3 (which reduces stalling), and prebundled libraries or groups of libraries.
As for lack of tree-shaking, that’s not an issue for smaller web applications. The libraries will be prebuilt and so are slim already, and you have perfect control over what is added which means there’s less that needs discarding. Also, most web applications struggle with image footprint, not js or css footprint.
I think a medium to large SPA web app shouldn’t try this approach, but smaller web apps or ones that have a light client footprint may benefit from the simplicity of a no build frontend.
Are you sure? Each separate download needs its own negotiation with the server. Each download needs its own request and response. So you would have 100 requests and 100 responses versus 1 request and 1 response.
It's the same difference as driving 100 cars vs. driving a train with 100 connected train-cars over a narrow bridge etc.
HTTP 1.1 shifted the dynamic a bit, when properly configured.
HTTP 2+ shift the dynamic a lot. When everything is a single reusable shared connection it's a lot more "100 connected train-cars". At that point it's more a matter of request/response header overhead. (And even there HTTP 2+ have interesting mitigations such as Brotli compression and common header dictionaries.)
There's still some difference between one big file and 100 little ones in HTTP 2+, but things are much more complex and a lot of it does start to look like a "wash" (do whatever makes you happy to start, then performance test your specific scenarios once you've got a complete application).
In most browser implementations ESM modules produce "proxy" objects that weak reference un-JITed code until used and will (eventually) garbage-collect portions of the module that aren't ever imported/used by other modules. This can be seen as a sort of "natural" tree-shaking at runtime.
We need more thinking and efforts like this to bring frontend back to progressive principles.
Much of the innovation in the frontend space is now happening outside of the React ecosystem. (Astro, Qwik, Marko as other examples.)
This is all important work if we want to continue to regain our sanity with frontend.
[1] https://github.com/NetCoreTemplates/vue-mjs/blob/main/MyApp/...
The only truthful thing that can be said about the article is that it is "modern".
Today, Java considers the canonical Hello world example to be too complicated because of static main() and System.out.println() and introducing changes to make it easy to write first programs.
I do not know what kool-aid cool kids in Javascript front end world are drinking.
The basic premise was progressive enhancements, javascript augmented your html, but again, never mix.
Another argument was that your web designers couldn't be expected to know or understand javascript, they weren't necessarily programmers, so they should be able to just stay in html and css.