Programs are dead, and JavaScript has killed them

by poeti8 • 4 years ago

125 211 4 years ago

iamsaitam• 4 years ago

npm ci is your friend.

flohofwoe2• 4 years ago

It's partly a solution, but doesn't help when the 'enviroment' (OS, Node, compiler toolchains used in dependencies) has moved on and is no longer compatible with the old version-pinned npm packages, the same problem also exists in other programming ecosystems (just maybe not as extremely - but I have the same bad experience each time I want to write a blog post, because Jekyll usually breaks after a macOS update).

It's not Javascript or Node.js or NPM which is the problem though, but the 'culture' of offloading every little detail into its own dependency, nothing in the Javascript ecosystem technically requires this approach.

fuzzy2• 4 years ago

Sure, but this friend is also changing. Suddenly now it verifies peer dependencies. Oops.

janpot• 4 years ago

"yarn set version" could become your new friend?

https://yarnpkg.com/cli/set/version

mouzogu• 4 years ago

During the past 5–6 years of my JavaScript experience, every time I wanted to go back to any of my projects—from tiny to big, server-side or front-end—there was always a challenge, a problem to tackle or an obstacle to overcome before I can update or sometimes even just run my program.

why i moved mostly from writing node cmd tools to using bash. don't need to go on a bunch of side missions every time i run npm install

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

Gibbon1• 4 years ago

A month ago I found a bug in command line utility I wrote in C# and hadn't touched in 8 years. I checked out the project and opened it in Visual Studio. And it compiled. I fixed the bug and it just worked. End to end it took half an hour. I feel like there is an advantage to libraries and tools managed by adults with long term skin in the game.

hutzlibu4• 4 years ago

As a counter point: I have simple node scripts, that serve the same purpose to me. And there was also the need to fix something 2 days ago in an 8 year old script. Opened the file, changed the code and running it again. Took 5 minutes and it just worked.

I don't use js because it is the hot new thing, but rather because it is simple. (But I avoid messy and obscure npm repositories wherever possible for example.)

nazgulsenpai• 4 years ago

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.

Al-Khwarizmi• 4 years ago

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.

skitter• 4 years ago

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.

smrtinsert• 4 years ago

Same thing with java. Literally pick up where you left off. The issue of not working after some time just isn't an issue.

ianai• 4 years ago

Web has always been about the hot new thing. It was part of why I left-in 2001.

pjmlp4• 4 years ago

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.

bluocms• 4 years ago

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.

bambax• 4 years ago

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.

hpeinar• 4 years ago

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...

hulitu• 4 years ago

To avoid a rm -rf / ?

_ZeD_• 4 years ago

because js should never be the first choice in any case...

slowmovintarget• 4 years ago

My scripts in ksh from 25 years ago still work.

wellanyway3• 4 years ago

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.

andsens• 4 years ago

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.

cduzz4• 4 years ago

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}"

csmpltn• 4 years ago

"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).

cduzz4• 4 years ago

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.

yakubin2• 4 years ago

Bash scripts don’t break, when left unattended for months/years. Python scripts do.

freilanzer• 4 years ago

*Statically typed, not strongly typed

nikanj• 4 years ago

The python build/install/distribute situation is so bad, XKCD made fun of it years ago https://xkcd.com/1987/

ludovicianul• 4 years ago

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.

cxr10• 4 years ago

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.

robinsonb5• 4 years ago

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.

rjzzleep• 4 years ago

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.

yieldcrv• 4 years ago

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

cxr10• 4 years ago

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.

GrabbinD33ze69• 4 years ago

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.

he_is_legend• 4 years ago

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

jasfi• 4 years ago

Nim is great for this use case.

mckravchyk• 4 years ago

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...

FractalHQ• 4 years ago

Why has nobody mentioned that you can (and should) just lock your dependency versions…?

omarfarooq• 4 years ago

Because that stop short that complain train.

Tade02• 4 years ago

I experienced the same issues and to me the main culprit appears to be the dumpster fire that is the ongoing transition to ES2015 modules.

Also Node v18, while full of new, important features(like the built-in test runner) feels... kinda unstable? I had to downgrade to v16 because I had segfaults. Also had to make it use jemalloc due to memory leak issues when it used the default allocator.

I went into this platform specifically not to deal with such problems.

qazxcvbnm• 4 years ago

Just want to add that node unfortunately gives me segfaults in unexpected places too, often (seemingly randomly) during the first second of execution when I'm trying to debug it by running node under --inspect-brk...

Tade02• 4 years ago

Something is indeed off here. Even Node 0.x didn't have so many problems (granted, the debugger back then, ahem, left one wanting).

yazaddaruvala3• 4 years ago

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

m00dy• 4 years ago

If that kernel is linux kernel, then linux kernel should userspace app in js kernel.

hnbad2• 4 years ago

I see you haven't watched this talk about the history of JavaScript between 1995 and 2035 since that's exactly what happened in this future:

https://www.destroyallsoftware.com/talks/the-birth-and-death...

yazaddaruvala3• 4 years ago

I have! It's a very good talk. I wouldn't make any design or technology decisions based on it tho.

What is clear today is that Javascript is on every computer in the world (including phones). It is now even taking over for native desktop apps and native mobile apps. At this point, including a JS engine into all the kernels for apps and browsers to use just seems prudent.

martyalain• 4 years ago

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

papito• 4 years ago

In the early 2010s, the industry was dominated by mature and stable ecosystems, such as Python/Django and Rails. Then Node came about, and when it was still extremely immature, it got a ton of attention as an army of front-end devs started to flock to it. "We are backend engineers now too!".

Doesn't work that way. Node has been basically re-learning all the lessons learned a long time ago, and many lessons it didn't learn at all. The fact that the FAANG alumni then joined the orgy and reminded us that we are all lame because we really need to be doing distributed systems for everything (for the young ones - microservices), did not make things simpler.

Leave a JS project unattended for a few weeks and I go back to it with a sense of dread. What horrors await me?

In contrast, I dusted off an old Flask project from 8 years ago, upgraded the dependency manager, the major Python version, 2-3 hours and off I go.

eternalban• 4 years ago

This was a relatively mild but necessary rant.

re-learning all the lessons learned a long time ago

Because this is the same crew that sailed on the ship that sang the "over 30 is over the hills" song. In fact, wasn't our own /u/pg cheering this 'very wrong idea' of completely discounting experience on the side?

Surprise, surprise. Experience actually matters.

hnbad2• 4 years ago

But hiring college graduates is so much cheaper and they are so much easier to dazzle and don't have any outrageous demands like being able to spend time with their family. Why hire for quality when you can make it up with quantity?

flohofwoe2• 4 years ago

by mature and stable ecosystems, such as Python...

Nothing I experienced in the JS ecosystem so far was as nearly as painful as the over a decade-long transition from python2 to python3, and now python3 has the same 'move fast and break things' mindset. It's kinda infuriating for use cases where python2 was more than good enough.

norman784• 4 years ago

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

jen20• 4 years ago

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.

thorncorona2• 4 years ago

The only reliable solution to this that I have found is compiling an app into a docker container and ensuring my projects are able to run off a SQLite database.

I then save this to my NAS.

Otherwise literally everything will break.

Running an app that I wrote only 3 years ago will blow up.

ElKrist• 4 years ago

I don't understand: if you have fixed dependencies and the same Nodejs version, how can things break?

I'm not saying it's a good thing to not update your packages but you seem to imply there's another force messing with your project?

thorncorona2• 4 years ago

In general it's a hassle when your processor arch, OS version, and node version starts to come into play. NPM doesn't handle this in a great way, especially with native dependencies that need to build, and rely on OS apis. NodeJS isn't particularly stable either.

For example, I used to dev apps on windows, and run them on Ubuntu 16. That worked alright but required minor changes. Moving to Ubuntu 20 on my server required a couple tweaks, and then later moving to deving on Mac required more changes.

Of course keeping old copied of databases is a different story but SQLite is just so convenient compared to backing up full fledged SQL dbs.

These were for old finished projects I wanted to briefly spin up.

newbieuser• 4 years ago

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

andrewstuart• 4 years ago

> JavaScript is evolving too rapidly.

No it's not.

There's lots of dependencies and they continue to be developed.

It's not too much and its not rapid. It's just constant.

bombolo8• 4 years ago

rapid is ok… constantly breaking backwards compatibility is the issue.

vineyardmike2• 4 years ago

My experience is pretty similar for my projects but I think generally we shouldn’t point too many fingers. When it comes to public projects, I’ve found a lot of trouble regardless of its JavaScript-proximity. I think we’ve been blessed by a growing ecosystem of projects that are clean to build, and eschew problematic dependencies. Try building anything Linux and C related and you’re worse than JS because now you need to modify libraries across your operating system not just NPM project.

Tonight, I tried simply compiling an example super-high-profile project that recently reached 1.0 (Matter protocol impl). It took me an hour of chasing down Linux dependencies to build on my Ubuntu server, while I gave up on building on my mac altogether after comments on issues suggested sym-linking various homebrew packages around my system.

We are still new at experiencing docker-packaged projects, and there’s few heavily used tools that work well. Many big companies have solved this problem internally, but not out in the wild. HN has often discussed GUIX or NIX systems, but I’ve yet to see a “real” open source project that uses anything but make/docker or language specific tools (npm, cargo, etc).

bombolo8• 4 years ago

I gave up on building on my mac altogether

osx is not linux. It has a gazillion of incompatibilities and most developers never test for it, so even if the code compiles, it's no guarantee it will work.

Try building anything Linux and C related

"apt install libwhatever-dev" does it in most cases.

docker-packaged projects

You mean completely insecure projects that most likely run an old and vulnerable openssl?

vineyardmike2• 4 years ago

Yea macOS is never a guarantee but I’m always hopeful when they include Mac instructions in the readme.

I’ve found projects that use C++ or other older languages and meant for Linux still have a nightmare with building. The project I looked at had a bootstrap script, an initialization script, a pip installation, and 3+ different make-alternatives. Not uncommon even when apt works.

Docker is great but it’s only as secure as Linux can be. Yea it can have outdated SSL, but it’s just as likely that the thing you need depends on a particular version. Most projects don’t get versions updated unless it’s broke. IMO if something is a web service or generally at risk, you should not depend on the good-faith security being vended. Put it bend a secure network or proxy, Audit, etc. As the advice goes, don’t run your server on port 80 as sudo, but instead run behind NGINX.(modify for risk)

AgentME2• 4 years ago

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.

BackBlast• 4 years ago

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.

bombolo8• 4 years ago

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

jFriedensreich• 4 years ago

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

ozim3• 4 years ago

I have a bit different view.

If some app is not updating - there is not much use for it.

Just like houses - yeah you can have 100 years old house but if you did not invest in it and expect to be just as good as new you are in world of pain.

Same with cars - 10 years and you really have to change quite some parts.

Applications are ideas - we expect that ideas don't "wear out" - well most of ideas wear out rather quickly and are not useful for centuries.

My javascript app is not Plato "cave allegory" - but that is fine and also what makes javascript app valuable, I can throw it away and rebuild from scratch even better with low effort. Data storage or formats should be usable for at least 5-8 years. There are things that should be preserved for longer - but these are exceptions. Most stuff after 2 years is not that useful anymore.

bombolo8• 4 years ago

Updating is fine… bash for example keeps having new versions and new features.

However this doesn't mean that we must fix every bash script every 6 months because of a bash update.

augustk• 4 years ago

That's why I stick to the POSIX shell (sh)

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

amoe_• 4 years ago

You have low expectations; I have Racket programs that have worked for over 10 years essentially untouched. More or less the same with Perl. We should be aspiring to Plato's cave (while accepting that we won't reach that).

causi3• 4 years ago

If some app is not updating - there is not much use for it.

That depends entirely on the program. My CD ripper/burner is going on twenty years old and it works flawlessly. Same with my audio recorder and the sensor viewer for my phone. On the occasion I need to make a slideshow or write a document, Office 2007 works just fine with no bullshit, granted I don't view third-party files in it. ES File Explorer Pro is still by far the best Android file manager despite not being updated in three and a half years. I wouldn't be particularly upset if I had to use a version of VLC that was ten years out of date.

bscphil2• 4 years ago

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.

opan• 4 years ago

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.

checkyoursudo• 4 years ago

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.

ozim3• 4 years ago

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.

ramesh31• 4 years ago

NPM bad. Insert other ecosystem good.

sourcecodeplz• 4 years ago

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

royletron4• 4 years ago

Meh, I feel a little like this is dunking on Javascript for the sake of dunking on Javascript. Ever done the same with a PHP app? Go? Python?! They all have issues with versioning and this is why there are a good set of tools to deal with it - pyenv/nvm etc. It's like they've listed all the good reasons to use JS and then kicked it because it's cool to hate on JS.

Hi, I am Darren, and I love JS - I will no longer be ashamed by it.

bombolo8• 4 years ago

most python modules do not have so many dependencies, and tend to have a stable api.

Bugs happen but it's by no means a constant thing.

lordgroff2• 4 years ago

Python has a completely different issue and that is that its dependencies on c extensions makes cross platform or cross version packaging a terrible thing.

This is why I get a bit puzzled when people complain about the Java build system. It's so much saner in comparison to the scripting languages, and arguably better than Go or Rust (though I'll take any of the three over Python or JS).

trarmp• 4 years ago

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.

lordgroff2• 4 years ago

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.

mardifoufs• 4 years ago

Python is worse. By far in my opinion.

usrbinbash3• 4 years ago

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.

royletron4• 4 years ago

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.

krapp• 4 years ago

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.

parasubvert3• 4 years ago

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).

cxr10• 4 years ago

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.

throwaway290• 4 years ago

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.)

Gys• 4 years ago

I love JS

That is the problem. You love a hammer and see nails everywhere.

royletron4• 4 years ago

Well that's a judgement call I'm afraid you have wrong. JS is a great solution to some problems, as is Go, as is Rust, Ruby etc etc. I love JS for what it's good at - things like making web apps a reality, allowing a single language to be a start point for devs etc. I certainly don't use it exclusively.

candu• 4 years ago

To be fair: the reference to `node-gyp` gets at a general problem with most high-level languages. I've seen very similar issues in Python - once you start to deal with native bindings, your nice high-level language abstractions become leaky, and you can no longer guarantee that building on new hardware won't fail in mysterious ways. (This is, incidentally, one of the benefits of VMs / containers / anything designed to remove or mitigate the "new hardware" part of that risk.)

If you look deep enough, or do anything low-level enough, or need to work with high-performance native libraries enough, you will find these leaky abstractions in every high-level language. Maybe it's at the "I want to do awesome Cormack-style invsqrt() pointer punning hacks" level, maybe it's at the "eep I'm dealing with raw binary data over a network and now the order of bits matters" level, maybe it's at the "argh I'm using a package that has native architecture-specific implementations" level.

dusted2• 4 years ago

This is an article about ecosystems and package managers, not particularly about JavsScript, which is a scripting language around which one can chose to participate in ecosystems and use package managers. The distinction is not as subtle as one would think.

It's the same with any program.. dependencies are future liabilities. You pay for fast development now with a future burden of upgrading and incompatibility.

That's why I enjoy coming back to the software I've written with that mindset, it does not matter which language.. If I was in the supposedly wrong NIH mode when I wrote it, it still builds..

xnorswap4• 4 years ago

But there's something very different in the JS ecosystem that makes things worse.

In the .net world, even with packages managed with Nuget, it doesn't have the same "constantly breaking" problem.

For example being "stuck" on an old version of react, because dependency X version 6.x requires react < 17, but dependency X version 7 completely re-wrote their entire API and has so many breaking changes it's not reasonable to upgrade.

So you're faced with either being stuck on an old react, or re-writing half your application around the new version of your dependency.

In the .net world, things don't move so fast, don't break so much and it's rare that both your dependencies and frameworks all break all at the same time leaving you stranded.

The .net 5 transition was the closest thing, but the .net standard pathway mitigated the worst of that, and crucially, .net framework is still well supported.

Also in the JS ecosystem, it's not just your application packages but your whole build toolchain that quickly gets out of date and breaks. For example finding that you can't move to the latest version of something because it breaks something else in a "random" location.

For example finding out that you when you upgrade node, suddenly node-gyp doesn't work, and this package you likely haven't previously heard of is crucial and central to your build.

There's no way around this problem but to dedicate hours every month to keep everything on the bleeding edge. There's no such thing as "LTS" in javascript. Node in theory has an LTS release but it's useless as soon as libraries start requiring non-LTS releases.

Bringing in libraries shouldn't mean burdening yourself with so much future incompatibility and constant upgrade grinds that it's a significant part of every month, it they shouldn't force you to live on the bleeding edge.

cxr10• 4 years ago

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.

rektide• 4 years ago

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.

dusted2• 4 years ago

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.

amadeuspagel2• 4 years ago

Even if you write something yourself, it might not work on a future version of your OS.

constantcrying• 4 years ago

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.

zelphirkalt9• 4 years ago

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.

Dah00n• 4 years ago

JavaScript feels like IE7 all over again.

enjikaka• 4 years ago

Tools like Babel emerged to bridge a compatibility gap between the evolving ECMAScript specification and the browser lacking behind implementing the new features. Then some "smart" people decided Babel would be a good thing to transform anything and thus React, JSX and the like were born. The problem emerged and took foot when we stopped polyfilling and transpiling the compability gap and instead built further on the powers of these tools and coupled us too tightly with them.

People need to learn to build on and use the platform. Do NOT learn React, Node.js or Tailwind. Learn HTML, JS and CSS. Use these in your projects and they will work forever.

The standards are backwards compatible and evergreen. Your walled garden withers.

mirthflat83• 4 years ago

Learning React, Node.js, and Tailwind doesn’t mean that you’re not learning HTML, JS, or CSS…

lloydatkinson3• 4 years ago

I was going to say the same but I think you said it much more clearly than I would have. I see this meme a lot. "I hate X, don't learn X, Y is better because Y is fundamental to Z".

I have not once seen these same people suggesting "Don't learn the toolkit/framework/control library for your OS, instead use raw WinAPI or X System calls and push raw pixels to build applications".

Yet, they push for the same with HTML. How you arrive at the HTML is up to you. By saying, for example, don't learn React, you might as well be saying "don't do anything productively, do everything in the least maintainable and the most convoluted and unnecessary way possible, your customers and team will like that surely".

zelphirkalt9• 4 years ago

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)

lloydatkinson3• 4 years ago

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.

schwartzworld• 4 years ago

Do NOT learn React, Node.js or Tailwind. Learn HTML, JS and CSS.

How exactly should I use html and css to replace nodejs?

zelphirkalt9• 4 years ago

You don't do server side code in JS and then you don't have a need for Node.js. Easy.

dmitriid4• 4 years ago

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

LtWorf3• 4 years ago

Most of the modern web will be broken on older devices.

And the super heavy js websites will work?

parasubvert3• 4 years ago

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.

zelphirkalt9• 4 years ago

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.

gedy2• 4 years ago

This attitude usually results in a company inventing some bespoke abstraction/framework whilst saying they are following standards.

brushfoot2• 4 years ago

There's no free lunch. JavaScript has the largest package ecosystem in the world. It's great for finding "free" UI components or server libraries for projects, but you pay for it in maintenance costs.

That said, I don't think it's as bad as this article makes it out to be. There's this kind of maintenance in a traditional server-rendered Django/Rails app, too, on both ends. You can self-host your JS scripts or fetch them from a CDN instead of using Node, but they're still deps. You still have to worry about upgrading and vulnerability scanning. It's just invisible now. The onus is on you.

iso1631• 4 years ago

I've got perl web apps that haven't been touched for 15 years (aside from a single change from a flash <object> to <video> in the template) that still perform their function perfectly well

brushfoot2• 4 years ago

Sure - if you don't need rich UI interactivity, you can get by with a lot less. Plenty of sites don't and should.

What I like about Node, though, is frameworks like Next.js that are the best of both worlds. You can do traditional server-side rendering using React components, so you can easily add as much/as little client-side JS as you need.

With Next you use the same package manager for the front end and back end. And you get code sharing and access to that huge ecosystem of libraries.

But needs and skillsets change the equation, definitely.

AshleysBrain• 4 years ago

I think the overlooked lesson is: the more technology you add in to your stack, the harder it is to maintain. Shallow tech stacks - using fewer tools and frameworks wherever possible - are usually a good idea to minimise your maintenance headaches.

If you're making a small quick tool, vanilla JavaScript is not a bad choice. You don't have to use npm, TypeScript, and a bunch of frameworks. If you do anyway then sure, you can end up in a situation where 90% of your work is maintenance, but you made that tradeoff - these should be things you consciously weigh up and decide, not just do automatically.

lionel_ZA• 4 years ago

I agree with this view. Any large, complicated project with a large number of dependencies is going to require maintenance over time, regardless of the language or package ecosystem. Keep your simple projects simple, and if you need to use dependencies to get something off the ground quickly, either be prepared to maintain it or to do some additional work to remove the need for those dependencies over time.

namaria• 4 years ago

Fred Brooks has been warning us that the key problem with software development is 'how to keep complexity at bay'. Half a century later we're still wondering why sloppy complexity management bites us in the ass later on.

Doxin• 4 years ago

There's still a difference between javascript and other languages with respect to dependencies. E.g. if I open a 5yr old python project there's a fair chance all the dependencies still exist and still work with a more recent python interpreter, let alone work at all.

My --limited, to be fair-- experience with npm is that you can barely look away from a project for a week or it'll have a bunch of deeply broken dependencies, requiring you to update them which then breaks other dependencies in turn.

too_much_churn• 4 years ago

Too much churn is killing me.

JavaScript is really just the tip of the iceberg or maybe the perfect embodiment of modernity.

Looking at it narcissisticly, it's like some kind of divine punishment for younger me who couldn't wait for progress and innovation on basically everything.

amadeuspagel2• 4 years ago

"your new operating system"?

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

maverickmax90• 4 years ago

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

kypro• 4 years ago

I like JavaScript, but it's a horrible first language imo. Especially if it's being used in the browser.

DiabloD3• 4 years ago

I don't understand the point of this article. Most Javascript "programs" (lets not glorify them) are being stripped out of prod everywhere that isn't a NodeJS shop internally (and those are being garbage collected left and right by the Covid recession).

If you build your tools with somebody else's entrenched technical debt, you are now paying somebody else's debt.

CapsAdmin• 4 years ago

some ways to combat this:

- do you really need to upgrade?

- try to reduce dependencies

- freeze packages to specific versions

- are you sure you need to upgrade?

- if you depend on a simple package that you can't be bothered to write yourself, consider moving it into your project

- try to get more control over how your project is built

- try not to use dependencies that have implicit dependencies on other languages (msgpack written in c++ for example)

- try to choose packages written in typescript first if you're using typescript

- make sure you have a good reason to upgrade

_ubs3• 4 years ago

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

yurishimo• 4 years ago

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

dncornholio• 4 years ago

The solution is very simple. Lock your versions in package.json. Everyone stays happy. The only thing to keep track is, is what version of NodeJS you are using. It will happily keep working for years!

Do I get a super long list of deprecated and warning messages? Yes, they are also meaningless. You can ignore them and just build the feature.

beardedetim• 4 years ago

This is exactly my feelings throughout this thread. We have apps in prod that haven't been touched in years that don't break and handle average to high req/s. We add a line here or there as we need to for bug fixes but we don't have any dep problems randomly breaking the app.

Pin your deps and everything keeps working how you want.

nobodyandproud• 4 years ago

Is python and pip more stable in this regard?

I need a scripting language with a robust library, and I’ve seem first hand how difficult NPM projects can become.

bombolo8• 4 years ago

pypi is full of awful amateur libraries that don't work very well.

Finding a good one among 20 crappy clones is a chore, and the most downloaded ones are not necessarily the best options.

I personally just stick with whatever is on my distribution (debian) and very very seldom venture out to using something directly from pypi.

In any case python doesn't require many libraries, so most of my projects require no more than 2 or 3 dependencies. Where js projects require 50, so the risk of issues from a dependency changing API is not as big.

d_runs_far• 4 years ago

As I am preparing to update a 10 year old project done in backbone/coffeescript this whole thread hits hard. Likewise a react prototype done in 2018 that is all class based that is going to be next to revive.

Maybe I should just write my own framework... quick, to the name generator sites!

codyswann• 4 years ago

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

Oh well.

wellanyway3• 4 years ago

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

eezing• 4 years ago

Just run “npm ci” next time.

nasmorn• 4 years ago

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

musicale• 4 years ago

Build on quicksand, sink into quicksand.

I may complain about Swift/iOS/macOS breaking things every year but they seem like bedrock compared to many JavaScript environments and frameworks. Come to think of it, even many Java apps seem to be built on a quicksand morass of constantly changing frameworks.

But I think you can have fairly stable JavaScript if you write primarily vanilla JS and don't rely on the latest bleeding-edge features in Chrome, etc..

wellanyway3• 4 years ago

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

boxed• 4 years ago

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

Programs are dead, and JavaScript has killed them

Related Stories