36 ms·

Programs are dead, and JavaScript has killed them

125 points by poeti8 4y ago

iamsaitam 4y ago
npm ci is your friend.
- flohofwoe 4y ago
  It's partly a solution, but doesn't help when the 'enviroment' (OS, Node, compiler toolchains used in dependencies) has moved on and is no longer compatible with the old version-pinned npm packages, the same problem also exists in other programming ecosystems (just maybe not as extremely - but I have the same bad experience each time I want to write a blog post, because Jekyll usually breaks after a macOS update). It's not Javascript or Node.js or NPM which is the problem though, but the 'culture' of offloading every little detail into its own dependency, nothing in the Javascript ecosystem technically requires this approach.
- fuzzy2 4y ago
  Sure, but this friend is also changing. Suddenly now it verifies peer dependencies. Oops.
  - janpot 4y ago
    "yarn set version" could become your new friend? https://yarnpkg.com/cli/set/version https://yarnpkg.com/cli/set/version
5350-uiop-1130 4y ago
> 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 install not enough pragmatism in the JS community (people). more about hot new thing as opposed to boring long term stability. maybe because of web/chrome as a constantly moving platform, and Apple/Jobs app-ification of everything, relative young age of JS community.
- Gibbon1 4y ago
  A month ago I found a bug in command line utility I wrote in C# and hadn't touched in 8 years. I checked out the project and opened it in Visual Studio. And it compiled. I fixed the bug and it just worked. End to end it took half an hour. I feel like there is an advantage to libraries and tools managed by adults with long term skin in the game.
  - hutzlibu 4y ago
    As a counter point: I have simple node scripts, that serve the same purpose to me. And there was also the need to fix something 2 days ago in an 8 year old script. Opened the file, changed the code and running it again. Took 5 minutes and it just worked. I don't use js because it is the hot new thing, but rather because it is simple. (But I avoid messy and obscure npm repositories wherever possible for example.)
    - yakshaving_jgt 4y ago
      > I don't use js because it is the hot new thing, but rather because it is simple. It infamously isn't. https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
      - hutzlibu 4y ago
        Hm, video arguments are not my take, I did not watch it (yet), but in either case this seems to be opinion. But of course, javascript is so simple, that it is not suitable for complex problems. No (sane) person would ever claim, that it is the right language for every problem.
        deleted 4y ago
        [deleted]
        yakshaving_jgt 4y ago
        Are you familiar with the No True Scotsman logical fallacy?
Tade0 4y ago
I experienced the same issues and to me the main culprit appears to be the dumpster fire that is the ongoing transition to ES2015 modules. Also Node v18, while full of new, important features(like the built-in test runner) feels... kinda unstable? I had to downgrade to v16 because I had segfaults. Also had to make it use jemalloc due to memory leak issues when it used the default allocator. I went into this platform specifically not to deal with such problems.
- qazxcvbnm 4y ago
  Just want to add that node unfortunately gives me segfaults in unexpected places too, often (seemingly randomly) during the first second of execution when I'm trying to debug it by running node under --inspect-brk...
  - Tade0 4y ago
    Something is indeed off here. Even Node 0.x didn't have so many problems (granted, the debugger back then, ahem, left one wanting).
yazaddaruvala 4y ago
We are probably at the tipping point where the JS engine should now be part of the kernel and run in ring 0.
- m00dy 4y ago
  If that kernel is linux kernel, then linux kernel should userspace app in js kernel.
- hnbad 4y ago
  I see you haven't watched this talk about the history of JavaScript between 1995 and 2035 since that's exactly what happened in this future: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
  - yazaddaruvala 4y ago
    I have! It's a very good talk. I wouldn't make any design or technology decisions based on it tho. What is clear today is that Javascript is on every computer in the world (including phones). It is now even taking over for native desktop apps and native mobile apps. At this point, including a JS engine into all the kernels for apps and browsers to use just seems prudent.
    - kingboss 4y ago
      JS in kernel is a beyond idiotic idea. Why the hell would you put something like that in the kernel? Computing world has lost its mind if this can even come up as a suggestion. I just feel that 90% of people on this website are junior web devs. That must be the reason for the glorification of a POS language such as JS. Why the hell would you even want to run this garbage language on the server? Now you want it in the kernel? Insanity....
      - yazaddaruvala 4y ago
        lol, are you familiar with ring 0? what about context switching and scheduler preemption? If you are, then you know they add significant overhead to IO bound applications. > Why the hell would you put something like that in the kernel? Because some ridiculously large % of all client software is written in/transpiled to JavaScript? If the JS/WASM runtime would be run with the correct sandboxing (similar to browsers like Chrome), you likely could run the entire application in ring 0 and only context switch because of scheduling preemption. Maybe even ouch the whole browser into the kernel? All runtime APIs that currently need “syscalls” would become significantly more efficient. You’d end up with an extremely performant system for running browsers and browser like apps (ie Electron).
martyalain 4y ago
I agree with you. Now, thanks to JS and web browsers, anybody has access to a wide eco-system via a small interface. This is mine : http://lambdaway.free.fr/lambdawalks/ http://lambdaway.free.fr/lambdawalks/ with which I can play and explore lots of funny algorithms.
papito 4y ago
In the early 2010s, the industry was dominated by mature and stable ecosystems, such as Python/Django and Rails. Then Node came about, and when it was still extremely immature, it got a ton of attention as an army of front-end devs started to flock to it. "We are backend engineers now too!". Doesn't work that way. Node has been basically re-learning all the lessons learned a long time ago, and many lessons it didn't learn at all. The fact that the FAANG alumni then joined the orgy and reminded us that we are all lame because we really need to be doing distributed systems for everything (for the young ones - microservices), did not make things simpler. Leave a JS project unattended for a few weeks and I go back to it with a sense of dread. What horrors await me? In contrast, I dusted off an old Flask project from 8 years ago, upgraded the dependency manager, the major Python version, 2-3 hours and off I go.
- eternalban 4y ago
  This was a relatively mild but necessary rant. > re-learning all the lessons learned a long time ago Because this is the same crew that sailed on the ship that sang the "over 30 is over the hills" song. In fact, wasn't our own /u/pg cheering this 'very wrong idea' of completely discounting experience on the side? Surprise, surprise. Experience actually matters.
  - hnbad 4y ago
    But hiring college graduates is so much cheaper and they are so much easier to dazzle and don't have any outrageous demands like being able to spend time with their family. Why hire for quality when you can make it up with quantity?
- flohofwoe 4y ago
  > by mature and stable ecosystems, such as Python... Nothing I experienced in the JS ecosystem so far was as nearly as painful as the over a decade-long transition from python2 to python3, and now python3 has the same 'move fast and break things' mindset. It's kinda infuriating for use cases where python2 was more than good enough.
  - 4y ago
thorncorona 4y ago
The only reliable solution to this that I have found is compiling an app into a docker container and ensuring my projects are able to run off a SQLite database. I then save this to my NAS. Otherwise literally everything will break. Running an app that I wrote only 3 years ago will blow up.
- ElKrist 4y ago
  I don't understand: if you have fixed dependencies and the same Nodejs version, how can things break? I'm not saying it's a good thing to not update your packages but you seem to imply there's another force messing with your project?
  - thorncorona 4y ago
    In general it's a hassle when your processor arch, OS version, and node version starts to come into play. NPM doesn't handle this in a great way, especially with native dependencies that need to build, and rely on OS apis. NodeJS isn't particularly stable either. For example, I used to dev apps on windows, and run them on Ubuntu 16. That worked alright but required minor changes. Moving to Ubuntu 20 on my server required a couple tweaks, and then later moving to deving on Mac required more changes. Of course keeping old copied of databases is a different story but SQLite is just so convenient compared to backing up full fledged SQL dbs. These were for old finished projects I wanted to briefly spin up.
newbieuser 4y ago
The package you use for testing may cause memory leak problems. The package you use for build may cause memory leak problems. With the new version of the frontend library you use, you can completely change its architecture and decorate it with different nonsense. Welcome to the world of javascript.
andrewstuart 4y ago
>> JavaScript is evolving too rapidly. No it's not. There's lots of dependencies and they continue to be developed. It's not too much and its not rapid. It's just constant.
- bombolo 4y ago
  rapid is ok… constantly breaking backwards compatibility is the issue.
vineyardmike 4y ago
My 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 to modify libraries across your operating system not just NPM project. Tonight, I tried simply compiling an example super-high-profile project that recently reached 1.0 (Matter protocol impl). It took me an hour of chasing down Linux dependencies to build on my Ubuntu server, while I gave up on building on my mac altogether after comments on issues suggested sym-linking various homebrew packages around my system. We are still new at experiencing docker-packaged projects, and there’s few heavily used tools that work well. Many big companies have solved this problem internally, but not out in the wild. HN has often discussed GUIX or NIX systems, but I’ve yet to see a “real” open source project that uses anything but make/docker or language specific tools (npm, cargo, etc).
- bombolo 4y ago
  > I gave up on building on my mac altogether osx is not linux. It has a gazillion of incompatibilities and most developers never test for it, so even if the code compiles, it's no guarantee it will work. > Try building anything Linux and C related "apt install libwhatever-dev" does it in most cases. > docker-packaged projects You mean completely insecure projects that most likely run an old and vulnerable openssl?
  - vineyardmike 4y ago
    Yea macOS is never a guarantee but I’m always hopeful when they include Mac instructions in the readme. I’ve found projects that use C++ or other older languages and meant for Linux still have a nightmare with building. The project I looked at had a bootstrap script, an initialization script, a pip installation, and 3+ different make-alternatives. Not uncommon even when apt works. Docker is great but it’s only as secure as Linux can be. Yea it can have outdated SSL, but it’s just as likely that the thing you need depends on a particular version. Most projects don’t get versions updated unless it’s broke. IMO if something is a web service or generally at risk, you should not depend on the good-faith security being vended. Put it bend a secure network or proxy, Audit, etc. As the advice goes, don’t run your server on port 80 as sudo, but instead run behind NGINX.(modify for risk)
bombolo 4y ago
Well js might have killed js programs. But I can go back to my python and C projects after a couple of years and rebuild them just fine.
jFriedensreich 4y ago
we should stop saying javascript when we mean nodejs. there are plenty of javascript ecosystems now and not all have those issues. if someone wants to use the latest experimental nodejs framework in a project sure its going to be difficult to continue a few years later, but if you want to build a sustainable long term project in javascript its simple to do. only use dependencies without binaries inside and only web standard apis no node apis and vendor/ hard pin everything you depend on. also use less dependencies 98% of what typical nodejs projects have is tech debt that is not needed.
ozim 4y ago
I have a bit different view. If some app is not updating - there is not much use for it. Just like houses - yeah you can have 100 years old house but if you did not invest in it and expect to be just as good as new you are in world of pain. Same with cars - 10 years and you really have to change quite some parts. Applications are ideas - we expect that ideas don't "wear out" - well most of ideas wear out rather quickly and are not useful for centuries. My javascript app is not Plato "cave allegory" - but that is fine and also what makes javascript app valuable, I can throw it away and rebuild from scratch even better with low effort. Data storage or formats should be usable for at least 5-8 years. There are things that should be preserved for longer - but these are exceptions. Most stuff after 2 years is not that useful anymore.
- amoe_ 4y ago
  You have low expectations; I have Racket programs that have worked for over 10 years essentially untouched. More or less the same with Perl. We should be aspiring to Plato's cave (while accepting that we won't reach that).
- bombolo 4y ago
  Updating is fine… bash for example keeps having new versions and new features. However this doesn't mean that we must fix every bash script every 6 months because of a bash update.
  - augustk 4y ago
    That's why I stick to the POSIX shell (sh) https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
- causi 4y ago
  If some app is not updating - there is not much use for it. That depends entirely on the program. My CD ripper/burner is going on twenty years old and it works flawlessly. Same with my audio recorder and the sensor viewer for my phone. On the occasion I need to make a slideshow or write a document, Office 2007 works just fine with no bullshit, granted I don't view third-party files in it. ES File Explorer Pro is still by far the best Android file manager despite not being updated in three and a half years. I wouldn't be particularly upset if I had to use a version of VLC that was ten years out of date.
ramesh31 4y ago
NPM bad. Insert other ecosystem good.
sourcecodeplz 4y ago
I never did understood the relaxation behind pulling new code into your project from external sources.
royletron 4y ago
Meh, 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 ashamed by it.
- Gys 4y ago
  > I love JS That is the problem. You love a hammer and see nails everywhere.
  - royletron 4y ago
    Well that's a judgement call I'm afraid you have wrong. JS is a great solution to some problems, as is Go, as is Rust, Ruby etc etc. I love JS for what it's good at - things like making web apps a reality, allowing a single language to be a start point for devs etc. I certainly don't use it exclusively.
- bombolo 4y ago
  most python modules do not have so many dependencies, and tend to have a stable api. Bugs happen but it's by no means a constant thing.
  - lordgroff 4y ago
    Python has a completely different issue and that is that its dependencies on c extensions makes cross platform or cross version packaging a terrible thing. This is why I get a bit puzzled when people complain about the Java build system. It's so much saner in comparison to the scripting languages, and arguably better than Go or Rust (though I'll take any of the three over Python or JS).
    - bombolo 4y ago
      > Python has a completely different issue and that is that its dependencies on c extensions makes cross platform or cross version packaging a terrible thing. Well java has no way to do a unix socket unless we rely on a C extension so it's hardly better in this respect.
candu 4y ago
To be fair: the reference to `node-gyp` gets at a general problem with most high-level languages. I've seen very similar issues in Python - once you start to deal with native bindings, your nice high-level language abstractions become leaky, and you can no longer guarantee that building on new hardware won't fail in mysterious ways. (This is, incidentally, one of the benefits of VMs / containers / anything designed to remove or mitigate the "new hardware" part of that risk.) If you look deep enough, or do anything low-level enough, or need to work with high-performance native libraries enough, you will find these leaky abstractions in every high-level language. Maybe it's at the "I want to do awesome Cormack-style invsqrt() pointer punning hacks" level, maybe it's at the "eep I'm dealing with raw binary data over a network and now the order of bits matters" level, maybe it's at the "argh I'm using a package that has native architecture-specific implementations" level.
dusted 4y ago
This is an article about ecosystems and package managers, not particularly about JavsScript, which is a scripting language around which one can chose to participate in ecosystems and use package managers. The distinction is not as subtle as one would think. It's the same with any program.. dependencies are future liabilities. You pay for fast development now with a future burden of upgrading and incompatibility. That's why I enjoy coming back to the software I've written with that mindset, it does not matter which language.. If I was in the supposedly wrong NIH mode when I wrote it, it still builds..
- xnorswap 4y ago
  But there's something very different in the JS ecosystem that makes things worse. In the .net world, even with packages managed with Nuget, it doesn't have the same "constantly breaking" problem. For example being "stuck" on an old version of react, because dependency X version 6.x requires react < 17, but dependency X version 7 completely re-wrote their entire API and has so many breaking changes it's not reasonable to upgrade. So you're faced with either being stuck on an old react, or re-writing half your application around the new version of your dependency. In the .net world, things don't move so fast, don't break so much and it's rare that both your dependencies and frameworks all break all at the same time leaving you stranded. The .net 5 transition was the closest thing, but the .net standard pathway mitigated the worst of that, and crucially, .net framework is still well supported. Also in the JS ecosystem, it's not just your application packages but your whole build toolchain that quickly gets out of date and breaks. For example finding that you can't move to the latest version of something because it breaks something else in a "random" location. For example finding out that you when you upgrade node, suddenly node-gyp doesn't work, and this package you likely haven't previously heard of is crucial and central to your build. There's no way around this problem but to dedicate hours every month to keep everything on the bleeding edge. There's no such thing as "LTS" in javascript. Node in theory has an LTS release but it's useless as soon as libraries start requiring non-LTS releases. Bringing in libraries shouldn't mean burdening yourself with so much future incompatibility and constant upgrade grinds that it's a significant part of every month, it they shouldn't force you to live on the bleeding edge.
  - 4y ago
Dah00n 4y ago
JavaScript feels like IE7 all over again.
enjikaka 4y ago
Tools like Babel emerged to bridge a compatibility gap between the evolving ECMAScript specification and the browser lacking behind implementing the new features. Then some "smart" people decided Babel would be a good thing to transform anything and thus React, JSX and the like were born. The problem emerged and took foot when we stopped polyfilling and transpiling the compability gap and instead built further on the powers of these tools and coupled us too tightly with them. People need to learn to build on and use the platform. Do NOT learn React, Node.js or Tailwind. Learn HTML, JS and CSS. Use these in your projects and they will work forever. The standards are backwards compatible and evergreen. Your walled garden withers.
- mirthflat83 4y ago
  Learning React, Node.js, and Tailwind doesn’t mean that you’re not learning HTML, JS, or CSS…
  - lloydatkinson 4y ago
    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. How you arrive at the HTML is up to you. By saying, for example, don't learn React, you might as well be saying "don't do anything productively, do everything in the least maintainable and the most convoluted and unnecessary way possible, your customers and team will like that surely".
    - zelphirkalt 4y ago
      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.
brushfoot 4y ago
There's no free lunch. JavaScript has the largest package ecosystem in the world. It's great for finding "free" UI components or server libraries for projects, but you pay for it in maintenance costs. That said, I don't think it's as bad as this article makes it out to be. There's this kind of maintenance in a traditional server-rendered Django/Rails app, too, on both ends. You can self-host your JS scripts or fetch them from a CDN instead of using Node, but they're still deps. You still have to worry about upgrading and vulnerability scanning. It's just invisible now. The onus is on you.
- iso1631 4y ago
  I've got perl web apps that haven't been touched for 15 years (aside from a single change from a flash <object> to <video> in the template) that still perform their function perfectly well
  - brushfoot 4y ago
    Sure - if you don't need rich UI interactivity, you can get by with a lot less. Plenty of sites don't and should. What I like about Node, though, is frameworks like Next.js that are the best of both worlds. You can do traditional server-side rendering using React components, so you can easily add as much/as little client-side JS as you need. With Next you use the same package manager for the front end and back end. And you get code sharing and access to that huge ecosystem of libraries. But needs and skillsets change the equation, definitely.
AshleysBrain 4y ago
I think the overlooked lesson is: the more technology you add in to your stack, the harder it is to maintain. Shallow tech stacks - using fewer tools and frameworks wherever possible - are usually a good idea to minimise your maintenance headaches. If you're making a small quick tool, vanilla JavaScript is not a bad choice. You don't have to use npm, TypeScript, and a bunch of frameworks. If you do anyway then sure, you can end up in a situation where 90% of your work is maintenance, but you made that tradeoff - these should be things you consciously weigh up and decide, not just do automatically.
- lionel_ZA 4y ago
  I agree with this view. Any large, complicated project with a large number of dependencies is going to require maintenance over time, regardless of the language or package ecosystem. Keep your simple projects simple, and if you need to use dependencies to get something off the ground quickly, either be prepared to maintain it or to do some additional work to remove the need for those dependencies over time.
- namaria 4y ago
  Fred Brooks has been warning us that the key problem with software development is 'how to keep complexity at bay'. Half a century later we're still wondering why sloppy complexity management bites us in the ass later on.
- Doxin 4y ago
  There's still a difference between javascript and other languages with respect to dependencies. E.g. if I open a 5yr old python project there's a fair chance all the dependencies still exist and still work with a more recent python interpreter, let alone work at all. My --limited, to be fair-- experience with npm is that you can barely look away from a project for a week or it'll have a bunch of deeply broken dependencies, requiring you to update them which then breaks other dependencies in turn.
too_much_churn 4y ago
Too much churn is killing me. JavaScript is really just the tip of the iceberg or maybe the perfect embodiment of modernity. Looking at it narcissisticly, it's like some kind of divine punishment for younger me who couldn't wait for progress and innovation on basically everything.
amadeuspagel 4y ago
"your new operating system"? What does this have to do with javascript? And with javascript evolving too rapidly? Software written for one OS sometimes doesn't work on another OS, or even on a new version of that OS. At least the latter is almost universally recognized as a problem of the OS, but here justifies a rant about javascript?
maverickmax90 4y ago
JavaScript will always win as is most accessible to new folks.
- kypro 4y ago
  I like JavaScript, but it's a horrible first language imo. Especially if it's being used in the browser.
  - deleted 4y ago
    [deleted]
DiabloD3 4y ago
I don't understand the point of this article. Most Javascript "programs" (lets not glorify them) are being stripped out of prod everywhere that isn't a NodeJS shop internally (and those are being garbage collected left and right by the Covid recession). If you build your tools with somebody else's entrenched technical debt, you are now paying somebody else's debt.
CapsAdmin 4y ago
some ways to combat this: - do you really need to upgrade? - try to reduce dependencies - freeze packages to specific versions - are you sure you need to upgrade? - if you depend on a simple package that you can't be bothered to write yourself, consider moving it into your project - try to get more control over how your project is built - try not to use dependencies that have implicit dependencies on other languages (msgpack written in c++ for example) - try to choose packages written in typescript first if you're using typescript - make sure you have a good reason to upgrade
_ubs3 4y ago
Pro tip: unless it's a trivial app, and if you don't dislike "difficult" languages, use Rust for the logic. It tends to be backwards compatible and interfaces nicely with Javascript with WASM, and you can share it with other frontends like native apps.
- yurishimo 4y ago
  Most of the time when JS stuff breaks, it's in your core business logic. It's some frontend dependency someone included because they didn't want to write their own date picker calendar component.
dncornholio 4y ago
The solution is very simple. Lock your versions in package.json. Everyone stays happy. The only thing to keep track is, is what version of NodeJS you are using. It will happily keep working for years! Do I get a super long list of deprecated and warning messages? Yes, they are also meaningless. You can ignore them and just build the feature.
- beardedetim 4y ago
  This is exactly my feelings throughout this thread. We have apps in prod that haven't been touched in years that don't break and handle average to high req/s. We add a line here or there as we need to for bug fixes but we don't have any dep problems randomly breaking the app. Pin your deps and everything keeps working how you want.
nobodyandproud 4y ago
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.
- bombolo 4y ago
  pypi is full of awful amateur libraries that don't work very well. Finding a good one among 20 crappy clones is a chore, and the most downloaded ones are not necessarily the best options. I personally just stick with whatever is on my distribution (debian) and very very seldom venture out to using something directly from pypi. In any case python doesn't require many libraries, so most of my projects require no more than 2 or 3 dependencies. Where js projects require 50, so the risk of issues from a dependency changing API is not as big.
d_runs_far 4y ago
As I am preparing to update a 10 year old project done in backbone/coffeescript this whole thread hits hard. Likewise a react prototype done in 2018 that is all class based that is going to be next to revive. Maybe I should just write my own framework... quick, to the name generator sites!
codyswann 4y ago
Man. People complain that JavaScript sucks as a language and then complain when it evolves too quickly to appease these same people. Oh well.
- wellanyway 4y ago
  It evolves too quickly for 20 years fixing fundamental issues tgat stem from the hacky origin of the language.
eezing 4y ago
Just run “npm ci” next time.
nasmorn 4y ago
I am a ruby dev mostly but I have to work on my clients react front end a few time. While I have no idea what node-gyp really is, it has come up more often then I care to remember.
boxed 4y ago
This is what I go through every time I try to run my jekyll blog locally. Just total hell.
musicale 4y ago
Build on quicksand, sink into quicksand. I may complain about Swift/iOS/macOS breaking things every year but they seem like bedrock compared to many JavaScript environments and frameworks. Come to think of it, even many Java apps seem to be built on a quicksand morass of constantly changing frameworks. But I think you can have fairly stable JavaScript if you write primarily vanilla JS and don't rely on the latest bleeding-edge features in Chrome, etc..
wellanyway 4y ago
That is what you get for using subpar tools that are not fit for the job. Javascript is a garbage language. Javascript on backend is the dumbest idea ever conceived in computing.

125 points by poeti8 4y ago

iamsaitam 4y ago

npm ci is your friend.

flohofwoe 4y ago
It's partly a solution, but doesn't help when the 'enviroment' (OS, Node, compiler toolchains used in dependencies) has moved on and is no longer compatible with the old version-pinned npm packages, the same problem also exists in other programming ecosystems (just maybe not as extremely - but I have the same bad experience each time I want to write a blog post, because Jekyll usually breaks after a macOS update). It's not Javascript or Node.js or NPM which is the problem though, but the 'culture' of offloading every little detail into its own dependency, nothing in the Javascript ecosystem technically requires this approach.
fuzzy2 4y ago
Sure, but this friend is also changing. Suddenly now it verifies peer dependencies. Oops.
- janpot 4y ago
  "yarn set version" could become your new friend? https://yarnpkg.com/cli/set/version https://yarnpkg.com/cli/set/version

5350-uiop-1130 4y ago

> 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 install not enough pragmatism in the JS community (people). more about hot new thing as opposed to boring long term stability. maybe because of web/chrome as a constantly moving platform, and Apple/Jobs app-ification of everything, relative young age of JS community.

Gibbon1 4y ago
A month ago I found a bug in command line utility I wrote in C# and hadn't touched in 8 years. I checked out the project and opened it in Visual Studio. And it compiled. I fixed the bug and it just worked. End to end it took half an hour. I feel like there is an advantage to libraries and tools managed by adults with long term skin in the game.
- hutzlibu 4y ago
  As a counter point: I have simple node scripts, that serve the same purpose to me. And there was also the need to fix something 2 days ago in an 8 year old script. Opened the file, changed the code and running it again. Took 5 minutes and it just worked. I don't use js because it is the hot new thing, but rather because it is simple. (But I avoid messy and obscure npm repositories wherever possible for example.)
  - yakshaving_jgt 4y ago
    > I don't use js because it is the hot new thing, but rather because it is simple. It infamously isn't. https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
    - hutzlibu 4y ago
      Hm, video arguments are not my take, I did not watch it (yet), but in either case this seems to be opinion. But of course, javascript is so simple, that it is not suitable for complex problems. No (sane) person would ever claim, that it is the right language for every problem.
      - deleted 4y ago
        [deleted]
      - yakshaving_jgt 4y ago
        Are you familiar with the No True Scotsman logical fallacy?

Tade0 4y ago

I experienced the same issues and to me the main culprit appears to be the dumpster fire that is the ongoing transition to ES2015 modules. Also Node v18, while full of new, important features(like the built-in test runner) feels... kinda unstable? I had to downgrade to v16 because I had segfaults. Also had to make it use jemalloc due to memory leak issues when it used the default allocator. I went into this platform specifically not to deal with such problems.

qazxcvbnm 4y ago
Just want to add that node unfortunately gives me segfaults in unexpected places too, often (seemingly randomly) during the first second of execution when I'm trying to debug it by running node under --inspect-brk...
- Tade0 4y ago
  Something is indeed off here. Even Node 0.x didn't have so many problems (granted, the debugger back then, ahem, left one wanting).

yazaddaruvala 4y ago

We are probably at the tipping point where the JS engine should now be part of the kernel and run in ring 0.

m00dy 4y ago
If that kernel is linux kernel, then linux kernel should userspace app in js kernel.
hnbad 4y ago
I see you haven't watched this talk about the history of JavaScript between 1995 and 2035 since that's exactly what happened in this future: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- yazaddaruvala 4y ago
  I have! It's a very good talk. I wouldn't make any design or technology decisions based on it tho. What is clear today is that Javascript is on every computer in the world (including phones). It is now even taking over for native desktop apps and native mobile apps. At this point, including a JS engine into all the kernels for apps and browsers to use just seems prudent.
  - kingboss 4y ago
    JS in kernel is a beyond idiotic idea. Why the hell would you put something like that in the kernel? Computing world has lost its mind if this can even come up as a suggestion. I just feel that 90% of people on this website are junior web devs. That must be the reason for the glorification of a POS language such as JS. Why the hell would you even want to run this garbage language on the server? Now you want it in the kernel? Insanity....
    - yazaddaruvala 4y ago
      lol, are you familiar with ring 0? what about context switching and scheduler preemption? If you are, then you know they add significant overhead to IO bound applications. > Why the hell would you put something like that in the kernel? Because some ridiculously large % of all client software is written in/transpiled to JavaScript? If the JS/WASM runtime would be run with the correct sandboxing (similar to browsers like Chrome), you likely could run the entire application in ring 0 and only context switch because of scheduling preemption. Maybe even ouch the whole browser into the kernel? All runtime APIs that currently need “syscalls” would become significantly more efficient. You’d end up with an extremely performant system for running browsers and browser like apps (ie Electron).

martyalain 4y ago

I agree with you. Now, thanks to JS and web browsers, anybody has access to a wide eco-system via a small interface. This is mine : http://lambdaway.free.fr/lambdawalks/ http://lambdaway.free.fr/lambdawalks/ with which I can play and explore lots of funny algorithms.

papito 4y ago

In the early 2010s, the industry was dominated by mature and stable ecosystems, such as Python/Django and Rails. Then Node came about, and when it was still extremely immature, it got a ton of attention as an army of front-end devs started to flock to it. "We are backend engineers now too!". Doesn't work that way. Node has been basically re-learning all the lessons learned a long time ago, and many lessons it didn't learn at all. The fact that the FAANG alumni then joined the orgy and reminded us that we are all lame because we really need to be doing distributed systems for everything (for the young ones - microservices), did not make things simpler. Leave a JS project unattended for a few weeks and I go back to it with a sense of dread. What horrors await me? In contrast, I dusted off an old Flask project from 8 years ago, upgraded the dependency manager, the major Python version, 2-3 hours and off I go.

eternalban 4y ago
This was a relatively mild but necessary rant. > re-learning all the lessons learned a long time ago Because this is the same crew that sailed on the ship that sang the "over 30 is over the hills" song. In fact, wasn't our own /u/pg cheering this 'very wrong idea' of completely discounting experience on the side? Surprise, surprise. Experience actually matters.
- hnbad 4y ago
  But hiring college graduates is so much cheaper and they are so much easier to dazzle and don't have any outrageous demands like being able to spend time with their family. Why hire for quality when you can make it up with quantity?
flohofwoe 4y ago
> by mature and stable ecosystems, such as Python... Nothing I experienced in the JS ecosystem so far was as nearly as painful as the over a decade-long transition from python2 to python3, and now python3 has the same 'move fast and break things' mindset. It's kinda infuriating for use cases where python2 was more than good enough.
- 4y ago

thorncorona 4y ago

The only reliable solution to this that I have found is compiling an app into a docker container and ensuring my projects are able to run off a SQLite database. I then save this to my NAS. Otherwise literally everything will break. Running an app that I wrote only 3 years ago will blow up.

ElKrist 4y ago
I don't understand: if you have fixed dependencies and the same Nodejs version, how can things break? I'm not saying it's a good thing to not update your packages but you seem to imply there's another force messing with your project?
- thorncorona 4y ago
  In general it's a hassle when your processor arch, OS version, and node version starts to come into play. NPM doesn't handle this in a great way, especially with native dependencies that need to build, and rely on OS apis. NodeJS isn't particularly stable either. For example, I used to dev apps on windows, and run them on Ubuntu 16. That worked alright but required minor changes. Moving to Ubuntu 20 on my server required a couple tweaks, and then later moving to deving on Mac required more changes. Of course keeping old copied of databases is a different story but SQLite is just so convenient compared to backing up full fledged SQL dbs. These were for old finished projects I wanted to briefly spin up.

newbieuser 4y ago

The package you use for testing may cause memory leak problems. The package you use for build may cause memory leak problems. With the new version of the frontend library you use, you can completely change its architecture and decorate it with different nonsense. Welcome to the world of javascript.

andrewstuart 4y ago

>> JavaScript is evolving too rapidly. No it's not. There's lots of dependencies and they continue to be developed. It's not too much and its not rapid. It's just constant.

bombolo 4y ago
rapid is ok… constantly breaking backwards compatibility is the issue.

vineyardmike 4y ago

My 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 to modify libraries across your operating system not just NPM project. Tonight, I tried simply compiling an example super-high-profile project that recently reached 1.0 (Matter protocol impl). It took me an hour of chasing down Linux dependencies to build on my Ubuntu server, while I gave up on building on my mac altogether after comments on issues suggested sym-linking various homebrew packages around my system. We are still new at experiencing docker-packaged projects, and there’s few heavily used tools that work well. Many big companies have solved this problem internally, but not out in the wild. HN has often discussed GUIX or NIX systems, but I’ve yet to see a “real” open source project that uses anything but make/docker or language specific tools (npm, cargo, etc).

bombolo 4y ago
> I gave up on building on my mac altogether osx is not linux. It has a gazillion of incompatibilities and most developers never test for it, so even if the code compiles, it's no guarantee it will work. > Try building anything Linux and C related "apt install libwhatever-dev" does it in most cases. > docker-packaged projects You mean completely insecure projects that most likely run an old and vulnerable openssl?
- vineyardmike 4y ago
  Yea macOS is never a guarantee but I’m always hopeful when they include Mac instructions in the readme. I’ve found projects that use C++ or other older languages and meant for Linux still have a nightmare with building. The project I looked at had a bootstrap script, an initialization script, a pip installation, and 3+ different make-alternatives. Not uncommon even when apt works. Docker is great but it’s only as secure as Linux can be. Yea it can have outdated SSL, but it’s just as likely that the thing you need depends on a particular version. Most projects don’t get versions updated unless it’s broke. IMO if something is a web service or generally at risk, you should not depend on the good-faith security being vended. Put it bend a secure network or proxy, Audit, etc. As the advice goes, don’t run your server on port 80 as sudo, but instead run behind NGINX.(modify for risk)

bombolo 4y ago

Well js might have killed js programs. But I can go back to my python and C projects after a couple of years and rebuild them just fine.

jFriedensreich 4y ago

we should stop saying javascript when we mean nodejs. there are plenty of javascript ecosystems now and not all have those issues. if someone wants to use the latest experimental nodejs framework in a project sure its going to be difficult to continue a few years later, but if you want to build a sustainable long term project in javascript its simple to do. only use dependencies without binaries inside and only web standard apis no node apis and vendor/ hard pin everything you depend on. also use less dependencies 98% of what typical nodejs projects have is tech debt that is not needed.

ozim 4y ago

I have a bit different view. If some app is not updating - there is not much use for it. Just like houses - yeah you can have 100 years old house but if you did not invest in it and expect to be just as good as new you are in world of pain. Same with cars - 10 years and you really have to change quite some parts. Applications are ideas - we expect that ideas don't "wear out" - well most of ideas wear out rather quickly and are not useful for centuries. My javascript app is not Plato "cave allegory" - but that is fine and also what makes javascript app valuable, I can throw it away and rebuild from scratch even better with low effort. Data storage or formats should be usable for at least 5-8 years. There are things that should be preserved for longer - but these are exceptions. Most stuff after 2 years is not that useful anymore.

amoe_ 4y ago
You have low expectations; I have Racket programs that have worked for over 10 years essentially untouched. More or less the same with Perl. We should be aspiring to Plato's cave (while accepting that we won't reach that).
bombolo 4y ago
Updating is fine… bash for example keeps having new versions and new features. However this doesn't mean that we must fix every bash script every 6 months because of a bash update.
- augustk 4y ago
  That's why I stick to the POSIX shell (sh) https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
causi 4y ago
If some app is not updating - there is not much use for it. That depends entirely on the program. My CD ripper/burner is going on twenty years old and it works flawlessly. Same with my audio recorder and the sensor viewer for my phone. On the occasion I need to make a slideshow or write a document, Office 2007 works just fine with no bullshit, granted I don't view third-party files in it. ES File Explorer Pro is still by far the best Android file manager despite not being updated in three and a half years. I wouldn't be particularly upset if I had to use a version of VLC that was ten years out of date.

ramesh31 4y ago

NPM bad. Insert other ecosystem good.

sourcecodeplz 4y ago

I never did understood the relaxation behind pulling new code into your project from external sources.

royletron 4y ago

Meh, 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 ashamed by it.

Gys 4y ago
> I love JS That is the problem. You love a hammer and see nails everywhere.
- royletron 4y ago
  Well that's a judgement call I'm afraid you have wrong. JS is a great solution to some problems, as is Go, as is Rust, Ruby etc etc. I love JS for what it's good at - things like making web apps a reality, allowing a single language to be a start point for devs etc. I certainly don't use it exclusively.
bombolo 4y ago
most python modules do not have so many dependencies, and tend to have a stable api. Bugs happen but it's by no means a constant thing.
- lordgroff 4y ago
  Python has a completely different issue and that is that its dependencies on c extensions makes cross platform or cross version packaging a terrible thing. This is why I get a bit puzzled when people complain about the Java build system. It's so much saner in comparison to the scripting languages, and arguably better than Go or Rust (though I'll take any of the three over Python or JS).
  - bombolo 4y ago
    > Python has a completely different issue and that is that its dependencies on c extensions makes cross platform or cross version packaging a terrible thing. Well java has no way to do a unix socket unless we rely on a C extension so it's hardly better in this respect.

candu 4y ago

To be fair: the reference to `node-gyp` gets at a general problem with most high-level languages. I've seen very similar issues in Python - once you start to deal with native bindings, your nice high-level language abstractions become leaky, and you can no longer guarantee that building on new hardware won't fail in mysterious ways. (This is, incidentally, one of the benefits of VMs / containers / anything designed to remove or mitigate the "new hardware" part of that risk.) If you look deep enough, or do anything low-level enough, or need to work with high-performance native libraries enough, you will find these leaky abstractions in every high-level language. Maybe it's at the "I want to do awesome Cormack-style invsqrt() pointer punning hacks" level, maybe it's at the "eep I'm dealing with raw binary data over a network and now the order of bits matters" level, maybe it's at the "argh I'm using a package that has native architecture-specific implementations" level.

dusted 4y ago

This is an article about ecosystems and package managers, not particularly about JavsScript, which is a scripting language around which one can chose to participate in ecosystems and use package managers. The distinction is not as subtle as one would think. It's the same with any program.. dependencies are future liabilities. You pay for fast development now with a future burden of upgrading and incompatibility. That's why I enjoy coming back to the software I've written with that mindset, it does not matter which language.. If I was in the supposedly wrong NIH mode when I wrote it, it still builds..

xnorswap 4y ago
But there's something very different in the JS ecosystem that makes things worse. In the .net world, even with packages managed with Nuget, it doesn't have the same "constantly breaking" problem. For example being "stuck" on an old version of react, because dependency X version 6.x requires react < 17, but dependency X version 7 completely re-wrote their entire API and has so many breaking changes it's not reasonable to upgrade. So you're faced with either being stuck on an old react, or re-writing half your application around the new version of your dependency. In the .net world, things don't move so fast, don't break so much and it's rare that both your dependencies and frameworks all break all at the same time leaving you stranded. The .net 5 transition was the closest thing, but the .net standard pathway mitigated the worst of that, and crucially, .net framework is still well supported. Also in the JS ecosystem, it's not just your application packages but your whole build toolchain that quickly gets out of date and breaks. For example finding that you can't move to the latest version of something because it breaks something else in a "random" location. For example finding out that you when you upgrade node, suddenly node-gyp doesn't work, and this package you likely haven't previously heard of is crucial and central to your build. There's no way around this problem but to dedicate hours every month to keep everything on the bleeding edge. There's no such thing as "LTS" in javascript. Node in theory has an LTS release but it's useless as soon as libraries start requiring non-LTS releases. Bringing in libraries shouldn't mean burdening yourself with so much future incompatibility and constant upgrade grinds that it's a significant part of every month, it they shouldn't force you to live on the bleeding edge.
- 4y ago

Dah00n 4y ago

JavaScript feels like IE7 all over again.

enjikaka 4y ago

Tools like Babel emerged to bridge a compatibility gap between the evolving ECMAScript specification and the browser lacking behind implementing the new features. Then some "smart" people decided Babel would be a good thing to transform anything and thus React, JSX and the like were born. The problem emerged and took foot when we stopped polyfilling and transpiling the compability gap and instead built further on the powers of these tools and coupled us too tightly with them. People need to learn to build on and use the platform. Do NOT learn React, Node.js or Tailwind. Learn HTML, JS and CSS. Use these in your projects and they will work forever. The standards are backwards compatible and evergreen. Your walled garden withers.

mirthflat83 4y ago
Learning React, Node.js, and Tailwind doesn’t mean that you’re not learning HTML, JS, or CSS…
- lloydatkinson 4y ago
  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. How you arrive at the HTML is up to you. By saying, for example, don't learn React, you might as well be saying "don't do anything productively, do everything in the least maintainable and the most convoluted and unnecessary way possible, your customers and team will like that surely".
  - zelphirkalt 4y ago
    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.

brushfoot 4y ago

There's no free lunch. JavaScript has the largest package ecosystem in the world. It's great for finding "free" UI components or server libraries for projects, but you pay for it in maintenance costs. That said, I don't think it's as bad as this article makes it out to be. There's this kind of maintenance in a traditional server-rendered Django/Rails app, too, on both ends. You can self-host your JS scripts or fetch them from a CDN instead of using Node, but they're still deps. You still have to worry about upgrading and vulnerability scanning. It's just invisible now. The onus is on you.

iso1631 4y ago
I've got perl web apps that haven't been touched for 15 years (aside from a single change from a flash <object> to <video> in the template) that still perform their function perfectly well
- brushfoot 4y ago
  Sure - if you don't need rich UI interactivity, you can get by with a lot less. Plenty of sites don't and should. What I like about Node, though, is frameworks like Next.js that are the best of both worlds. You can do traditional server-side rendering using React components, so you can easily add as much/as little client-side JS as you need. With Next you use the same package manager for the front end and back end. And you get code sharing and access to that huge ecosystem of libraries. But needs and skillsets change the equation, definitely.

AshleysBrain 4y ago

I think the overlooked lesson is: the more technology you add in to your stack, the harder it is to maintain. Shallow tech stacks - using fewer tools and frameworks wherever possible - are usually a good idea to minimise your maintenance headaches. If you're making a small quick tool, vanilla JavaScript is not a bad choice. You don't have to use npm, TypeScript, and a bunch of frameworks. If you do anyway then sure, you can end up in a situation where 90% of your work is maintenance, but you made that tradeoff - these should be things you consciously weigh up and decide, not just do automatically.

lionel_ZA 4y ago
I agree with this view. Any large, complicated project with a large number of dependencies is going to require maintenance over time, regardless of the language or package ecosystem. Keep your simple projects simple, and if you need to use dependencies to get something off the ground quickly, either be prepared to maintain it or to do some additional work to remove the need for those dependencies over time.
namaria 4y ago
Fred Brooks has been warning us that the key problem with software development is 'how to keep complexity at bay'. Half a century later we're still wondering why sloppy complexity management bites us in the ass later on.
Doxin 4y ago
There's still a difference between javascript and other languages with respect to dependencies. E.g. if I open a 5yr old python project there's a fair chance all the dependencies still exist and still work with a more recent python interpreter, let alone work at all. My --limited, to be fair-- experience with npm is that you can barely look away from a project for a week or it'll have a bunch of deeply broken dependencies, requiring you to update them which then breaks other dependencies in turn.

too_much_churn 4y ago

Too much churn is killing me. JavaScript is really just the tip of the iceberg or maybe the perfect embodiment of modernity. Looking at it narcissisticly, it's like some kind of divine punishment for younger me who couldn't wait for progress and innovation on basically everything.

amadeuspagel 4y ago

"your new operating system"? What does this have to do with javascript? And with javascript evolving too rapidly? Software written for one OS sometimes doesn't work on another OS, or even on a new version of that OS. At least the latter is almost universally recognized as a problem of the OS, but here justifies a rant about javascript?

maverickmax90 4y ago

JavaScript will always win as is most accessible to new folks.

kypro 4y ago
I like JavaScript, but it's a horrible first language imo. Especially if it's being used in the browser.
- deleted 4y ago
  [deleted]

DiabloD3 4y ago

I don't understand the point of this article. Most Javascript "programs" (lets not glorify them) are being stripped out of prod everywhere that isn't a NodeJS shop internally (and those are being garbage collected left and right by the Covid recession). If you build your tools with somebody else's entrenched technical debt, you are now paying somebody else's debt.

CapsAdmin 4y ago

some ways to combat this: - do you really need to upgrade? - try to reduce dependencies - freeze packages to specific versions - are you sure you need to upgrade? - if you depend on a simple package that you can't be bothered to write yourself, consider moving it into your project - try to get more control over how your project is built - try not to use dependencies that have implicit dependencies on other languages (msgpack written in c++ for example) - try to choose packages written in typescript first if you're using typescript - make sure you have a good reason to upgrade

_ubs3 4y ago

Pro tip: unless it's a trivial app, and if you don't dislike "difficult" languages, use Rust for the logic. It tends to be backwards compatible and interfaces nicely with Javascript with WASM, and you can share it with other frontends like native apps.

yurishimo 4y ago
Most of the time when JS stuff breaks, it's in your core business logic. It's some frontend dependency someone included because they didn't want to write their own date picker calendar component.

dncornholio 4y ago

The solution is very simple. Lock your versions in package.json. Everyone stays happy. The only thing to keep track is, is what version of NodeJS you are using. It will happily keep working for years! Do I get a super long list of deprecated and warning messages? Yes, they are also meaningless. You can ignore them and just build the feature.

beardedetim 4y ago
This is exactly my feelings throughout this thread. We have apps in prod that haven't been touched in years that don't break and handle average to high req/s. We add a line here or there as we need to for bug fixes but we don't have any dep problems randomly breaking the app. Pin your deps and everything keeps working how you want.

nobodyandproud 4y ago

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.

bombolo 4y ago
pypi is full of awful amateur libraries that don't work very well. Finding a good one among 20 crappy clones is a chore, and the most downloaded ones are not necessarily the best options. I personally just stick with whatever is on my distribution (debian) and very very seldom venture out to using something directly from pypi. In any case python doesn't require many libraries, so most of my projects require no more than 2 or 3 dependencies. Where js projects require 50, so the risk of issues from a dependency changing API is not as big.

d_runs_far 4y ago

As I am preparing to update a 10 year old project done in backbone/coffeescript this whole thread hits hard. Likewise a react prototype done in 2018 that is all class based that is going to be next to revive. Maybe I should just write my own framework... quick, to the name generator sites!

codyswann 4y ago

Man. People complain that JavaScript sucks as a language and then complain when it evolves too quickly to appease these same people. Oh well.

wellanyway 4y ago
It evolves too quickly for 20 years fixing fundamental issues tgat stem from the hacky origin of the language.

eezing 4y ago

Just run “npm ci” next time.

nasmorn 4y ago

I am a ruby dev mostly but I have to work on my clients react front end a few time. While I have no idea what node-gyp really is, it has come up more often then I care to remember.

boxed 4y ago

This is what I go through every time I try to run my jekyll blog locally. Just total hell.

musicale 4y ago

Build on quicksand, sink into quicksand. I may complain about Swift/iOS/macOS breaking things every year but they seem like bedrock compared to many JavaScript environments and frameworks. Come to think of it, even many Java apps seem to be built on a quicksand morass of constantly changing frameworks. But I think you can have fairly stable JavaScript if you write primarily vanilla JS and don't rely on the latest bleeding-edge features in Chrome, etc..

wellanyway 4y ago

That is what you get for using subpar tools that are not fit for the job. Javascript is a garbage language. Javascript on backend is the dumbest idea ever conceived in computing.