Programs are dead, and JavaScript has killed them

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.

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.

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

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

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