10 ms·
They don‘t start if they use complex frameworks, many dependencies, don‘t use lock files, don‘t lock their package manager and don‘t lock nodeJS and don‘t use D
by quonn 3y ago
They don‘t start if they use complex frameworks, many dependencies, don‘t use lock files, don‘t lock their package manager and don‘t lock nodeJS and don‘t use Docker.
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.
- gofreddygo 3y agoLockfiles aren't a magic bullet. They point to an a specific old version of all internal dependencies. That still requires the maintainer of each of my dependencies to have published a patch to an OLD version when vulns show up. 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.
- quonn 3y agoMany of these libraries cannot have meaningful vulnerabilities. What‘s a possible vulnerability in lodash that can be exploited without already being able to inject code? 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.