> 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.
It's funny. The issue described (inability to replicate the conditions to build and/or run the original program using NPM) is something that gets brought up a lot, but people will appear who are downright adamant that it's not a problem. Not just that it's not prevalent enough to be concerned about, but that they've literally never seen it happen ever. We're living in completely separate worlds.
And let's be clear: this is an *NPMJS* problem, not a *JS* problem. For folks who have read and written lots of JS before and during NPM's reign over programmers' attention and will continue to do so afterward (when NPM as the dominant culture evaporates) and have kept NPM- and NodeJS-inspired "best practices" at arms length precisely for these reasons and more, it's irksome to see people full-on equate JS with what-the-NPMers-are-doing.
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.
> "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#, Java, etc).
The best thing about bash is portability indeed. Node requires an entire runtime, while Rust may have a problem with library versions and requires a heavy toolchain too to recompile. I use it for small CLI tools but I could not envision anything over 1k LOC in bash. I think the ideal would be a language that introduced a nicer syntax and compiled it to bash. I wonder if there's anything like that...
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..
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.
I can come back to a go module I write today months later and do a build. `go.mod` specifies exactly what version of what dependency I used, and `go.sum` provides the checksums. Even if the original repo was shut down, there is a good chance the `GOPROXY` I use has it cached, and failing that, if I am really worried about long time availability of dependencies I can always do a `go mod vendor` and check everything in my own repo.
Heck, I think half a year ago, I unearthed a project I wrote in Go1. ... I think 6? 8?, Anywho, way before modules were introduced. All I had to do to get it to build was a `go mod init app && go mod tidy`.
And all of this is baked into the official toolchain that comes with the language. So is testing, benchmarking, documentation-generation. As a bonus, the official proxy provides a handy way for package discovery, but without relying on any one centralized repository to fetch said packages.
The language itself doesn't change a whole lot, and by design encourages a straightforward and to-the-point style of doing things, (at the cost of being somewhat verbose sometimes, but I think that's an acceptable tradeoff). The result (and also a big thanks to `gofmt` at this point) is a coding style that is pretty consistent between many modules written 5 years ago and projects started yesterday. The designers make sure that newer versions of Go itself don't break things, with even generics not breaking any backwards compatibility.
And if I want to upgrade a dependency, there are only 2 possible outcomes: Either the go-tool can resolve the dependency graph to something that works for everything in the project, or it cannot. Either way, provided I `go mod vendor`ed, I won't end up in a situation where I just cannot build any more.
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.
>Hi, I am Darren, and I love JS - I will no longer be ashamed by it.
Don't make a programming language part of your identity. It's pathetic.
No one is "dunking on Javascript for the sake of dunking on Javascript." PHP, Go and other languages don't have these issues, or at best don't have them at the same frequency, nor are they as catastrophic when they occur.
No PHP dev ever woke up to discover the entire universe was broken because some rando who owned the function that left-aligned text in terminals deleted their repo in a fit of pique. Other languages vendor dependencies by default. Other developers use libraries which contain more than a single function so their dependency trees are shallower and less brittle. Other developers are less allergic to actually writing code than Javascript developers, so less of their application is offloaded to remote dependencies.
This isn't a JS issue, it's an ecosystem and culture issue. Back in the ancient days of JQuery modules, none of these problems existed. They're the result of Javascript being co-opted by SV and corporate interests. The necessary evils of piling on complexities in order to get the language to do things it wasn't meant to do, in contexts it wasn't meant to operate in, because money.
Hell, a lot of JS' problems stem from the fact that - alone among programming languages as far as i'm aware - JS development all but requires using another language entirely. No one writing Python actually uses a strictly typed "superset" of Python that compiles to Python, because they consider actually writing Python directly to be too dangerous. That would be ridiculous. Yet in JS, it's essentially mandatory.
Yeah, sorry but JS is kind of a comedy of errors right now, and it's never going to get better if people refuse to see its faults.
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.
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).
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.
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?
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.
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.
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.
> 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?
> 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.
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.
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..
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.
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.
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?
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/ with which I can play and explore lots of funny algorithms.
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.
> Then some "smart" people decided Babel would be a good thing to transform anything and thus React ... and the like were born
Is this a serious comment? You're playing into the typical HN bandwagon of hate on anything web related. React is a library for declarative UI and state management. It doesn't need Babel or even JSX to be used. It can be used in the browser with no build tools at all. Except no one does that, because productivity of tooling is a massive win.
Your complaint about polyfills, transpiling, etc, is just a thinly veiled attack on React because you apparently have some gripe with it.
This is terrible advice, on the order of “learn assembly, not C”, or “real geeks compile their kernels with customizations”.
It’s a tale as old as time: the “smart” people are actually dumb, I am the smart one, and so I will build my own framework from the ground up of JS, HTML, CSS as part of my work. And maybe eventually I’ll release it to the world.
This is why the JS community is the way it is - lots of folks thinking they can do better than the last group. This plays out a few times in mature language ecosystems. Sometimes, occasionally, it’s actually true. In the JS community there have been a LOT of new attempts with “just enough” better ideas to form a sustainable community around them. But most of the time this is a wasteful idea: reskilling, reinvention, endless advocacy flame wars, etc.
But such is the tech world, we used to see this with Operating systems in the 80s and 90s before we settled down mostly on *nix.
Doing it all by yourself from base technology is fine if it’s just you and you’re the boss, but is a recipe for an unmaintainable mess that will be hell to deal with and likely thrown out once you leave whatever organization you inflicted your brilliance on.
The JS community is an example of what Happens when there is no strong central body in control of core library and framework maintainability. There are subsets that are well maintained. Use those.
> The standards are backwards compatible and evergreen.
They are definitely not backwards compatible. Most of the modern web will be broken on older devices. A few of the newer standards couldn't even be properly polyfilled on some older browsers.
And some of them are definitely not evergreen. Marquee is the one that will definitely spring to mind. But then there was Custom Elements V0 that Youtube was rebuilt in and removed when Youtube was rebuilt in V1. And then there's the push by browsers to remove alert/prompt/confirm.
> Your walled garden withers.
These "walled gardens" use the platform as much as your half-baked lib/framework you inevitably end up with. Because there's nothing else to use in the browser but the platform.
And the platform sucks. It offers almost zero functionality for anything beyond a static text page with a few images on it
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.
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.
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.
[+] [-] mouzogu|3 years ago|reply
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.
[+] [-] cxr|3 years ago|reply
And let's be clear: this is an *NPMJS* problem, not a *JS* problem. For folks who have read and written lots of JS before and during NPM's reign over programmers' attention and will continue to do so afterward (when NPM as the dominant culture evaporates) and have kept NPM- and NodeJS-inspired "best practices" at arms length precisely for these reasons and more, it's irksome to see people full-on equate JS with what-the-NPMers-are-doing.
[+] [-] Gibbon1|3 years ago|reply
[+] [-] csmpltn|3 years ago|reply
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#, Java, etc).
[+] [-] GrabbinD33ze69|3 years ago|reply
Lol what a great way to describe what running a simple "npm install" entails.
[+] [-] bluocms|3 years ago|reply
My software in js from 7 years ago still works.
[+] [-] ianai|3 years ago|reply
[+] [-] mckravchyk|3 years ago|reply
[+] [-] FractalHQ|3 years ago|reply
[+] [-] yieldcrv|3 years ago|reply
It isolate and pins npm installs so that the environment is the same in the future without messing up your main system
Your projects also need to consider pinning their dependencies to a specific version
Other languages/frameworks with package managers have similar concepts
[+] [-] andsens|3 years ago|reply
https://github.com/andsens/docopt.sh
No dependencies, the code is directly inlined into your script, and you write the args parser by writing the help-text.
[+] [-] jasfi|3 years ago|reply
[+] [-] dusted|3 years ago|reply
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..
[+] [-] royletron|3 years ago|reply
Hi, I am Darren, and I love JS - I will no longer be ashamed by it.
[+] [-] usrbinbash|3 years ago|reply
Heck, I think half a year ago, I unearthed a project I wrote in Go1. ... I think 6? 8?, Anywho, way before modules were introduced. All I had to do to get it to build was a `go mod init app && go mod tidy`.
And all of this is baked into the official toolchain that comes with the language. So is testing, benchmarking, documentation-generation. As a bonus, the official proxy provides a handy way for package discovery, but without relying on any one centralized repository to fetch said packages.
The language itself doesn't change a whole lot, and by design encourages a straightforward and to-the-point style of doing things, (at the cost of being somewhat verbose sometimes, but I think that's an acceptable tradeoff). The result (and also a big thanks to `gofmt` at this point) is a coding style that is pretty consistent between many modules written 5 years ago and projects started yesterday. The designers make sure that newer versions of Go itself don't break things, with even generics not breaking any backwards compatibility.
And if I want to upgrade a dependency, there are only 2 possible outcomes: Either the go-tool can resolve the dependency graph to something that works for everything in the project, or it cannot. Either way, provided I `go mod vendor`ed, I won't end up in a situation where I just cannot build any more.
[+] [-] trarmp|3 years ago|reply
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.
[+] [-] krapp|3 years ago|reply
Don't make a programming language part of your identity. It's pathetic.
No one is "dunking on Javascript for the sake of dunking on Javascript." PHP, Go and other languages don't have these issues, or at best don't have them at the same frequency, nor are they as catastrophic when they occur.
No PHP dev ever woke up to discover the entire universe was broken because some rando who owned the function that left-aligned text in terminals deleted their repo in a fit of pique. Other languages vendor dependencies by default. Other developers use libraries which contain more than a single function so their dependency trees are shallower and less brittle. Other developers are less allergic to actually writing code than Javascript developers, so less of their application is offloaded to remote dependencies.
This isn't a JS issue, it's an ecosystem and culture issue. Back in the ancient days of JQuery modules, none of these problems existed. They're the result of Javascript being co-opted by SV and corporate interests. The necessary evils of piling on complexities in order to get the language to do things it wasn't meant to do, in contexts it wasn't meant to operate in, because money.
Hell, a lot of JS' problems stem from the fact that - alone among programming languages as far as i'm aware - JS development all but requires using another language entirely. No one writing Python actually uses a strictly typed "superset" of Python that compiles to Python, because they consider actually writing Python directly to be too dangerous. That would be ridiculous. Yet in JS, it's essentially mandatory.
Yeah, sorry but JS is kind of a comedy of errors right now, and it's never going to get better if people refuse to see its faults.
[+] [-] bombolo|3 years ago|reply
Bugs happen but it's by no means a constant thing.
[+] [-] Gys|3 years ago|reply
That is the problem. You love a hammer and see nails everywhere.
[+] [-] AshleysBrain|3 years ago|reply
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.
[+] [-] vineyardmike|3 years ago|reply
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).
[+] [-] AgentME|3 years ago|reply
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.
[+] [-] bombolo|3 years ago|reply
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?
[+] [-] Tade0|3 years ago|reply
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.
[+] [-] candu|3 years ago|reply
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.
[+] [-] papito|3 years ago|reply
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|3 years ago|reply
> 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.
[+] [-] flohofwoe|3 years ago|reply
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.
[+] [-] brushfoot|3 years ago|reply
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.
[+] [-] andrewstuart|3 years ago|reply
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.
[+] [-] musicale|3 years ago|reply
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..
[+] [-] thorncorona|3 years ago|reply
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.
[+] [-] jFriedensreich|3 years ago|reply
[+] [-] bombolo|3 years ago|reply
[+] [-] amadeuspagel|3 years ago|reply
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?
[+] [-] martyalain|3 years ago|reply
[+] [-] enjikaka|3 years ago|reply
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.
[+] [-] lloydatkinson|3 years ago|reply
Is this a serious comment? You're playing into the typical HN bandwagon of hate on anything web related. React is a library for declarative UI and state management. It doesn't need Babel or even JSX to be used. It can be used in the browser with no build tools at all. Except no one does that, because productivity of tooling is a massive win.
Your complaint about polyfills, transpiling, etc, is just a thinly veiled attack on React because you apparently have some gripe with it.
[+] [-] parasubvert|3 years ago|reply
It’s a tale as old as time: the “smart” people are actually dumb, I am the smart one, and so I will build my own framework from the ground up of JS, HTML, CSS as part of my work. And maybe eventually I’ll release it to the world.
This is why the JS community is the way it is - lots of folks thinking they can do better than the last group. This plays out a few times in mature language ecosystems. Sometimes, occasionally, it’s actually true. In the JS community there have been a LOT of new attempts with “just enough” better ideas to form a sustainable community around them. But most of the time this is a wasteful idea: reskilling, reinvention, endless advocacy flame wars, etc.
But such is the tech world, we used to see this with Operating systems in the 80s and 90s before we settled down mostly on *nix.
Doing it all by yourself from base technology is fine if it’s just you and you’re the boss, but is a recipe for an unmaintainable mess that will be hell to deal with and likely thrown out once you leave whatever organization you inflicted your brilliance on.
The JS community is an example of what Happens when there is no strong central body in control of core library and framework maintainability. There are subsets that are well maintained. Use those.
[+] [-] schwartzworld|3 years ago|reply
How exactly should I use html and css to replace nodejs?
[+] [-] mirthflat83|3 years ago|reply
[+] [-] dmitriid|3 years ago|reply
They are definitely not backwards compatible. Most of the modern web will be broken on older devices. A few of the newer standards couldn't even be properly polyfilled on some older browsers.
And some of them are definitely not evergreen. Marquee is the one that will definitely spring to mind. But then there was Custom Elements V0 that Youtube was rebuilt in and removed when Youtube was rebuilt in V1. And then there's the push by browsers to remove alert/prompt/confirm.
> Your walled garden withers.
These "walled gardens" use the platform as much as your half-baked lib/framework you inevitably end up with. Because there's nothing else to use in the browser but the platform.
And the platform sucks. It offers almost zero functionality for anything beyond a static text page with a few images on it
[+] [-] gedy|3 years ago|reply
[+] [-] too_much_churn|3 years ago|reply
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.
[+] [-] CapsAdmin|3 years ago|reply
- 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
[+] [-] dncornholio|3 years ago|reply
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|3 years ago|reply
Pin your deps and everything keeps working how you want.