I’ve been working with the understanding that NPM package dependency hierarchies are deep because the browser API environment did not provide much in the way of a standard library. Therefore tiny packages are useful enough to distribute and get versioned instead of ignored, and large packages will bring many others with them. The platform is low, so the stack goes high. Then packages get versioned at high frequency, often cascading through dependency trees.
But that’s just how it went, because despite its limitations, the JavaScript environment is the web, and the web is where it’s at. Location, location, location.
A way out of the mess is for the language to level up so we don’t feel the need for Babel, and for the most wanted third party things to be added as standards, like web components. That has been happening, but the mess of packages is still there and growing. We need to wean ourselves off of huge dependencies that bring the kitchen sink with them and get on standards for our dependency graphs to become shallow and livable.
This is a long argument, but I think programmers should avoid “pyramid-shaped” and hard-coded dependency graphs.
Package managers like npm and Cargo encourage this style of programming (“pile some more stuff on top”) with their notion of transitive dependencies. I also had a lot of experience with this at Google – people would always complain why building a low level web server linked in code maintained by the maps team, or things like that. Or why changing an application header unexpectedly caused you to need to rebuild the world.
It was always a transitive dependency problem. (Incidentally, that’s the genesis of the “include what you use” tool that was on the front page yesterday.)
What results in smaller and more stable software is if you program to interfaces rather than implementations, in the style of dependency inversion. Unfortunately it seems like there is no package manager that works like that.
sqlite and Lua are 2 examples of pure libraries that “invert” all their dependencies. They make them all optional and have well defined and documented interfaces.
They don’t depend a huge pyramid of libraries – you can build them with just a C compiler.
Yes. It is the kind of thing that would pass as an hyperbolic joke if it wasn’t reality already.
You should check the left pad fiasco. TLDR: developer got salty over loosing a bunch of GitHub stars to a 3 letter name collision by a registered brand. Ends up breaking half the web.
JavaScript’s ecosystem grew up at a time when three things were true: open-source was completely established from the get-go; “everyone” (for loose values) needed to write at least some JavaScript; and the delivery platform (the browser) arrived before the actual development strategy was really understood. So what you got were multiple efforts to figure out how to build things, done in parallel, done differently, without learning from one another, where no one solution was going to be The Solution, and where the people writing the development tools were (in general) not the same people writing the deployment platform. Throw on top of that users who were, to a greater extent than many other previous platforms, going to be a mix of both professional developers and newer developers to JavaScript, development in general, or both, and you here you are.
I make that qualification for two reasons. First, any time a language is easy enough, and wide-spread enough, that it attracts tons of amateur developers, it gets a reputation for having a crappy ecosystem. Happened to Windows, happened to PHP, and has now happened to JavaScript. I’m not going to say that Webpack is awesome (it isn’t) or that the mainstream frameworks don’t have issues (they do), but I don’t feel that, on balance, the issues we’re facing are worse than what Python, PHP, Java, or a half dozen other languages went through when they were at the apex of their popularity. Maybe bigger, just because so many more developers are around, but not actually worse.
Second, the sheer size of the ecosystem–the same thing that is attracting so much of a “donkey circus”–also means that, to a greater extent than in any other language I’ve used, there is always a good, high-quality library to do whatever I want to do. There will be 67 awful ones and six that are more popular than they should be without working quite right, but there will be at least one that does exactly what I need, and does it well. So I kind of view the pile of nutsitude as the payment to get into that ecosystem.
I think this is very important to highlight. Every couple of years I see a new library or 2 that rise in popularity that repeat the same mistakes other libraries did a few years prior. They almost always have a claim along the lines of “____ done right!” Within a year or 2, if they remain popular, they end up having to overhaul the framework to get rid those flaws.
A lot of this is due to developers flipping their shit if a library doesn’t meet their aesthetics exactly, or is just a little harder to use or has just a little boilerplate or whatever. Weeks of writing code can save minutes of typing.
I think there are two important points being missed here and in almost all discussions I see around this. First, JS is many many people’s first language, and so half the libraries (especially ui) are just magic and programming is impossibly difficult; and then suddenly you get it, and you can actually start doing something half decent, and so of course you want to tell the world! So I think we owe these developers a bit more compassion than what we currently are giving them. That’s not to say that it’s great with 50 new ui libraries every week; but I can certainly empathise with whoever wrote one if it’s their first big thing. Good for them!
Second, updating a user interface in the browser based on partial and updating data is a surprisingly difficult problem to solve, and so a new ui library with a slightly new take isn’t always meant as something anyone should use in production; but rather an experiment, or input to the global discussion on how this should be done best.
Of course not everything falls into these two buckets, but a certain percentage does. At least let’s be kind to the people in the first bucket :-)
I think it’s also important to note that the folks behind the language did it no favors in dragging their heels towards adding the standard library stuff that would’ve prevented some of the crazy. They had their reasons, but the error is manifest.
Yes and no. The fact is that the turnaround is much faster, major libraries and frameworks go at a quick pace. Also the tooling is getting a lot of improvements. So you have to stay on top of it or stay behind.
But for any serious work, you pick stable frameworks and plan ahead.
What the post is complaining about is a project in Vue 2 be Vue 3. Almost like python situation. If someone told you “I wrote this shit in Java 8, and it doesn’t work on 11”, people would just say “well yeah”.
But as said, we have faster turnaround on front-end plus we upgrade not just the framework, but also build systems, libraries, tools. So while you had a some changes between Java 8 and 11 and, say, what some library did in one or the other, at least intellij or eclipse or whatever was it did not break as well.
So, yes, it’s a fast paced action game, not an old school turn based strategy. But people who learn to play it can get pretty good at it and almost never even feel the RSI in their hands from to much clicking.
May be so, but that’s not experience. Granted I don’t work with Java-anything but have experience and I remember it being so silly that you’d need an exact minor point version of some dependencies on exact minor jre or else things would not work. So you’re in the same situation like the OP. You can’t upgrade to a new version of X, because Y does not have a working new version.
It’s probably not always so, but it does happen. Maybe not as complicated as in the article, but enough to prevent you from upgrading.
There is a firm-ish boundary if/when a project switches from classpath to modules, and a couple of things from AWT and Applets that no longer work, but other than that I’ve never heard of the JVM breaking anything, let alone requiring a specific point-release.
Yes but we’re not talking about JVM out v8 here. We’re taking about libraries and frameworks and other deps.
Take an app written with spring 2 or something. It all works, right? But now use Spring boot instead. Majority of your code no longer works, right? That’s the problem the article is describing and that’s what I’ve meant when I said dep management is bad in js but it’s not like it’s all peaches in other languages.
IMO this all started with NPM’s decision to advocate for huge dependency trees of small packages. Really this “I’m exhausted from running on a treadmill of maintenance” outcome is baked into the entire JS ecosystem at this point. The only way to avoid it is to use a different language and ecosystem.
That’s pretty much why my old, small apps will never update to Vue 3. I’ll use it for new stuff, because it is a devex improvement, but things that already work? No compiler, no bundler, just inline scripts and “<script src …” to load Vue 2 - it makes my life simpler. (Yes, I understand that approach won’t work for larger projects)
If you’re creating something small, I recommend giving it a go. Like it’s 2013 and jQuery 2 just dropped.
What I would like to point out is this: the author reached for a nice and productive tool, vue 2 and built his thing quickly. What the problem here is, is maintenance. On top of all other comments here, I would just like to add that. You use a framework or a library means that you’re tied to its future.
Not that the complaints aren’t valid. Just that this kind of mess is a normal kind of mess for any system where you get tied into third party code.
I’ve been working with the understanding that NPM package dependency hierarchies are deep because the browser API environment did not provide much in the way of a standard library. Therefore tiny packages are useful enough to distribute and get versioned instead of ignored, and large packages will bring many others with them. The platform is low, so the stack goes high. Then packages get versioned at high frequency, often cascading through dependency trees.
But that’s just how it went, because despite its limitations, the JavaScript environment is the web, and the web is where it’s at. Location, location, location.
A way out of the mess is for the language to level up so we don’t feel the need for Babel, and for the most wanted third party things to be added as standards, like web components. That has been happening, but the mess of packages is still there and growing. We need to wean ourselves off of huge dependencies that bring the kitchen sink with them and get on standards for our dependency graphs to become shallow and livable.
This is a long argument, but I think programmers should avoid “pyramid-shaped” and hard-coded dependency graphs.
Package managers like npm and Cargo encourage this style of programming (“pile some more stuff on top”) with their notion of transitive dependencies. I also had a lot of experience with this at Google – people would always complain why building a low level web server linked in code maintained by the maps team, or things like that. Or why changing an application header unexpectedly caused you to need to rebuild the world.
It was always a transitive dependency problem. (Incidentally, that’s the genesis of the “include what you use” tool that was on the front page yesterday.)
What results in smaller and more stable software is if you program to interfaces rather than implementations, in the style of dependency inversion. Unfortunately it seems like there is no package manager that works like that.
sqlite and Lua are 2 examples of pure libraries that “invert” all their dependencies. They make them all optional and have well defined and documented interfaces.
They don’t depend a huge pyramid of libraries – you can build them with just a C compiler.
As someone who has never and will never write, build and deploy JavaScript — is it really this much of a donkey circus?
Yes. It is the kind of thing that would pass as an hyperbolic joke if it wasn’t reality already.
You should check the left pad fiasco. TLDR: developer got salty over loosing a bunch of GitHub stars to a 3 letter name collision by a registered brand. Ends up breaking half the web.
Yes, but: I think that can be misleading.
JavaScript’s ecosystem grew up at a time when three things were true: open-source was completely established from the get-go; “everyone” (for loose values) needed to write at least some JavaScript; and the delivery platform (the browser) arrived before the actual development strategy was really understood. So what you got were multiple efforts to figure out how to build things, done in parallel, done differently, without learning from one another, where no one solution was going to be The Solution, and where the people writing the development tools were (in general) not the same people writing the deployment platform. Throw on top of that users who were, to a greater extent than many other previous platforms, going to be a mix of both professional developers and newer developers to JavaScript, development in general, or both, and you here you are.
I make that qualification for two reasons. First, any time a language is easy enough, and wide-spread enough, that it attracts tons of amateur developers, it gets a reputation for having a crappy ecosystem. Happened to Windows, happened to PHP, and has now happened to JavaScript. I’m not going to say that Webpack is awesome (it isn’t) or that the mainstream frameworks don’t have issues (they do), but I don’t feel that, on balance, the issues we’re facing are worse than what Python, PHP, Java, or a half dozen other languages went through when they were at the apex of their popularity. Maybe bigger, just because so many more developers are around, but not actually worse.
Second, the sheer size of the ecosystem–the same thing that is attracting so much of a “donkey circus”–also means that, to a greater extent than in any other language I’ve used, there is always a good, high-quality library to do whatever I want to do. There will be 67 awful ones and six that are more popular than they should be without working quite right, but there will be at least one that does exactly what I need, and does it well. So I kind of view the pile of nutsitude as the payment to get into that ecosystem.
I think this is very important to highlight. Every couple of years I see a new library or 2 that rise in popularity that repeat the same mistakes other libraries did a few years prior. They almost always have a claim along the lines of “____ done right!” Within a year or 2, if they remain popular, they end up having to overhaul the framework to get rid those flaws.
I.e. there’s a lot of building blindly
A lot of this is due to developers flipping their shit if a library doesn’t meet their aesthetics exactly, or is just a little harder to use or has just a little boilerplate or whatever. Weeks of writing code can save minutes of typing.
I think there are two important points being missed here and in almost all discussions I see around this. First, JS is many many people’s first language, and so half the libraries (especially ui) are just magic and programming is impossibly difficult; and then suddenly you get it, and you can actually start doing something half decent, and so of course you want to tell the world! So I think we owe these developers a bit more compassion than what we currently are giving them. That’s not to say that it’s great with 50 new ui libraries every week; but I can certainly empathise with whoever wrote one if it’s their first big thing. Good for them!
Second, updating a user interface in the browser based on partial and updating data is a surprisingly difficult problem to solve, and so a new ui library with a slightly new take isn’t always meant as something anyone should use in production; but rather an experiment, or input to the global discussion on how this should be done best.
Of course not everything falls into these two buckets, but a certain percentage does. At least let’s be kind to the people in the first bucket :-)
I think it’s also important to note that the folks behind the language did it no favors in dragging their heels towards adding the standard library stuff that would’ve prevented some of the crazy. They had their reasons, but the error is manifest.
Yes and no. The fact is that the turnaround is much faster, major libraries and frameworks go at a quick pace. Also the tooling is getting a lot of improvements. So you have to stay on top of it or stay behind.
But for any serious work, you pick stable frameworks and plan ahead.
What the post is complaining about is a project in Vue 2 be Vue 3. Almost like python situation. If someone told you “I wrote this shit in Java 8, and it doesn’t work on 11”, people would just say “well yeah”.
But as said, we have faster turnaround on front-end plus we upgrade not just the framework, but also build systems, libraries, tools. So while you had a some changes between Java 8 and 11 and, say, what some library did in one or the other, at least intellij or eclipse or whatever was it did not break as well.
So, yes, it’s a fast paced action game, not an old school turn based strategy. But people who learn to play it can get pretty good at it and almost never even feel the RSI in their hands from to much clicking.
No, that’s basically the opposite of how Java works.
May be so, but that’s not experience. Granted I don’t work with Java-anything but have experience and I remember it being so silly that you’d need an exact minor point version of some dependencies on exact minor jre or else things would not work. So you’re in the same situation like the OP. You can’t upgrade to a new version of X, because Y does not have a working new version.
It’s probably not always so, but it does happen. Maybe not as complicated as in the article, but enough to prevent you from upgrading.
There is a firm-ish boundary if/when a project switches from classpath to modules, and a couple of things from AWT and Applets that no longer work, but other than that I’ve never heard of the JVM breaking anything, let alone requiring a specific point-release.
Yes but we’re not talking about JVM out v8 here. We’re taking about libraries and frameworks and other deps.
Take an app written with spring 2 or something. It all works, right? But now use Spring boot instead. Majority of your code no longer works, right? That’s the problem the article is describing and that’s what I’ve meant when I said dep management is bad in js but it’s not like it’s all peaches in other languages.
Yes, for many reasons, most of which will never be addressed.
The jank will continue until foresight improves.
IMO this all started with NPM’s decision to advocate for huge dependency trees of small packages. Really this “I’m exhausted from running on a treadmill of maintenance” outcome is baked into the entire JS ecosystem at this point. The only way to avoid it is to use a different language and ecosystem.
That’s pretty much why my old, small apps will never update to Vue 3. I’ll use it for new stuff, because it is a devex improvement, but things that already work? No compiler, no bundler, just inline scripts and “<script src …” to load Vue 2 - it makes my life simpler. (Yes, I understand that approach won’t work for larger projects)
If you’re creating something small, I recommend giving it a go. Like it’s 2013 and jQuery 2 just dropped.
What I would like to point out is this: the author reached for a nice and productive tool, vue 2 and built his thing quickly. What the problem here is, is maintenance. On top of all other comments here, I would just like to add that. You use a framework or a library means that you’re tied to its future.
Not that the complaints aren’t valid. Just that this kind of mess is a normal kind of mess for any system where you get tied into third party code.