I have a slightly different spin on how JavaScript ended up where we are: https://erock.io/2021/03/27/my-love-letter-to-front-end-web-...
JavaScript's Dependency Problem
11–16 of 16 posts
Re: JavaScript's Dependency Problem
#12Not Javascript's dependency problem, but NPM's dependency problem. You don't need to use NPM to build things in JS — it's perfectly feasible to manually load just the scripts you need, and avoid build steps, frameworks, and dependencies.
Re: JavaScript's Dependency Problem
#13> A majority of the dependencies for modern frontend development are only used during development
This is important to note. I think we have to separate non-dev dependencies and dev dependencies. The attitude should be different. One is embedded in the product you deliver the other is only used locally to make the product. No one would say that we should start writing our C++ compiler by hand because "dependencies!".
I think this is an important strength of javascript: the tooling infrastructure. Its ability to embed everything you need into your package.json makes it so easy to start working on a project. I'm old enough to remember the weeks spent trying to get all the licenses, accounts created, software installed and configured in order to just start compiling a project.
This being said, we should also be careful about the tool we're using. If you want to use mustache with express, do not install the dependencies that link them together (mustache-express). Just write the 4 lines of code you need to adapt one to the other, so that you have a better understanding of what's going on and when something fails, you'll not be lost in a sea of unreadable JS code you didn't write.
Re: JavaScript's Dependency Problem
#14The problem is that there is little incentive to "clean up" and move away from the bottomless trough of is-even type packages... similarly, how many front-end tools require one of the many utility packages that effectively just wrap some minor functionality around document.querySelector? Is the problem inexperienced developers? (the article talks about this as well) I'm also curious how many HN readers and JS devs in…
I don't think we talk enough about the downsides of DRY. Reinventing the wheel for the sake of reinventing the wheel (not-invented-here) is a problem, but reinventing it for the sake of learning more about wheels is a big deal. I suppose many developers reach for libraries because they're more confident that the libraries will implement things correctly/more efficiently than they could. But if they keep reaching for…
Most developers work under constant time pressure and usually with a fixed budget. Choices have to be made. Sometimes ugly code will creep in, because doing better is simply not worth the investment. Many projects don't have a very long lifespan anyway.
Pet project usually get a lot more attention, but rewriting existing libraries is not exactly fun and will require maintenance when made public, so that does not happen often.
Re: JavaScript's Dependency Problem
#15Not Javascript's dependency problem, but NPM's dependency problem. You don't need to use NPM to build things in JS — it's perfectly feasible to manually load just the scripts you need, and avoid build steps, frameworks, and dependencies.
Doesn't feel unreasonable to conflate the two. npm is the dominant way to handle dependencies for frontend and backend, even some of the most popular script-tag delivery CDNs are powered by npm (unpkg, skypack).
Coincidentally one of my previous posts was about a no tool approach. https://danthedev.com/web-dev-without-tools/
Re: JavaScript's Dependency Problem
#16Not Javascript's dependency problem, but NPM's dependency problem. You don't need to use NPM to build things in JS — it's perfectly feasible to manually load just the scripts you need, and avoid build steps, frameworks, and dependencies.
Doesn't feel unreasonable to conflate the two. npm is the dominant way to handle dependencies for frontend and backend, even some of the most popular script-tag delivery CDNs are powered by npm (unpkg, skypack). Coincidentally one of my previous posts was about a no tool approach. https://danthedev.com/web-dev-without-tools/
> npm is the dominant way to handle dependencies
Precisely. Which is why it's NPM's dependency problem, not JS's. Avoid NPM and no dependency problems (well, fewer anyway).
Liked your no tool article, but I laughed at this bit: "Traditionally, using other people's code has required some combination of npm and yarn to download those modules". NPM is only 12 years old (and Yarn is newer) — that's less than half the age of JS. No, 'traditionally' you just viewed the source and copied the code you wanted, or went to a project page and downloaded the script.