Programs are dead, and JavaScript has killed them(pouria.dev)
pouria.dev
Programs are dead, and JavaScript has killed them
https://pouria.dev/programs-are-dead/
215 comments
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.
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.
You're right that it's not the language per se, but I'd argue that it's not specifically NPM either - the same problems afflict any rapidly-moving not-yet-fully-mature software ecosystem. The whole tale definitely reminded me of the pain of trying to build projects in C and C++ from source in the early 2000s, with GNU Autotools everywhere, and before pkg_config was common. I've had similar "side quest" frustrations (I really like that description from the parent post!) more recently when python's involved.
But I guess NPM's particularly prone to it due to the sheer number of interdependent packages. I can't quite wrap my head around there being one npm package for every 6,100 human beings on the planet.
But I guess NPM's particularly prone to it due to the sheer number of interdependent packages. I can't quite wrap my head around there being one npm package for every 6,100 human beings on the planet.
This article reminded me of my days as a sysadmin in the 90s. It seemed like every new system had a fresh issue with getting some shared library right.
Of course it's a JS problem. "Programs" being replaced by JavaScript apps doesn't mean some custom homegrown LTS framework. It means apps that aim to replace what used to be known as "Programs" have some sort of frontend JS component. frontend JS doesn't mean npm.js sure, but it means whatever flavour of bower is hot today, webpack or the other new kids on the block, react or other stuff. There is a reason why these big companies hire unlimited amounts of frontend devs. If you leave a react apps dependencies half a year and then try to update it none of it will work. It's "less" bad than it was 2 years go, but it's extremely cost-intensive to maintain nonetheless.
But it's not like backend js is any better. Most people run express.js in some shape of form, but then people roll their own (or use any of the existing 50) input sanitizing libraries and then half of those projects run into the same authentication bugs that Rails fixed almost a decade ago. There's a reason why people don't ask for JavaScript experience, but instead ask for Node.js experience in resumes.
But it's not like backend js is any better. Most people run express.js in some shape of form, but then people roll their own (or use any of the existing 50) input sanitizing libraries and then half of those projects run into the same authentication bugs that Rails fixed almost a decade ago. There's a reason why people don't ask for JavaScript experience, but instead ask for Node.js experience in resumes.
> Of course it's a JS problem.
I've already explained why it isn't, in detail.
I've already explained why it isn't, in detail.
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.
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.)
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.)
> 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
It infamously isn't.
https://www.destroyallsoftware.com/talks/wat
Most of these are 'gotchas' that rarely happen in real code because they're all due to implicit type conversions
Yeah, nothing there affects regular programs even a tenth as bad as say quoting rules and space handling affect average Bash shell scripts.
Wouldn't shellcheck catch most of these?
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.
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]
Are you familiar with the No True Scotsman logical fallacy?
Yes, but I do not know, what you are trying to tell me.
I am suggesting that you are making exactly this kind of fallacious argument when you say “No (sane) person would ever claim, that it is the right language for every problem.”
"in which one attempts to protect their universal generalization from a falsifying counterexample by excluding the counterexample improperly"
This would be the wiki definition.
But where is your falsifying counterexample?
You mean the video, which says below:
"This talk does not represent anyone's actual opinion. For a more serious take on software, try .."?
This would be the wiki definition.
But where is your falsifying counterexample?
You mean the video, which says below:
"This talk does not represent anyone's actual opinion. For a more serious take on software, try .."?
It's fairly easy to find falsifying counterexamples — it's not such an uncommon opinion.
Also I believe the author of the video is clarifying in the statement you quoted that he isn't trying to take a position on the state of the industry.
Also I believe the author of the video is clarifying in the statement you quoted that he isn't trying to take a position on the state of the industry.
People always underestimate how stable JS is. I would argue that it is more stable and backward compatible than a lot of backend languages. What is not stable in JS - is a whole ecosystem.
I've been laughed at for scripting in Java, but I have a bunch of such scripts from 15-20 years ago and guess what, they work out of the box like the first day.
You can also patch most classic .NET (4.8 and below) "binaries" in place with something like dnSpy. One example: I had to update a simple command line tool someone else wrote to poll an API that had undergone some changes. Was able to make the changes directly in dnSpy without having to even open Visual Studio. I haven't tried with any of the 5.0+ versions so I don't know if this is still the case.
Same thing with java. Literally pick up where you left off. The issue of not working after some time just isn't an issue.
That's how it should work. But of course last week I revisited a project I wrote in C# too, this only 3 years old, and apart from dotnet complaining about the target framework not being supported any more, I couldn't get it working again due to the libraries used.
This makes no sense. If you upgraded your libraries, thats in you to fix it tho.
> "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).
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).
Only use python if you plan on compiling it with something like docker or podman to pickle your resulting stew in epoxy for all time.
Otherwise you'll still be in some dependency heck as you run down why your library updated doesn't work (oh, switched to TLS encryption; that's good I guess) or you're thing uses v2 and everything now uses v3.
golang, rust, at least, make a static binary out of the gate. In 8 years it'll probably be full of hideous out-of-date code and full of security vulnerabilities, but at least you won't have to look at it and feel bad.
If static binaries were good enough for Ultrix, they're good enough for you.
Otherwise you'll still be in some dependency heck as you run down why your library updated doesn't work (oh, switched to TLS encryption; that's good I guess) or you're thing uses v2 and everything now uses v3.
golang, rust, at least, make a static binary out of the gate. In 8 years it'll probably be full of hideous out-of-date code and full of security vulnerabilities, but at least you won't have to look at it and feel bad.
If static binaries were good enough for Ultrix, they're good enough for you.
I've been writing tools like this in Python for a very long time and haven't run into anything close to what you're describing. However, if this happened to me and I was annoyed enough to do something about it, I would use a tool (e.g. pip-compile) that creates a requirements.txt file, which specifies all the libraries and dependency version numbers explicitly. If something broke one day, you can stick that script in a directory with a venv and just run it from there. There's no need to resort to compiled languages like Go and Rust which will very likely give you a large raft of other unrelated problems (slower development velocity, comparatively limited libraries, etc.). Going through all of that just to have a binary in hand doesn't seem remotely worth it from my perspective (YMMV).
The OCI container is the binary. Docker is a tool to take any existing runtime and turn it into a static binary you can feed to any future linux(ish) kernel.
I on the other hand, have had plenty of situations where some system somewhere is managed with some config management tool (such as puppet) and it is told "make this application with these dependencies" and the application, such as "manage elasticsearch index rotation" uses the system python and does pip install to install all the things. This idiom seems fine, but ultimately ends up with a hideous mess where it worked one day and didn't work a year later, because either the system python is different or the dependencies are all messed up or the pip tool itself on the system python isn't compatible with modern package distribution.
You can (correctly) say "don't do that" but the same idiom in a shell script will almost certainly work across decades regardless of if "sh" is bash or ash or ksh, to some degree of "works" (again, you can _correctly_ say that no shell script ever works correctly).
I on the other hand, have had plenty of situations where some system somewhere is managed with some config management tool (such as puppet) and it is told "make this application with these dependencies" and the application, such as "manage elasticsearch index rotation" uses the system python and does pip install to install all the things. This idiom seems fine, but ultimately ends up with a hideous mess where it worked one day and didn't work a year later, because either the system python is different or the dependencies are all messed up or the pip tool itself on the system python isn't compatible with modern package distribution.
You can (correctly) say "don't do that" but the same idiom in a shell script will almost certainly work across decades regardless of if "sh" is bash or ash or ksh, to some degree of "works" (again, you can _correctly_ say that no shell script ever works correctly).
It is interesting that the data science and ML folks are willing to weather Python’s dependency mess Vs. the huge momentum Golang and (increasingly) Rust have built around their static binary philosophy.
Perhaps this is the future of Kubernetes , to be the only thing brave enough to run epoxied globs of .NET, Java and Python.
Perhaps this is the future of Kubernetes , to be the only thing brave enough to run epoxied globs of .NET, Java and Python.
Python and docker, with compose is a really good fit. Everything works, everything is boring, everything is stable all the time. And importantly, most problems are easily googled.
Just be sure to archive your artifacts. Both the ones you make and the ones you use to build output artifact.
Otherwise, your docker build tool will work today and be a screaming mess of broken dependencies tomorrow.
Otherwise, your docker build tool will work today and be a screaming mess of broken dependencies tomorrow.
I think the trick is to not have any dependencies, except Python itself, when writing such command line tools. Python does have a large standard library after all. While Python itself surely could be nicer, it is still easier to maintain such a script than a script of similar size of GNU Bash code.
Bash scripts don’t break, when left unattended for months/years. Python scripts do.
It can’t break if it were never correct in the first place. Bash scripts are always chock-full of bugs, and only work when everything in its environment is the same. That folder now has two files instead of one? Now it just stops working.
In my experience, they don’t have more bugs than Python scripts. That’s assuming they’re shorter than 50 LOC. Long before my scripts reach this size I convert them straight to Go. That’s the most problem-free strategy.
Pin your versions.
Also - to make the equivalent safe bash program compared to a typical python implementation is ... a lot of work. Enough that imo the python version is worth the maintenance.
Pinning versions doesn’t help when the old version of some dependency no longer works with your new OS or hardware.
I mostly only code in Python but this article really spoke to me. I have <10 personal Python scripts that I use heavily for my job, but they are such a bear to maintain.
Meanwhile my two old Autohotkey scripts that I wrote 10+ years ago and rarely touch still chug along perfectly.
I mostly only code in Python but this article really spoke to me. I have <10 personal Python scripts that I use heavily for my job, but they are such a bear to maintain.
Meanwhile my two old Autohotkey scripts that I wrote 10+ years ago and rarely touch still chug along perfectly.
The recent deprecation warning message of `egrep` is a prime example that bash scripts can break (depending on stderr processing). They will definitely break once the alias is removed.
egrep has been on a deprecation path for 15 years, and the replacement is incredibly straightforward. Also, I think egrep will generally just continue to work.
I'm not sure what you mean by "recent", but this is more longevity than we get in the node/JS world.
I'm primarily a JS (now TS) dev, who also throws bash at things when it makes more sense, but let's not kid ourselves that it's the same.
I'm not sure what you mean by "recent", but this is more longevity than we get in the node/JS world.
I'm primarily a JS (now TS) dev, who also throws bash at things when it makes more sense, but let's not kid ourselves that it's the same.
*Statically typed, not strongly typed
In the past years Java is a strong candidate for cmd tools.Using Quarkus + Picocli + GraalVM for native compiling, gives you a standalone binary which can be used on any platform.
The python build/install/distribute situation is so bad, XKCD made fun of it years ago https://xkcd.com/1987/
> don't need to go on a bunch of side missions every time i run npm install
Lol what a great way to describe what running a simple "npm install" entails.
Lol what a great way to describe what running a simple "npm install" entails.
Try doing this on a 5 year old project. You'll very likely end up in dependency hell.
There is a solution though - use of nvm and .nvmrc (to control the version of node and npm that you use), and use of npm ci (which installs packages as they were at the time, rather than installing newer versions than specified in package-lock.json (because too many devs rarely ever pin versions) instead of npm install / npm i).
nvm (Node Version manager): https://github.com/nvm-sh/nvm npm ci: https://docs.npmjs.com/cli/v6/commands/npm-ci
There is a solution though - use of nvm and .nvmrc (to control the version of node and npm that you use), and use of npm ci (which installs packages as they were at the time, rather than installing newer versions than specified in package-lock.json (because too many devs rarely ever pin versions) instead of npm install / npm i).
nvm (Node Version manager): https://github.com/nvm-sh/nvm npm ci: https://docs.npmjs.com/cli/v6/commands/npm-ci
I rarely if ever get version mismatches for a normal npm install because upgrades by default only do minors. If a package has a breaking change in a minor it's not a JS issue, it's not a npm issue, it's a "this package author made a breaking change in a minor" issue.
And regarding nvm: That's obvious. This is the same for almost any runtime. If you have the wrong jdk version it doesn't work, if you have the wrong (whatever iOS uses for xcode) version it doesn't work, if you have the wrong version of gcc it doesn't work.
Obviously wrong is not always the same, more up-to-date versions of gcc can compile older programs (maybe) but that's also the same for Node unless otherwise specified in the packages.
And regarding nvm: That's obvious. This is the same for almost any runtime. If you have the wrong jdk version it doesn't work, if you have the wrong (whatever iOS uses for xcode) version it doesn't work, if you have the wrong version of gcc it doesn't work.
Obviously wrong is not always the same, more up-to-date versions of gcc can compile older programs (maybe) but that's also the same for Node unless otherwise specified in the packages.
Why learn cmd and bash when you can just learn js? Easier to maintain 1 language than 1+.
My software in js from 7 years ago still works.
My software in js from 7 years ago still works.
But it's not that simple, for an example I have older personal projects as well which I'm unable to run without doing considerable changes to the code after moving to M1 chip.
Just because I'm unable to run older versions of node and thus unable to run some of the dependencies and thus need to update the dependencies and then the code etcetc.
Yes, I could use docker and containers... Yes, I could use Rosetta...
But it doesn't run natively like it did before.
But bash still works...
Just because I'm unable to run older versions of node and thus unable to run some of the dependencies and thus need to update the dependencies and then the code etcetc.
Yes, I could use docker and containers... Yes, I could use Rosetta...
But it doesn't run natively like it did before.
But bash still works...
Exactly. Dependency hell is easy to avoid by avoiding dependencies. Modern JS with modules and classes is really good for simple projects, esp. prototypes that don't have to work everywhere. No framework, no special utilities that all have their quirks. And no packaging either. Much, much simpler this way.
Likewise, concurrency stops being a problem if I avoid threads and async as much as possible.
I'm starting to feel old now that I can no longer pretend I've only got two threads, network and UI, where everything is fine if I wrap the network response with "do on main thread" and crashes reliably and instantly whenever I forgot.
I'm starting to feel old now that I can no longer pretend I've only got two threads, network and UI, where everything is fine if I wrap the network response with "do on main thread" and crashes reliably and instantly whenever I forgot.
This comment here is exactly the problem with JS people.
If you are making a big thing out of learning(!) cmd(!!!) then you shouldn't be working in software development, period.
7 years is a flex only in a JS world. As others mentioned, try 35.
My scripts in ksh from 25 years ago still work.
because js should never be the first choice in any case...
To avoid a rm -rf / ?
Web has always been about the hot new thing. It was part of why I left-in 2001.
I left for a couple of years for Windows desktop and Android native development, turns out that the GUI civil wars at Microsoft, and the whole Java vs Kotlin vs AndroidX vs JetPack vs NDK being like a 10% project, are even worse than dealing with Web quirks.
So even though I rather do native development, here we are back at the Web and distributed computing.
So even though I rather do native development, here we are back at the Web and distributed computing.
> the GUI civil wars at Microsoft
The wars are done.
Look at what Microsoft actually uses for GUIs, not what they recommend. All the new Microsoft apps are written in Electron.
The wars are done.
Look at what Microsoft actually uses for GUIs, not what they recommend. All the new Microsoft apps are written in Electron.
Actually not all of them use Electron as such.
Teams is thankfully now using WebView2 (less resource heavy), new Outlook is a PWA.
However I do agree with the gist of your comment, it appears everyone from the GUI civil wars that doesn't want to stay until the end has jumped ship to "Azure OS", or the competition (Amazon/Google), and most UIs are Web based or the classical Win32 ones.
Naturally "Azure OS" applications use the Web as UI.
Only WinDev themselves seem head down on using WinUI, and still don't grasp the competition, not only the WebView2 based stuff into their turf, the other OSes that don't require dealing with COM and C++ for basic stuff like OS widgets.
Teams is thankfully now using WebView2 (less resource heavy), new Outlook is a PWA.
However I do agree with the gist of your comment, it appears everyone from the GUI civil wars that doesn't want to stay until the end has jumped ship to "Azure OS", or the competition (Amazon/Google), and most UIs are Web based or the classical Win32 ones.
Naturally "Azure OS" applications use the Web as UI.
Only WinDev themselves seem head down on using WinUI, and still don't grasp the competition, not only the WebView2 based stuff into their turf, the other OSes that don't require dealing with COM and C++ for basic stuff like OS widgets.
> All the new Microsoft apps are written in Electron.
Is this why the new calculator app takes over 5 seconds to show up on screen?
Is this why the new calculator app takes over 5 seconds to show up on screen?
Nope, that is the UWP security container most likely.
https://github.com/microsoft/calculator
https://github.com/microsoft/calculator
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...
Why has nobody mentioned that you can (and should) just lock your dependency versions…?
Because that stop short that complain train.
nvm is my solution to this
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
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
> Your projects also need to consider pinning their dependencies to a specific version
At that point, you should consider just using your version control system to handle versioning instead of trying to route around it, poorly.
At that point, you should consider just using your version control system to handle versioning instead of trying to route around it, poorly.
As a long-time ruby user where bundler has done version pinning for decades, I think this is a core feature of any dependency management system, not some kind of "routing around it."
I'm not sure what "your own version control system" means. Checking all dependencies into (eg) git? I'm not sure how you deal with indirect/second-level dependencies, but any kind of roll your own like that to me is what I'd call "routing around" the failures of your platform dependency management system.
Correct dependency pinning also allows you automated ways to upgrade dependencies, resolving requirement trees, within stated bounds specified per-dependency (like keep to same major version). It just happens when you want, not every time you install or deploy.
I'm not sure what "your own version control system" means. Checking all dependencies into (eg) git? I'm not sure how you deal with indirect/second-level dependencies, but any kind of roll your own like that to me is what I'd call "routing around" the failures of your platform dependency management system.
Correct dependency pinning also allows you automated ways to upgrade dependencies, resolving requirement trees, within stated bounds specified per-dependency (like keep to same major version). It just happens when you want, not every time you install or deploy.
> I'm not sure what "your own version control system" means.
Me neither. Where did that come from? I didn't write it. (It's not in my comment, just yours.)
Me neither. Where did that come from? I didn't write it. (It's not in my comment, just yours.)
Ah apparently my brain inserted `own`, looking back you said "just using your version control system". OK, I think I'd write the rest of my comment the same still; does it mean putting all your dependencies (source/binary) in your version control (eg) git?
Yes—using your VCS/SCM to version control the source code.
shameless plug
If you want to avoid having to write your own args parser everytime or think getopt is a pain, you should check out my little project:
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.
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.
hey='you can define variables' do_this='without commandline parsing' ./thing
#!/bin/sh
hey=${hey:='default one'}
do_this=${do_this:='default two'}
not_that=${not_that:='because getopts is a nightmare'}
echo "${hey} ${do_this} ${not_that}"
#!/bin/sh
hey=${hey:='default one'}
do_this=${do_this:='default two'}
not_that=${not_that:='because getopts is a nightmare'}
echo "${hey} ${do_this} ${not_that}"
If you want to be more DRY (do not repeat yourself) with regard to the variable names you can use the `:` command inside the script (which just expands its arguments) as in
Also, besides shells most prog.langs have easy ways to receive these { getenv in C, os.environ.get("do_this", "default two") in Python, etc. }.
--
I think what people really miss here is the (rarely used, I guess?) shell calling/invocation syntax @cduzz points out of:
Soon enough you may outgrow shell programming and, if you become used to such nice conveniences and are willing to learn Nim, I might then recommend something more like https://github.com/c-blake/cligen
: ${hey:='default one'}
Also, besides shells most prog.langs have easy ways to receive these { getenv in C, os.environ.get("do_this", "default two") in Python, etc. }.
--
I think what people really miss here is the (rarely used, I guess?) shell calling/invocation syntax @cduzz points out of:
var1=val1 var2=val2 program
program --var1=val1 --var2=val2
help= program
grep '^: ' "$0"
Soon enough you may outgrow shell programming and, if you become used to such nice conveniences and are willing to learn Nim, I might then recommend something more like https://github.com/c-blake/cligen
I’ve been bashing for decades and never thought of that. Thank you
You might also see ideas in https://news.ycombinator.com/item?id=34147636
Nim is great for this use case.
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..
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..
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.
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.
Don't you find it odd that you're willing to distinguish .NET as a concept from e.g. a language like C#, but when it comes to what is, in reality, the NodeJS ecosystem that you have an issue with, you pin it broadly on what you call "javascript" (also a language)?
> There's no such thing as "LTS" in javascript.
In fact, there is. The language is stable—it's at least as backwards compatible as C# (if not moreso). There are even very stable platform APIs available outside the language core, e.g. the non-experimental stuff that the WHATWG/W3C standardizes. What you're doing though is opting for an opinionated, incompatible, vendor-specific fork (NodeJS), then experiencing the ensuing pain that comes with that decision.
Maybe if you like the stability of .NET and you find yourself having to use JS, you should rally for a JS-for-.NET cause instead of tacitly feeding the ongoing JS-with-NodeJS hegemony even though it keeps hurting you.
> There's no such thing as "LTS" in javascript.
In fact, there is. The language is stable—it's at least as backwards compatible as C# (if not moreso). There are even very stable platform APIs available outside the language core, e.g. the non-experimental stuff that the WHATWG/W3C standardizes. What you're doing though is opting for an opinionated, incompatible, vendor-specific fork (NodeJS), then experiencing the ensuing pain that comes with that decision.
Maybe if you like the stability of .NET and you find yourself having to use JS, you should rally for a JS-for-.NET cause instead of tacitly feeding the ongoing JS-with-NodeJS hegemony even though it keeps hurting you.
I refer to .net as the language a lot of the time too, they are tied even more strongly together, as described in https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... . I'm probably just not being precise about the language.
I'm happy to pin this on NodeJS but Node is the key reason why javascript is used for any non-web work at all and it's almost impossible to separate that.
The javascript ecosystem and it's breakage is down to Node, but the javascript ecosystem is node. Even if you only do web work now you still need node for the build toolchain, it's essentially impossible to escape it.
You can't realistically develop without it, even projects like react have given up on trying say anything but "just use create-react-app".
I'm happy to pin this on NodeJS but Node is the key reason why javascript is used for any non-web work at all and it's almost impossible to separate that.
The javascript ecosystem and it's breakage is down to Node, but the javascript ecosystem is node. Even if you only do web work now you still need node for the build toolchain, it's essentially impossible to escape it.
You can't realistically develop without it, even projects like react have given up on trying say anything but "just use create-react-app".
> the javascript ecosystem is node
It's not. NodeJS is NodeJS. JavaScript is JavaScript.
The James Webb Space Telescope isn't running Node LTS or pulling in left-pad.
If you want to make a lateral move and draw comparisons elsewhere: the Java ecosystem is not Sun/Oracle's mobile platform—which never took off, while Android thrives. Languages are absolutely separable from the big loud noisemaker (and the problems they bring with them).
As for build toolchains: even taking the comment that "if you only do web work now you still need node for the build toolchain" charitably, we could understand it to mean that NodeJS-based toolchains save you time, rather than that you strictly need them in a literal sense. Even that argument is dubious. It's worth considering, if people spent half as much time working on the drudge work that these toolchains are ostensibly supposed to be saving them time on, instead of dealing with the dysfunction that comes with these tools, where might they be? Ivan is doing a-okay with Photopea despite repudiating basically everything about NodeJS.
In practice, those toolchains have proven to be a false economy for many circumstances where they end up being (mis)used. More honestly, they're shiny distractions that people put at the forefront of their attention because that's what they like doing—and they're willing to lie to themselves by saying they're doing something essential.
> You can't realistically develop without it
Sorry, bud, this is wildly exaggerated. It's simple bullshit. I won't concede to such an argument that doesn't have a firm basis in truth.
Or, if you want a pithy rejoinder, here's one: "You can't realistically develop with it!"[1]
Firefox is one of the most advanced early codebases that made extensive use of JS for serious use—and still more serious than many of the things that people are writing in JS today—and there was no use of NPM—because neither it nor NodeJS (nor V8!) even existed yet.
1. <https://news.ycombinator.com/item?id=24495646>
It's not. NodeJS is NodeJS. JavaScript is JavaScript.
The James Webb Space Telescope isn't running Node LTS or pulling in left-pad.
If you want to make a lateral move and draw comparisons elsewhere: the Java ecosystem is not Sun/Oracle's mobile platform—which never took off, while Android thrives. Languages are absolutely separable from the big loud noisemaker (and the problems they bring with them).
As for build toolchains: even taking the comment that "if you only do web work now you still need node for the build toolchain" charitably, we could understand it to mean that NodeJS-based toolchains save you time, rather than that you strictly need them in a literal sense. Even that argument is dubious. It's worth considering, if people spent half as much time working on the drudge work that these toolchains are ostensibly supposed to be saving them time on, instead of dealing with the dysfunction that comes with these tools, where might they be? Ivan is doing a-okay with Photopea despite repudiating basically everything about NodeJS.
In practice, those toolchains have proven to be a false economy for many circumstances where they end up being (mis)used. More honestly, they're shiny distractions that people put at the forefront of their attention because that's what they like doing—and they're willing to lie to themselves by saying they're doing something essential.
> You can't realistically develop without it
Sorry, bud, this is wildly exaggerated. It's simple bullshit. I won't concede to such an argument that doesn't have a firm basis in truth.
Or, if you want a pithy rejoinder, here's one: "You can't realistically develop with it!"[1]
Firefox is one of the most advanced early codebases that made extensive use of JS for serious use—and still more serious than many of the things that people are writing in JS today—and there was no use of NPM—because neither it nor NodeJS (nor V8!) even existed yet.
1. <https://news.ycombinator.com/item?id=24495646>
But when I say "javascript ecosystem", I'm talking about Node, and that's clear from my writing.
I don't care for pedantry about what it might also refer to, I'm talking about NodeJS, npm and the problems with it, and that's clear because that's also what the original article is talking about.
I don't care for pedantry about what it might also refer to, I'm talking about NodeJS, npm and the problems with it, and that's clear because that's also what the original article is talking about.
> when I say "javascript ecosystem", I'm talking about Node
Can you change your habits?
> I'm talking about NodeJS, npm and the problems with it
So how about just saying that?
> and that's clear
It's not. A person doesn't have to go all in on Sapir–Whorf to recognize that this is fraught with peril.
The original article that you fall back on for support doesn't even agree with you; the argument that the author makes (explicitly, even) is that this actually is a JS-and-not-just-NodeJS problem.
Nor do your earlier remarks agree; you're ignoring now the pushback on your earlier remarks that escape is essentially/almost "impossible". Feels like you're going for a motte-and-bailey here (a type of bait-and-switch argument; see <https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy>).
Can you change your habits?
> I'm talking about NodeJS, npm and the problems with it
So how about just saying that?
> and that's clear
It's not. A person doesn't have to go all in on Sapir–Whorf to recognize that this is fraught with peril.
The original article that you fall back on for support doesn't even agree with you; the argument that the author makes (explicitly, even) is that this actually is a JS-and-not-just-NodeJS problem.
Nor do your earlier remarks agree; you're ignoring now the pushback on your earlier remarks that escape is essentially/almost "impossible". Feels like you're going for a motte-and-bailey here (a type of bait-and-switch argument; see <https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy>).
> Don't you find it odd that you're willing to distinguish .NET as a concept from e.g. a language like C#, but when it comes to what is, in reality, the NodeJS ecosystem that you have an issue with, you pin it broadly on what you call "javascript" (also a language)?
Does that matter? Both for front-end or back-end you generally use NodeJS now, if you are not using an entire other language (like WebAssembly for front-end and PHP for the back-end). Even if you get rid of javascript for the front-end, you'il still have it likely to compile or minify CSS.
Does that matter? Both for front-end or back-end you generally use NodeJS now, if you are not using an entire other language (like WebAssembly for front-end and PHP for the back-end). Even if you get rid of javascript for the front-end, you'il still have it likely to compile or minify CSS.
> Does that matter?
Well, yeah—for reasons already explained.
Millions of desktops will boot into Gnome Shell today. Millions more people, including people using Windows and Mac and not Gnome Shell, will open Firefox. There will be no NodeJS process running in the background in order to achieve any of this, nor will there be API-compatible runtime involved.
There's absolutely no reason not to say NodeJS when that's what you mean. There is a problem with blanket generalizations about "javascript" that implicate other software and software developers that have absolutely nothing to do with NodeJS or the any of the NodeJS-specific problems that are well past due (read: should have been solved by now). The world is bigger than the back-end/front-end dichotomy that webdevs spend all day thinking about.
I have no idea how to even respond to your CSS comments. Without even getting into whether it's true or not, it's just totally irrelevant. Painfully so. ChatGPT writes more salient responses.
Well, yeah—for reasons already explained.
Millions of desktops will boot into Gnome Shell today. Millions more people, including people using Windows and Mac and not Gnome Shell, will open Firefox. There will be no NodeJS process running in the background in order to achieve any of this, nor will there be API-compatible runtime involved.
There's absolutely no reason not to say NodeJS when that's what you mean. There is a problem with blanket generalizations about "javascript" that implicate other software and software developers that have absolutely nothing to do with NodeJS or the any of the NodeJS-specific problems that are well past due (read: should have been solved by now). The world is bigger than the back-end/front-end dichotomy that webdevs spend all day thinking about.
I have no idea how to even respond to your CSS comments. Without even getting into whether it's true or not, it's just totally irrelevant. Painfully so. ChatGPT writes more salient responses.
What I hear you say is that some publicly available third-party libraries written for use with JS are changing very often, and introduce incompatibilities and breaking changes.
And you write that some publicly available third-party libraries written for use with .NET change less often and/or do not introduce incompatibilities and breaking changes (as often).
Two true statements, which are totally and entirely unrelated to the JavaScript and .net.
> Bringing in libraries shouldn't mean burdening yourself with so much future incompatibility.
I agree, but it does, and the more active the library, the worse.. If you don't believe me, try writing absolutely cutting edge stuff in C, using whatever the most active and hip libraries you can find..
You'll have better success, not because C is a better language (though, I very much like it), but because stuff moves at a slower pace, even the hip C stuff is not _that_ hip, when you look at the amount of code contributed per unit of time, or the amount of new features implemented per release.
Of course I'm being general, you can certainly find JS libraries that are extremely solid, and you can certainly find C libraries that are very fragile, but in general.. they correlate well to the popularity/activity of the language.. but not with any inherent property of the actual language.
And you write that some publicly available third-party libraries written for use with .NET change less often and/or do not introduce incompatibilities and breaking changes (as often).
Two true statements, which are totally and entirely unrelated to the JavaScript and .net.
> Bringing in libraries shouldn't mean burdening yourself with so much future incompatibility.
I agree, but it does, and the more active the library, the worse.. If you don't believe me, try writing absolutely cutting edge stuff in C, using whatever the most active and hip libraries you can find..
You'll have better success, not because C is a better language (though, I very much like it), but because stuff moves at a slower pace, even the hip C stuff is not _that_ hip, when you look at the amount of code contributed per unit of time, or the amount of new features implemented per release.
Of course I'm being general, you can certainly find JS libraries that are extremely solid, and you can certainly find C libraries that are very fragile, but in general.. they correlate well to the popularity/activity of the language.. but not with any inherent property of the actual language.
i agree.
.net is a cathedral platform, well manicured by a small trusted force that tries to make eveything fit together, that works semi-cohesively, to produce a manufactured industrially syitable one-solution to everything.
js is a bazaar language, that had many intertwingular existences in different places, doing different in similar things in thousands of different ways. it's innovation & history is chaotic & messy, with many onetime behemoths left by the wayside (jquery, gulp/grunt, backbone, moment, request). everything is a bit messy & organic & grown together, pieces breaking off & advancing one direction then being woven back with another library to work a third way.
> There's no way around this problem but to dedicate hours every month to keep everything on the bleeding edge.
i dont disagree.
work has spent considerable time dragging a couple dozen old fairly complex react apps & services we inherited out from node 6, node 8 this year, freshening things up.
it is however amazing how much stuff did just work. how many deps we could look through the changelog on, say, that's fine, and upgrade, and tests pass & on deployment things keep moving along. did we get bleeding edge? eh, like 50% of the time. in many cases we didnt even bother trying to get current. we checked dependabot vulnerabilities & did what we had to, stayed in the past for now. these apps were all running, live, with traffic... it's amazing how much of this messy organic tangle does work.
we did run into some of the version conflicts & problems, some of the conservative concerns, the reasons for fear & trepidation you cite. it wasnt fun work. no one wanted to be here. but we got through it in quick order, and it ended up being a whole lot less pain than us engineers expected & budgeted for. we were left with the impression of ease. confidence grew.
as others have tried to point out, i dont think your real complaint is with JS specifically. the organic nature of this world doesnt suit your desires. and i think that's a reasonable stance, these arent unreasonable values/complaints. but on the other hand, the organic has, i think, taken over with rightful cause. Azure OS is in huge part React, huge part JS. the tech adapts much faster. not being a carefully staged industrially-focused cathedral, being an organic place that values & cherishes idea & potential, has let us try a lot of things & keep exploring where real value is, and has kept leading us to better places. we understand more through the experimentalness of the process, we see such vistas that the cathedral makers could not have dreamed, find higher heights & ascend. & yes, sometimes as we rise above the clouds, we spy yet higher peaks, and we must decide whether & how long to stay where we are, or to try again, move onwards.
personally this organic world has brough me great joy & a wonderful continual sense of progress. that we have kept honing ourselves, reshaping. it feels finally like we are starting to really settle down more, that we have made finer cuts at iteration. apis are much more stable. the platform has amassed a more solid core, as groups like WinterCG bless & spread more of the much developed web platform as stable trustworthy systems. React has spent years building towards Suspense & it seems uncharacteristically humble, for a framework that had iterated so much & so heavily for so long, & there's little on the radar that gives us a sense there will be a next breathtaking new era. the organic has settled, become over time more like the cathedral you might have hoped for.
.net is a cathedral platform, well manicured by a small trusted force that tries to make eveything fit together, that works semi-cohesively, to produce a manufactured industrially syitable one-solution to everything.
js is a bazaar language, that had many intertwingular existences in different places, doing different in similar things in thousands of different ways. it's innovation & history is chaotic & messy, with many onetime behemoths left by the wayside (jquery, gulp/grunt, backbone, moment, request). everything is a bit messy & organic & grown together, pieces breaking off & advancing one direction then being woven back with another library to work a third way.
> There's no way around this problem but to dedicate hours every month to keep everything on the bleeding edge.
i dont disagree.
work has spent considerable time dragging a couple dozen old fairly complex react apps & services we inherited out from node 6, node 8 this year, freshening things up.
it is however amazing how much stuff did just work. how many deps we could look through the changelog on, say, that's fine, and upgrade, and tests pass & on deployment things keep moving along. did we get bleeding edge? eh, like 50% of the time. in many cases we didnt even bother trying to get current. we checked dependabot vulnerabilities & did what we had to, stayed in the past for now. these apps were all running, live, with traffic... it's amazing how much of this messy organic tangle does work.
we did run into some of the version conflicts & problems, some of the conservative concerns, the reasons for fear & trepidation you cite. it wasnt fun work. no one wanted to be here. but we got through it in quick order, and it ended up being a whole lot less pain than us engineers expected & budgeted for. we were left with the impression of ease. confidence grew.
as others have tried to point out, i dont think your real complaint is with JS specifically. the organic nature of this world doesnt suit your desires. and i think that's a reasonable stance, these arent unreasonable values/complaints. but on the other hand, the organic has, i think, taken over with rightful cause. Azure OS is in huge part React, huge part JS. the tech adapts much faster. not being a carefully staged industrially-focused cathedral, being an organic place that values & cherishes idea & potential, has let us try a lot of things & keep exploring where real value is, and has kept leading us to better places. we understand more through the experimentalness of the process, we see such vistas that the cathedral makers could not have dreamed, find higher heights & ascend. & yes, sometimes as we rise above the clouds, we spy yet higher peaks, and we must decide whether & how long to stay where we are, or to try again, move onwards.
personally this organic world has brough me great joy & a wonderful continual sense of progress. that we have kept honing ourselves, reshaping. it feels finally like we are starting to really settle down more, that we have made finer cuts at iteration. apis are much more stable. the platform has amassed a more solid core, as groups like WinterCG bless & spread more of the much developed web platform as stable trustworthy systems. React has spent years building towards Suspense & it seems uncharacteristically humble, for a framework that had iterated so much & so heavily for so long, & there's little on the radar that gives us a sense there will be a next breathtaking new era. the organic has settled, become over time more like the cathedral you might have hoped for.
Dependencies being future liabilities is one reason why core programming skills are so important. A team with weak core programming skills will quickly make a mess of dependencies, because they will not dare to implement that left pad or that tree recursion themselves. The mess will work, but the cost will be inflicted for as long as the dependencies are in there.
Of course there are some things which getting into is not so recommended, because of high initial time cost. Like writing your own web framework. Or correctly implementing data structures or difficult to understand mathematical algorithms, or cryptography stuff.
Of course there are some things which getting into is not so recommended, because of high initial time cost. Like writing your own web framework. Or correctly implementing data structures or difficult to understand mathematical algorithms, or cryptography stuff.
>JavsScript, which is a scripting language
It clearly is not. Whatever it was supposed to be, or might have been in the past JS is not a scripting language.
It clearly is not. Whatever it was supposed to be, or might have been in the past JS is not a scripting language.
Even if you write something yourself, it might not work on a future version of your OS.
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.
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.
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.
I use go a lot and also love it. I did find it odd in the early days to not have a package manager, but they seem to have mostly built on the experience of NPM and got it right.
Yeah, the initial days were indeed odd, and modules absolutely required, otherwise the ecosystem would probably be a tangle of different 3rd party solutions for vendoring and version-pinning right now. Glad they avoided that.
They were building in the right direction with the idea that a world where public code repositories exist, a) doesn't need yet-another-repository for just one language, and b) should acknowledge the real world by specifying these resources directly in the code.
They were building in the right direction with the idea that a world where public code repositories exist, a) doesn't need yet-another-repository for just one language, and b) should acknowledge the real world by specifying these resources directly in the code.
> They all have issues with versioning
Not on this scale. Let's leave out the versions of the NodeJS for clarity's sake (nvm is not for managing packages, afaik), and focus on packages. You could argue that the complexity is because of JavaScript's popularity, but it's hard to deny that running a seemingly simple `npm install` will net you tons of dependencies, and that's typical regardless of what you're installing.
Not on this scale. Let's leave out the versions of the NodeJS for clarity's sake (nvm is not for managing packages, afaik), and focus on packages. You could argue that the complexity is because of JavaScript's popularity, but it's hard to deny that running a seemingly simple `npm install` will net you tons of dependencies, and that's typical regardless of what you're installing.
Yeah this is really the Achilles heel of the node ecosystem. It turns out having an expansive standard library is important since I'd like to think most of these issues would disappear if that were the case.
Python is worse. By far in my opinion.
Why and how?
In my opinion Python modules are rarely "one function" dependencies. And while the ecosystem is certainly enormous, so is the standard library, so for many common tasks, I don't even need to `pip install` a new dependency.
Yes, "virtual environments" used to be kind of messy, and the fact that there are usually 2 competing ways to install modules (via the OS pkg manager and pip) doesn't help either. But since `pyenv` and `venv` exist now, venvs are much less of a hassle than they used to be.
In my opinion Python modules are rarely "one function" dependencies. And while the ecosystem is certainly enormous, so is the standard library, so for many common tasks, I don't even need to `pip install` a new dependency.
Yes, "virtual environments" used to be kind of messy, and the fact that there are usually 2 competing ways to install modules (via the OS pkg manager and pip) doesn't help either. But since `pyenv` and `venv` exist now, venvs are much less of a hassle than they used to be.
>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.
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.
My dude, have you lived in the tech (or otaku) community for long?
Making a piece of tech (or any media) part of your identity is a tale as old as time, and arguably getting worse.
I mean, you’re right, it is pathetic, and we need to collectively grow up. But you might as well be saying “be a well adjusted person, eat well and exercise”. We are so insecure and needy that we ascribe our self worth to a tech fad or piece of media or media figure. But it’s the core problem we have in western society today: geek/otaku culture, with its highs and lows, has gone mainstream. We are so comfortable and abundant with basic resources that we are bored and unsatisfied with our status and function in society and desperate to fill that gap with something to geek out on.
We live in a world where Lennart Poeterring gets death threads over systemd, the Golang maintainers get threats over generics, TV show runners get death threats when they change a character’s story arc. And politically there’s lots of folks willing to eject democracy so their adopted club can rule for eternity. Is it all for the lulz?
Anyway I took this on a tangent but… really, “I can’t believe you use that programming language” has always been bad as far as I can remember (at least 35-40 years).
Making a piece of tech (or any media) part of your identity is a tale as old as time, and arguably getting worse.
I mean, you’re right, it is pathetic, and we need to collectively grow up. But you might as well be saying “be a well adjusted person, eat well and exercise”. We are so insecure and needy that we ascribe our self worth to a tech fad or piece of media or media figure. But it’s the core problem we have in western society today: geek/otaku culture, with its highs and lows, has gone mainstream. We are so comfortable and abundant with basic resources that we are bored and unsatisfied with our status and function in society and desperate to fill that gap with something to geek out on.
We live in a world where Lennart Poeterring gets death threads over systemd, the Golang maintainers get threats over generics, TV show runners get death threats when they change a character’s story arc. And politically there’s lots of folks willing to eject democracy so their adopted club can rule for eternity. Is it all for the lulz?
Anyway I took this on a tangent but… really, “I can’t believe you use that programming language” has always been bad as far as I can remember (at least 35-40 years).
There's nothing wrong with making a language part of your identity but Darren is not even doing that, he simply said he loves JS.
I don't identify as a Python dev and I don't even work with Python much lately, I know package management isn't great and PyPI registry suffered malicious attacks recently, but I can still say I love Python, I started with it and the syntax is enjoyable.
But you are clearly making language hate part of your identity.
(BTW I'd actually thank JS for TS, if they added types natively they'd probably be limited like Python's and we'd be stuck with it, but they didn't so now we have a new language with a great type system that evolved beyond JS with variations that compile into WASM and such.)
I don't identify as a Python dev and I don't even work with Python much lately, I know package management isn't great and PyPI registry suffered malicious attacks recently, but I can still say I love Python, I started with it and the syntax is enjoyable.
But you are clearly making language hate part of your identity.
(BTW I'd actually thank JS for TS, if they added types natively they'd probably be limited like Python's and we'd be stuck with it, but they didn't so now we have a new language with a great type system that evolved beyond JS with variations that compile into WASM and such.)
Yeesh this really kicked off but thanks for the defence. For clarity I identify as a male programmer with Lego loving tendencies. JS is simply a tool I actually mostly enjoy using. I also use a lot of other languages, but really JS is one I'm always happy to come back to!
> 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.
You act as if this is something that was forced upon you.
Giving some "rando" the power to "own" a function in your app is a power that you choose to give them. If you don't want that then don't do it.
Sentences like "Other languages vendor dependencies by default" are nonsense statements. Stop saying "language" when you mean "the kind of people I do/don't have a problem with".
> This isn't a JS issue, it's an ecosystem and culture issue.
Right, and when people tacitly insist otherwise—by being sloppy with their words and thoughts—then it makes it harder for people to recognize the problem, see what specifically needs to be fixed, and then proceed with the "okay, let's fix it now" part.
You act as if this is something that was forced upon you.
Giving some "rando" the power to "own" a function in your app is a power that you choose to give them. If you don't want that then don't do it.
Sentences like "Other languages vendor dependencies by default" are nonsense statements. Stop saying "language" when you mean "the kind of people I do/don't have a problem with".
> This isn't a JS issue, it's an ecosystem and culture issue.
Right, and when people tacitly insist otherwise—by being sloppy with their words and thoughts—then it makes it harder for people to recognize the problem, see what specifically needs to be fixed, and then proceed with the "okay, let's fix it now" part.
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.
Bugs happen but it's by no means a constant thing.
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).
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).
> 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.
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.
> I love JS
That is the problem. You love a hammer and see nails everywhere.
That is the problem. You love a hammer and see nails everywhere.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
My experience matches this.
If there is a native dependency, then moving major node versions or moving to arm can cause difficulties or straddling the python version the gyp build system is based on.
It's worlds easier than trying to insure your C/C++ build environment is prepped properly to build a binary.
Updating libraries is usually not too bad, even across major versions. But that can be a bit of a wormhole trying to get everything squared away and all versions updated. This seems to be particularly true since all major frameworks I've used have gone from snake case deps (framework-module) to @framework/module.
If there is a native dependency, then moving major node versions or moving to arm can cause difficulties or straddling the python version the gyp build system is based on.
It's worlds easier than trying to insure your C/C++ build environment is prepped properly to build a binary.
Updating libraries is usually not too bad, even across major versions. But that can be a bit of a wormhole trying to get everything squared away and all versions updated. This seems to be particularly true since all major frameworks I've used have gone from snake case deps (framework-module) to @framework/module.
> 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?
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?
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)
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)
> 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.
Seems like it was created by noobs. It happens. I guess it's not packaged in a distribution for a reason. A distro maintainer would tell them to fix that crap.
> but it’s just as likely that the thing you need depends on a particular version
No it's not likely. Openssl is a shared library that you can just replace with a version that has whatever fix. Unless you do rust/golang/docker/static linking… and the standard is to dynamically link.
Running vulnerable software is always a risk. You might think you secured it, but vulnerabilities can get chained.
Anyway I'm sure there are crappy softwares being written in any language. But the problem with js seems to be that even a state of the art one incurs such problems continuously because all dependencies are crappy.
Seems like it was created by noobs. It happens. I guess it's not packaged in a distribution for a reason. A distro maintainer would tell them to fix that crap.
> but it’s just as likely that the thing you need depends on a particular version
No it's not likely. Openssl is a shared library that you can just replace with a version that has whatever fix. Unless you do rust/golang/docker/static linking… and the standard is to dynamically link.
Running vulnerable software is always a risk. You might think you secured it, but vulnerabilities can get chained.
Anyway I'm sure there are crappy softwares being written in any language. But the problem with js seems to be that even a state of the art one incurs such problems continuously because all dependencies are crappy.
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.
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.
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...
Something is indeed off here. Even Node 0.x didn't have so many problems (granted, the debugger back then, ahem, left one wanting).
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.
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.
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.
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.
> 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.
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?
> 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.
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.
About python past mistakes and future breaking changes, I recommend you to check this talk[0] about the topic
[0] https://www.youtube.com/watch?v=qC5Po77bfKI
[0] https://www.youtube.com/watch?v=qC5Po77bfKI
Still to this day nothing is as painful as trying to get a pip package or ruby gem with a C dependency to build on hardware where a wheel or whatever the ruby equivalent is unlikely to exist.
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.
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'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
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.
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.
>> 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.
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.
rapid is ok… constantly breaking backwards compatibility is the issue.
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..
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.
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.
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?
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?
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.
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.
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.
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.
"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?
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.
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.
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.
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.
To compare plain JS and React/stuff with C and assembly, that is a bit much. The comparison of things from so fundamentally different ecosystems is not going to yield a convincing argument.
"Smart" people are actually dump, if they use an overblown framework for something as simple as a switch on a website and thereby destroy normal browser functionality, because most of them do not actually know how to use their hammer.
So once one has carefully considered not using a full blown megabytes sized framework and simply writing a few lines of JS instead, coupled with standard conform CSS and has actually thought about what parts of a website really need to be interactive, then one can still decide point-wise / component-wise, where to use a framework.
The problem in the JS community is a huge load of people, who present their specific solution as a general solution and others who trust them and add dependencies to their project. Putting something like left pad as a package shows what I am talking about. There is no need to have such a simple thing be a package and no harm in writing a single simple function, when one needs it. But in JS ecosystem there are also loads of devs who just started out developing and they are happy to choose dependency after dependency, because it means they can have it now, without having to code it up themselves, even if it should be a simple exercise. That does not lead to being very smart. Smart is, when I can avoid dependencies, due to intelligently coding simple things myself in generally reusable ways, so that it does not impact future development. But with most of the JS ecosystem mentality, people never get there.
"Smart" people are actually dump, if they use an overblown framework for something as simple as a switch on a website and thereby destroy normal browser functionality, because most of them do not actually know how to use their hammer.
So once one has carefully considered not using a full blown megabytes sized framework and simply writing a few lines of JS instead, coupled with standard conform CSS and has actually thought about what parts of a website really need to be interactive, then one can still decide point-wise / component-wise, where to use a framework.
The problem in the JS community is a huge load of people, who present their specific solution as a general solution and others who trust them and add dependencies to their project. Putting something like left pad as a package shows what I am talking about. There is no need to have such a simple thing be a package and no harm in writing a single simple function, when one needs it. But in JS ecosystem there are also loads of devs who just started out developing and they are happy to choose dependency after dependency, because it means they can have it now, without having to code it up themselves, even if it should be a simple exercise. That does not lead to being very smart. Smart is, when I can avoid dependencies, due to intelligently coding simple things myself in generally reusable ways, so that it does not impact future development. But with most of the JS ecosystem mentality, people never get there.
> if they use an overblown framework for something as simple as a switch on a website and thereby destroy normal browser functionality
Likely not what you meant, but FYI there is no native "switch" control in HTML - you do need to use a CSS or JS framework if you want something like iOS switch control. QED
Likely not what you meant, but FYI there is no native "switch" control in HTML - you do need to use a CSS or JS framework if you want something like iOS switch control. QED
Your definition of "QED" is quite a funny one.
I don't need a JS framework for a thing, that has 2 states, which can be realized using 2 CSS classes and toggling between them. That's maybe a 3 liner, if at all.
I am not using iOS and have no interest in it, so I have no idea what is so special about an _iOS_ switch control. Since I don't know what is that is, I also cannot really want to have it.
Fairly sure that I could probably find some easy to follow tutorial on how to make something graphically resemble a switch, if a checkbox is not sufficient for whatever reason, if I look for it ... Oh I just found a website which lists 20 of them in pure CSS on the first search query I entered: "plain css js make switch"
I don't need a JS framework for a thing, that has 2 states, which can be realized using 2 CSS classes and toggling between them. That's maybe a 3 liner, if at all.
I am not using iOS and have no interest in it, so I have no idea what is so special about an _iOS_ switch control. Since I don't know what is that is, I also cannot really want to have it.
Fairly sure that I could probably find some easy to follow tutorial on how to make something graphically resemble a switch, if a checkbox is not sufficient for whatever reason, if I look for it ... Oh I just found a website which lists 20 of them in pure CSS on the first search query I entered: "plain css js make switch"
CheckBox is a native HTML switch control.
Change my mind.jpg
Change my mind.jpg
> Do NOT learn React, Node.js or Tailwind. Learn HTML, JS and CSS.
How exactly should I use html and css to replace nodejs?
How exactly should I use html and css to replace nodejs?
You don't do server side code in JS and then you don't have a need for Node.js. Easy.
Learning React, Node.js, and Tailwind doesn’t mean that you’re not learning HTML, JS, or CSS…
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".
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".
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.
It is hard to take a comment serious which compares not using React to not being able to do anything productively. It looks like a very junior React-only dev comment.
> The argument is to not use React or similar, when a simpler way using standard conform means is available.
Please show me which part of any current or future proposals show a declarative UI + state + input + template binding mechanism which React or even something like handlebars provide.
If you're going to mention three or four different API's and explaining combining them together, then you've just reinvented a worse X framework.
You can't just dismiss everything as "well you can do X with the native platform" which is literally what I'd already made an analogy for.
> It looks like a very junior React-only dev comment.
Personal attacks, nice. If you believe I'm a junior for my comments then you are free to believe what you want, it does not change reality.
Please show me which part of any current or future proposals show a declarative UI + state + input + template binding mechanism which React or even something like handlebars provide.
If you're going to mention three or four different API's and explaining combining them together, then you've just reinvented a worse X framework.
You can't just dismiss everything as "well you can do X with the native platform" which is literally what I'd already made an analogy for.
> It looks like a very junior React-only dev comment.
Personal attacks, nice. If you believe I'm a junior for my comments then you are free to believe what you want, it does not change reality.
You can buzzword all day long, but that doesn't make the typical React component any more declarative than the next script. Components reyling on internal state, querying that state and then munging some JS code into some HTML-like template and mutating the state again, when a user interaction happens -- That's hardly a declarative UI. It also does not become more declarative due to using an angle bracket notation for components.
One can look at some Prolog code to get an actual idea about what declarative means. In React you are not writing down constraints and logic rules, according to which React automatically figures things out. You are not working with relations, which need to be kept true. React is far from a configuration only kind of framework.
To claim something like one cannot be productive without using React or similar framework is really a silly thing to claim. Most websites do not even need to use any such framework, because in their nature, they are not interactive. They show information and that is it. Then there is a set of websites, which has here and there some small interactive widget, which one could argue to use a framework for, in parts, not for the whole friggin website. This still allows for people, who merely want to retrieve the information and leave without interacting. The third and smallest category is then the set of websites, which actually need interactivity and state in the frontend everywhere, where such a framework can be justified.
One can look at some Prolog code to get an actual idea about what declarative means. In React you are not writing down constraints and logic rules, according to which React automatically figures things out. You are not working with relations, which need to be kept true. React is far from a configuration only kind of framework.
To claim something like one cannot be productive without using React or similar framework is really a silly thing to claim. Most websites do not even need to use any such framework, because in their nature, they are not interactive. They show information and that is it. Then there is a set of websites, which has here and there some small interactive widget, which one could argue to use a framework for, in parts, not for the whole friggin website. This still allows for people, who merely want to retrieve the information and leave without interacting. The third and smallest category is then the set of websites, which actually need interactivity and state in the frontend everywhere, where such a framework can be justified.
> 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.
There are no simple ways to build UIs available in HTML5 and CSS3.
It has neither state handling, nor reactivity, nor any APIs that don't make you tear you hair out (or build another lib/framework).
It's a horrendously bad half-low-level half-high-level API with hundreds of one-off solutions and special cases that form no coherent whole.
You still can't reliably animate adding to and deleting items from a list without hacks because even if you so much as look at DOM, it will re-layout and re-draw the entire document.
It still has no collection of well-specified built-in controls beyond a few primitive ones. https://open-ui.org/ is about twenty years too late.
But sure, you can finally put items in grids now. I guess that's nice. But when you need a dialog element you need copious amounts of hacky Javascript to make it properly accessible. Go figure.
There are no simple ways to build UIs available in HTML5 and CSS3.
It has neither state handling, nor reactivity, nor any APIs that don't make you tear you hair out (or build another lib/framework).
It's a horrendously bad half-low-level half-high-level API with hundreds of one-off solutions and special cases that form no coherent whole.
You still can't reliably animate adding to and deleting items from a list without hacks because even if you so much as look at DOM, it will re-layout and re-draw the entire document.
It still has no collection of well-specified built-in controls beyond a few primitive ones. https://open-ui.org/ is about twenty years too late.
But sure, you can finally put items in grids now. I guess that's nice. But when you need a dialog element you need copious amounts of hacky Javascript to make it properly accessible. Go figure.
People have built "UIs" on websites for decades, without the current flavor of SPA web frameworks. It is actually very easy to put things like a navigation and forms and such things on a website. Most websites do not need more than that. They merely show some information. Maybe you can register through a form or login through a form to see some more information. Not every website needs to be a SPA. The use-case you are apparently relating to, the one of websites really needing a more complex desktop-like UI, is merely a small percentage of websites. If you find yourself building a SPA on every second project, then you are most likely just following hype.
If you find yourself wanting to put dialogs on a website, consider showing information in a different way, more appropriate to the web. Work on your assumptions of how things must be done and some problems will disappear without ever having to write gnarly code.
Aside from that, writing a dialog is really not that difficult. I've done that before and I didn't need any framework to do it. Just don't rely on its modality for security, obviously, because one does not rely on frontend code for security anyway. Element zapper will make short work out of any dialog, that tries to block the stuff underneath it.
Ultimately the browser is not the desktop. It has a different use-case. Too many people do not understand this and try to shoehorn things into being "like on the desktop". Write desktop programs, if you want the desktop (not Electron shit ...). Write websites, if you want the web and the browser. Both have their own quirks and complications. Trying to force one into the other will only lead to more complications. Good design pays attention to the medium.
If you find yourself wanting to put dialogs on a website, consider showing information in a different way, more appropriate to the web. Work on your assumptions of how things must be done and some problems will disappear without ever having to write gnarly code.
Aside from that, writing a dialog is really not that difficult. I've done that before and I didn't need any framework to do it. Just don't rely on its modality for security, obviously, because one does not rely on frontend code for security anyway. Element zapper will make short work out of any dialog, that tries to block the stuff underneath it.
Ultimately the browser is not the desktop. It has a different use-case. Too many people do not understand this and try to shoehorn things into being "like on the desktop". Write desktop programs, if you want the desktop (not Electron shit ...). Write websites, if you want the web and the browser. Both have their own quirks and complications. Trying to force one into the other will only lead to more complications. Good design pays attention to the medium.
> It is actually very easy to put things like a navigation and forms and such things on a website.
That's about 1% of 1% of what people want to build.
> Most websites do not need more than that.
That we can agree on
> If you find yourself wanting to put dialogs on a website, consider showing information in a different way, more appropriate to the web.
dialog is literally a web standard in the web platform you so ardently advocate for. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
> Aside from that, writing a dialog is really not that difficult.
Tell me you've never built a proper accessible dialog without telling you've never built one.
> Too many people do not understand this and try to shoehorn things into being "like on the desktop".
I can empathise with this sentiment because I've expressed it myself many times. However, that ship has sailed and the platform has not adjusted in the least.
That's about 1% of 1% of what people want to build.
> Most websites do not need more than that.
That we can agree on
> If you find yourself wanting to put dialogs on a website, consider showing information in a different way, more appropriate to the web.
dialog is literally a web standard in the web platform you so ardently advocate for. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
> Aside from that, writing a dialog is really not that difficult.
Tell me you've never built a proper accessible dialog without telling you've never built one.
> Too many people do not understand this and try to shoehorn things into being "like on the desktop".
I can empathise with this sentiment because I've expressed it myself many times. However, that ship has sailed and the platform has not adjusted in the least.
Oh in theory you are correct, but in practice once people are given a hammer, everything starts to look like a nail, especially since they do not yet have the basics down well enough and it does lead to them not really learing the basics, because "it also works with React" (no matter how shitty and with how much overhead)
> 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
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
> Most of the modern web will be broken on older devices.
And the super heavy js websites will work?
And the super heavy js websites will work?
Not necessarily.
How old and how backward compatible are you thinking?
- Symbol is 2014-2015
- Map is 2014-2015
- Weak* data structures and their methods span 2014-2021
- WebGL 2.0 is 2017-2021
- Custom Elements are 2017-2021
- Chrome-only non-standards (hardware APIs and a bunch of others) are pumped out at a rate of up to 400 per year
- WebAssembly MVP is 2017-2018
And so on. That's off the top of my head. None of them are backwards compatible. Some of them cannot be polyfilled.
How old and how backward compatible are you thinking?
- Symbol is 2014-2015
- Map is 2014-2015
- Weak* data structures and their methods span 2014-2021
- WebGL 2.0 is 2017-2021
- Custom Elements are 2017-2021
- Chrome-only non-standards (hardware APIs and a bunch of others) are pumped out at a rate of up to 400 per year
- WebAssembly MVP is 2017-2018
And so on. That's off the top of my head. None of them are backwards compatible. Some of them cannot be polyfilled.
This attitude usually results in a company inventing some bespoke abstraction/framework whilst saying they are following standards.
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.
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.
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
- 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
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.
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.
Pin your deps and everything keeps working how you want.
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.
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.
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).
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.
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.
> My CD ripper/burner is going on twenty years old and it works flawlessly.
This is probably a good example though. The state of the art in CD ripping has advanced significantly over the last 15 years. If you care about bit-perfect rips or even just reliable error correction, it would pay to know about the advances in Exact Audio Copy (Win), XLD (Mac), or Whipper (Linux). All of these have seen releases since 2020. If you have a newer CD drive model, having an updated database in your ripping program can help you get perfect rips, as same-model drives typically have identical bit offsets. In addition, bug fixes can prevent (admittedly rare) ripping issues.
This is probably a good example though. The state of the art in CD ripping has advanced significantly over the last 15 years. If you care about bit-perfect rips or even just reliable error correction, it would pay to know about the advances in Exact Audio Copy (Win), XLD (Mac), or Whipper (Linux). All of these have seen releases since 2020. If you have a newer CD drive model, having an updated database in your ripping program can help you get perfect rips, as same-model drives typically have identical bit offsets. In addition, bug fixes can prevent (admittedly rare) ripping issues.
>ES File Explorer Pro is still by far the best Android file manager despite not being updated in three and a half years.
Is there something special about it? I'd typically recommend either Ghost Commander or Simple File Manager from f-droid to someone.
Is there something special about it? I'd typically recommend either Ghost Commander or Simple File Manager from f-droid to someone.
The way it handles separate windows and also network file shares. Even highly-acclaimed managers like Total Commander only support two windows at a time and don't really do customization. When I open ES my first window is my internal storage, swipe right for my microSD card, swipe right for my network drives, and swipe right again for another copy of my network drives. As many windows as I want, in any default configuration I want, with no screwing around with mounting or unmounting network shares. Also the built-in equivalent of SpaceSniffer is quite handy.
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.
However this doesn't mean that we must fix every bash script every 6 months because of a bash update.
That's why I stick to the POSIX shell (sh)
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
> well most of ideas wear out rather quickly and are not useful for centuries
I'm not a religious person, but already a couple thousand years ago the bible folk rightly identified that there is nothing new under the sun. Or as BNL eloquently puts it, "it's all been done before."
I don't know how we could ever quantify it or qualify it, but I would guess that most ideas stick around.
I'm not a religious person, but already a couple thousand years ago the bible folk rightly identified that there is nothing new under the sun. Or as BNL eloquently puts it, "it's all been done before."
I don't know how we could ever quantify it or qualify it, but I would guess that most ideas stick around.
Couple hundred years ago people were still thinking that Earth is in the center of the universe :)
Ideas that survived is survivorship bias - everyday life just shifts around.
Ideas that survived is survivorship bias - everyday life just shifts around.
> Couple hundred years ago people were still thinking that Earth is in the center of the universe :)
They were? Were they educated people or just some random people?
They were? Were they educated people or just some random people?
Well just read up: https://en.wikipedia.org/wiki/Nicolaus_Copernicus
Couple hundred years ago - this was up to 600 years ago - I was not saying about 100 or 200.
Couple hundred years ago - this was up to 600 years ago - I was not saying about 100 or 200.
Well 200 is "a couple"
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.
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.
I never did understood the relaxation behind pulling new code into your project from external sources.
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.
If you build your tools with somebody else's entrenched technical debt, you are now paying somebody else's debt.
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.
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!
Maybe I should just write my own framework... quick, to the name generator sites!
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.
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.
This is what I go through every time I try to run my jekyll blog locally. Just total hell.
JavaScript will always win as is most accessible to new folks.
I like JavaScript, but it's a horrible first language imo. Especially if it's being used in the browser.
[deleted]
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.
I need a scripting language with a robust library, and I’ve seem first hand how difficult NPM projects can become.
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.
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.
JavaScript feels like IE7 all over again.
We are probably at the tipping point where the JS engine should now be part of the kernel and run in ring 0.
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...
https://www.destroyallsoftware.com/talks/the-birth-and-death...
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.
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.
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....
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....
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).
> 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).
I am familiar with ring 0. Familiar enough to understand how stupid it would be to put a browser there. You don't need that many syscalls if you know what you are doing. Obviously, JS guys don't since they argue that many syscalls are needed and it's impacting performance enough that they should move it to ring 0. Jesus H Christ ...
If that kernel is linux kernel, then linux kernel should userspace app in js kernel.
npm ci is your friend.
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.
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.
Sure, but this friend is also changing. Suddenly now it verifies peer dependencies. Oops.
"yarn set version" could become your new friend?
https://yarnpkg.com/cli/set/version
https://yarnpkg.com/cli/set/version
Man. People complain that JavaScript sucks as a language and then complain when it evolves too quickly to appease these same people.
Oh well.
Oh well.
It evolves too quickly for 20 years fixing fundamental issues tgat stem from the hacky origin of the language.
Just run “npm ci” next time.
NPM bad. Insert other ecosystem good.
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.