It's 3KB. Even less if you opt to not have any React compatibility at all.
Alpine is 13KB.
Until that I believe this argument is equivalent to “what about Mars”. By supporting dead slow connections on Earth you simply support them to remain so.
Literally none...this is just the argument of contrarians or people who've only ever worked on personal projects who take offense to real applications used by actual audiences.
Inflating the document size does impact paint time, but it scarcely matters here.
You don't embed same piece of code on every page request but instead you make the code cached on first download.
It works well. You end up with HTML like:
<div data-controller=“component” data-name-component-value”example” data-props-component-value=“{a: 1}”></div>
And no, `package.lock` is not enough of a solution, because you will have to update dependencies at some point. Congrats, you now have multiple moving, breaking parts in your dependency tree that throw the weirdest and unrelated errors. So you're hunting down github issues, workarounds and patches, while still not really knowing what the problem was. The bonus here is that you need to remove these workarounds at some later point because your build tools and libraries have fixed the issues, so your code breaks again with very fun error messages or just straight up opaque and weird behaviors.
At some point we have to ask why we're doing this to ourselves. It's not fun at all.
Even a basic application requires layers upon layers of dependencies. Many of them are not as mature as people like to think either.
Any notable examples? (apart from that “force everyone ESM overnight because we feel like” movement)
Basically touching a JS project that hasn't been updated monthly is incredibly anxiety inducing.
And now there are several new build tools since a relatively short while, which makes the issue even worse. They might be improvements in some dimensions but they all invent their own little world again, promising this or that. But it all sounds so familiar and I already lost trust.
Rollup has always been a straightforward path. Vite (built on rollup) is super clean. Before that even, webpack was relatively stable between versions.
If you just used Gulp / Grunt / Browserify I am a little more sympathetic, especially with Grunt / Gulp, but I always felt their limitations were obvious.
Browserify somehow managed to snatch defeat from the jaws of victory IMO
I'm just not sure where the churn is from. If you're talking about meta frameworks, like create-react-app, that churn alot and change things underneath, I get it, though with tools like that, one should always seek to stay on the happy path only, as its otherwise a recipe for disaster.
Change, sure. We've had browserify, parcel, rollup, webpack. Then the next wave hit with snowpack, esbuild, vite, lasso, turbopack etc.
There's a few that have hung around like rollup and webpack, but there's definitely a constant feel of chasing the dragon when it comes to js bundlers/builds, if not JS tooling as a whole.
I've had compatibility issues with rebar, rubygems, pip, go modules and many more.
Once you're pulling in third party dependencies and the tools that manage them - in any development environment - you open yourself up to these issues. At some point, you have to update dependencies and/or tools (for security reasons if nothing else). And at some point, either the dependencies or the tools will break in a way that has you hunting down issues and workarounds that are outside the scope of what you're actually trying to accomplish.
Is JS significantly worse in this regard? It does seem like the propensity for many small packages increases the surface area of things that can go wrong, but that doesn't seem to be a flaw in the tooling.
And yes that means that bigger surface area leads to more problems.
This is less severe if you are only working on few projects at a time that you gradually update. It still sucks and is completely unnecessary, but only in tiny bits over a spread out time period.
However if touch code from just a year ago, then you might get some of these fun, breaking changes and bugs. Even more fun if you're not familiar with the build tool, or the packaging tool, because there are a dozen of those around as well and someone decided to use X at the time because why not. And you need a specific version of those too.
The Go modules thing is similarly painful, but it's not the best example of what I describe, because there is a very clear cut change from the previous way of doing things. It sucks but there is a clear path forward. With a JS project you get the feeling that you are walking on a minefield.
But I mentioned them for the usually very vocal crowd on HN (and others) that dominate any JS orientated conversation by pissing and crying that build tools exist.
Apparently, to this crowd, the act of compiling code is perfectly OK everywhere else but a travesty to need or want to do any of that for software that runs in a browser. Weird.
However, the kinds of problems that existed in 2015 thanks to detracting tools like WebPack and Babel don't really exist now with the fact that browsers support ES modules and Node is dragging its heels but now mostly supports ES modules.
With things like typescript and vite I now never have the problems that used to be common. In fact when I see people creating brand new projects in 2023 using WebPack I cry a little in side.
At some point having a bad tooling experience can't be solely blamed on the tools. It's a choice.