Is python and pip more stable in this regard?
I need a scripting language with a robust library, and I’ve seem first hand how difficult NPM projects can become.
Programs are dead, and JavaScript has killed them
131–140 of 216 posts
Re: Programs are dead, and JavaScript has killed them
#132Earlier quoted context omitted.
> Your projects also need to consider pinning their dependencies to a specific version At that point, you should consider just using your version control system to handle versioning instead of trying to route around it, poorly.
As a long-time ruby user where bundler has done version pinning for decades, I think this is a core feature of any dependency management system, not some kind of "routing around it." I'm not sure what "your own version control system" means. Checking all dependencies into (eg) git? I'm not sure how you deal with indirect/second-level dependencies, but any kind of roll your own like that to me is what I'd call "routin…
> I'm not sure what "your own version control system" means.
Me neither. Where did that come from? I didn't write it. (It's not in my comment, just yours.)
Re: Programs are dead, and JavaScript has killed them
#133My experience is pretty similar for my projects but I think generally we shouldn’t point too many fingers. When it comes to public projects, I’ve found a lot of trouble regardless of its JavaScript-proximity. I think we’ve been blessed by a growing ecosystem of projects that are clean to build, and eschew problematic dependencies. Try building anything Linux and C related and you’re worse than JS because now you need…
Yeah, people are jumping the horse to claim any dev environment is superior and free of issues like this. I've contributed to some open source C++ projects and a lot of js/node projects, and in my experience, every C++ project is an adventure just to get the project compiling (it can be smooth running if the maintainers have a recently-updated guide specifically for your exact OS/distro version and the right versions of all the dependencies are in your distro's package manager, but anything off of this happy path is an ordeal, especially the case where you're working on another C++ project that wants a different version of the same dependency) while nearly every js/node project was up and running after just "npm install". Sure, it can go wrong and harder than that sometimes but it's worth appreciating that the standard case is pretty good.
Every project using native binary dependencies is prone to running into the kinds of dependency issues described in the OP article. I've run into similar situations with Java, PHP, and Python where there was some mismatch with a language library, a native binary, and my OS. I'm a fan of it when projects try to minimize their native binary dependencies for this kind of reason. Some js/node projects that have previously used a native binary dependency now use non-OS-specific WebAssembly binaries instead, which is great for how it removes potential issues.
Re: Programs are dead, and JavaScript has killed them
#134Earlier quoted context omitted.
I was going to say the same but I think you said it much more clearly than I would have. I see this meme a lot. "I hate X, don't learn X, Y is better because Y is fundamental to Z". I have not once seen these same people suggesting "Don't learn the toolkit/framework/control library for your OS, instead use raw WinAPI or X System calls and push raw pixels to build applications". Yet, they push for the same with HTML.…
The difference is, that JS, CSD and HTML are evolving. They now offer way more than they used to. We can do so much with HTML 5 and CSS 3 already. The argument is to not use React or similar, when a simpler way using standard conform means is available. It is hard to take a comment serious which compares not using React to not being able to do anything productively. It looks like a very junior React-only dev comment.
> The argument is to not use React or similar, when a simpler way using standard conform means is available.
Please show me which part of any current or future proposals show a declarative UI + state + input + template binding mechanism which React or even something like handlebars provide.
If you're going to mention three or four different API's and explaining combining them together, then you've just reinvented a worse X framework.
You can't just dismiss everything as "well you can do X with the native platform" which is literally what I'd already made an analogy for.
> It looks like a very junior React-only dev comment.
Personal attacks, nice. If you believe I'm a junior for my comments then you are free to believe what you want, it does not change reality.
Re: Programs are dead, and JavaScript has killed them
#135Earlier quoted context omitted.
I refer to .net as the language a lot of the time too, they are tied even more strongly together, as described in https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... . I'm probably just not being precise about the language. I'm happy to pin this on NodeJS but Node is the key reason why javascript is used for any non-web work at all and it's almost impossible to separate that. The javascript ecosystem and…
> the javascript ecosystem is node It's not. NodeJS is NodeJS. JavaScript is JavaScript. The James Webb Space Telescope isn't running Node LTS or pulling in left-pad. If you want to make a lateral move and draw comparisons elsewhere: the Java ecosystem is not Sun/Oracle's mobile platform—which never took off, while Android thrives. Languages are absolutely separable from the big loud noisemaker (and the problems they…
But when I say "javascript ecosystem", I'm talking about Node, and that's clear from my writing.
I don't care for pedantry about what it might also refer to, I'm talking about NodeJS, npm and the problems with it, and that's clear because that's also what the original article is talking about.
Re: Programs are dead, and JavaScript has killed them
#136Earlier quoted context omitted.
Bash scripts don’t break, when left unattended for months/years. Python scripts do.
Pin your versions. Also - to make the equivalent safe bash program compared to a typical python implementation is ... a lot of work. Enough that imo the python version is worth the maintenance.
Pinning versions doesn’t help when the old version of some dependency no longer works with your new OS or hardware.
I mostly only code in Python but this article really spoke to me. I have Meanwhile my two old Autohotkey scripts that I wrote 10+ years ago and rarely touch still chug along perfectly.
Re: Programs are dead, and JavaScript has killed them
#137Earlier quoted context omitted.
As a long-time ruby user where bundler has done version pinning for decades, I think this is a core feature of any dependency management system, not some kind of "routing around it." I'm not sure what "your own version control system" means. Checking all dependencies into (eg) git? I'm not sure how you deal with indirect/second-level dependencies, but any kind of roll your own like that to me is what I'd call "routin…
> I'm not sure what "your own version control system" means. Me neither. Where did that come from? I didn't write it. (It's not in my comment, just yours.)
Ah apparently my brain inserted `own`, looking back you said "just using your version control system". OK, I think I'd write the rest of my comment the same still; does it mean putting all your dependencies (source/binary) in your version control (eg) git?
Re: Programs are dead, and JavaScript has killed them
#138Earlier quoted context omitted.
> "why i moved mostly from writing node cmd tools to using bash" You literally moved from one unmaintainable mess of an ecosystem (Node), to what is arguably an even worse unmaintainable mess of an ecosystem (bash). Glad to hear it wasn't Perl though. For self-contained little tools or hobby projects that can run cross-platform, use Python. For anything beyond that - use a proper strongly typed language (C, C++, C#,…
Bash scripts don’t break, when left unattended for months/years. Python scripts do.
It can’t break if it were never correct in the first place. Bash scripts are always chock-full of bugs, and only work when everything in its environment is the same. That folder now has two files instead of one? Now it just stops working.
Re: Programs are dead, and JavaScript has killed them
#139Meh, I feel a little like this is dunking on Javascript for the sake of dunking on Javascript. Ever done the same with a PHP app? Go? Python?! They all have issues with versioning and this is why there are a good set of tools to deal with it - pyenv/nvm etc. It's like they've listed all the good reasons to use JS and then kicked it because it's cool to hate on JS. Hi, I am Darren, and I love JS - I will no longer be…
> They all have issues with versioning Not on this scale. Let's leave out the versions of the NodeJS for clarity's sake (nvm is not for managing packages, afaik), and focus on packages. You could argue that the complexity is because of JavaScript's popularity, but it's hard to deny that running a seemingly simple `npm install` will net you tons of dependencies, and that's typical regardless of what you're installing.
Yeah this is really the Achilles heel of the node ecosystem. It turns out having an expansive standard library is important since I'd like to think most of these issues would disappear if that were the case.
Re: Programs are dead, and JavaScript has killed them
#140> During the past 5–6 years of my JavaScript experience, every time I wanted to go back to any of my projects—from tiny to big, server-side or front-end—there was always a challenge, a problem to tackle or an obstacle to overcome before I can update or sometimes even just run my program. why i moved mostly from writing node cmd tools to using bash. don't need to go on a bunch of side missions every time i run npm ins…
Why learn cmd and bash when you can just learn js? Easier to maintain 1 language than 1+. My software in js from 7 years ago still works.
My scripts in ksh from 25 years ago still work.