Nobody argues that a C compiler is worse than assembly or that drivers or an operating system are bad.
Until you need to update a dependency on a large codebase, which takes weeks because dependency A doesn't work with dependency B version X, and updating dependency B means that it no longer works with dependency C version Y, and so on. And nobody uses dependency C anymore -- it's unmaintained, so you need to rewrite everything to use dependency D.
Then you need to repeat this every few months because there's nonstop vulnerabilities flagged and APIs broken.
Nah, I'm good.
If I need one, I have to get that package's dependencies. People don't choose to say "Damn, I'd really love to have 1800 dependencies!" But if you have 4-5, you automatically get dozens or hundreds out of your control.
Yes, could you build everything yourself by hand? Sure. That's a hard sell to many depts/projects. "This will take 3 weeks to build" vs "This will take 4 minutes to npm install". That 4 minutes is introducing a lot of potential risk and headache and time later, but it's providing immediate relief.
FWIW, "dependency management" is a problem in every platform, but I have nowhere near the same number of issues in the composer/php world (nor previously in the maven/java world) as I do in the npm/js world.
But it is worth emphasizing that NPM really does stand out as a hazard compared to package repositories for other dev ecosystems. I believe that dangers are more common, and unpleasant outcomes can be more severe.
I am sure I could fix it in a few hours - either I fix it within 5 hours or you don't pay anything. My hourly rate is 150 EUR and my email is in my profile.
Oh, that's the wrong yarn version. Oh, I thought v3 is the newest? But we still use v1? I used v3 in another project. So I need to install different versions? Ah, then I also need different versions of node? Ah, better to use nvm? Because only later versions have corepack, the experimental but recommended tool?
Or do we change back to npm? And why does an install process change a .lock file?
Person A: "Hey, so I ran bundle update and it's not working."
Person B: "You updated the dependencies? WHY WOULD YOU DO THAT!"
I've had a codebase that sat for as little as 6 months without me touching it. When I tried to run it again, I ran into so many compatibility issues that I had to tediously copy out all of my code into a new project and then fix the remaining issues with my code itself.
Web dev build systems are dependencies on top of dependencies on top of dependencies, and they're all introducing breaking changes every other week it seems.
Of course not. It just avoids that the build system *automatically* updates X to 1.2.3 and *accidentally* breaks your code. But when it's time to bump the version up a notch, that very fragile equilibrium may suddenly crumble.
Lock files are not a substitute for sane dependency management.
Nobody in their right mind thinks you can change major versions without some elbow grease in any other language.
I have an old project that I didn't touch in more than 5 years. Last week, I decided to give it another spin, and booked the entire afternoon to deal with any issues that may arise from the update process.
It went from Python 3.6 to 3.11, and from Django 2.2 to 4.2. Postgres jumped from 11 to 16! There were 10 other libraries (PIL, ...) that I had to update too.
The only special procedure that I had to do was dumping data from the old database and restoring it from the new one, as recommended by PG when doing major-point updates. (And adding a single line to Django's `settings.py` for the new `CSRF_TRUSTED_ORIGINS`.)
When I typed `docker compose up` on my terminal, the app just run smoothly without as single problem. I even had to check that I didn't invoke the old configuration by mistake.
All in all, the process took me less than 15 minutes.
There's something seriously wrong with modern front end tooling when the norm is downloading hundreds of dependencies to display semi-interactive text in a browser.
I think you mean thousands.
See:
If a particular application has 10 patterns that support all the applications UI interactions, then a simple, constrained solution like htmx that supports those 10 patterns is preferable (to me) than an unconstrained solution like Typescript + React where each developer will likely use their creativity and experience to design slightly or wildly bespoke solutions for each feature.
- Build tools are complex
- Large FX's have 100's of npm dependencies
- Every SPA I've created has suffered from bitrot overtime, including:
- Often breaking changes on upgrade, incompatibility between package versions
- Dependencies/tools/fxs often abandoned, rewritten, replaced, etc
- Constantly wasting time working around issues
- Doesn't scale, the larger the App, the slower initial load and slower the FCP
- Heavy client state and need to manage client routing
[1] https://world.hey.com/dhh/you-can-t-get-faster-than-no-build...
Problem is why do we even need one? All I'm trying to do is for my client code to update a part of the page and not the entire page. Why do I need to even introduce concepts of bundling and transpiling for this pig-headed simple task ?
Further, react has a steep learning curve that a backend person need not be subjected to. And it evolves, so that search-copy-paste phase just never ends.
And then dependencies update. Another comment here details why that is a nightmare.
If you want to feel the pain, search for any react project from 2 years ago on github or even some showhn projects here. Literally none of them even start !
So you see htmx does address a group just like react does. Its a tool and it's great at what it does.
And most applications are far more complex than just needing to update a small part of the page.
If they use plain TypeScript and plain React, have a lock file, lock their package manager version and lock their nodeJS version and optionally ship a sane Docker setup they will certainly run.
It is true that it would be nice to have a single tool that combines a bundler, typescript, linter, prettier, package manager and runtime and have it all configured with reasonable defaults from a single file and not 5 configs. And people have tried this lately, with approaches like deno and bun. But it‘s difficult to get these adopted.
Still, it would be better for someone to take all these tools and freeze them in place or even fork them and then freeze them with only bug fixes coming, rather than throwing out 10 years of progress and going back to something that just doesn‘t work.
And the alternative of typscript + react + nodejs + npm + docker for a damn web based UI is just terrible ! Sorry, no bueno.
I don't want to be at the mercy of all the maintainers of my dependencies. So clearly, I need to cut down on my dependencies. htmx is a great middle ground. Clearly, you can now at least see the appeal of htmx + a backend service for a robust though not fully optimized web based app.
And I can't see the JS ecosystem's last 10 years as outright "progress", but rather a series of experiments, that work for some and don't for others.
Furthermore, any vulnerability in a dependency could also exist in code written by myself or a team member. And then never get fixed or even found.
I actually did laugh out loud.
Even then, most of the times it doesn't take even an hour because majority of people will grab default config or use something that allows no-config (parcel, vite, etc)... Some are fine with default CRA for a long time until they really need something custom, for example.