I loathe NodeJS with the passion of a thousand suns. When Rails projects churn, at least you can rely on the stability of Ruby. With Node, the number of times I had to work around inconsistencies with the framework and even language were maddening. Babel is a horrible horrible thing, and Javascript was never meant to run on a server.

Maybe it's better now. But I won't ever do serious work again with the stack so I'll never find out.

Curiously enough JavaScript was in fact designed to run on the server too, Netscape LiveWire shipped it in 1995.

Node is getting better each year imo. I've been pretty happy with ES6.

What makes you say Babel is horrible? Not disagreeing but I haven't heard anyone say that before.

I write JavaScript daily and my gripe with Babel (and transpilers in general) in the JS ecosystem is that it makes it easy to have 10 dependencies written in 10 similar-but-different languages. If you have to edit a dependency then you're stuck editing their source file (written in ES6-ES11 plus random unaccepted proposals / TypeScript / Coffeescript / Purescript / etc), installing their devDeps tree to run their build process, integrating their sourcemaps to un-break your stack traces, and writing code in a slightly different language each time you make a change. It's exhausting.

It's really neat that we have the option to transpile, and I was actively working on transpilers in the Meteor ecosystem when they were all the rage, but at this point I try to avoid them whenever I can.

People don't say it directly, but all the constant complaining about the bloat and complexity of the JS ecosystem and the size of node_modules folder boils down mostly to two tools: Babel and Webpack.

When people make fun of leftpad they are not talking about babel and webpack.

The bloat is a lot about the lack of a standard library in JS. Or rather, too many of the damn things. That and an inconsistent and unpredictable type system.

> The bloat is a lot about the lack of a standard library in JS.

Which is why someone created core-js, which a bunch of libraries use but, in my experience, never update. Every React project will have multiple libraries complaining that core-js 2 is deprecated.

So basically even the "fix" has all those problems.

> That and an inconsistent and unpredictable type system.

Agreed and honestly, I don't think TypeScript's solution for third party types is any better, either. I recently ended up in a situation where `some-library` and `@types/some-library` got out of sync and I simply had to try versions of `@types/some-library` until it would compile again. This happened because typedef versions are not pinned to library version in any way, they are versioned just like any other library, and to the best of my knowledge you can't simply look up this information to figure out which @types release you need for a library. You can only enumerate released versions and hope the latest of each work fine. Was there a breaking change that the typedefs haven't accounted for yet? Well guess what, you can't update that library, yet, even if there were security fixes. Your code won't compile.

This means you could potentially have `some-library` at version 1.2.1 and `@types/some-library` at version 1.1.0. There's no relationship there. This happens the moment there's a revision in a library that doesn't require a revision in the typedefs.

Sorry to ramble, I'm just really unhappy with the state of our two major ES languages.

Babel was the largest package that was dependent on leftpad back in 2015 when the leftpad issue happened.

The package bloat issue doesn't happen with Typescript, for instance, which occupies a similar niche in the ecosystem (it's also a transpiler), or prettier.

But that is a sign is it not? If tools as badly designed as webpack is the standard, is that not saying there is an issue with the entire ecosystem?

There are other standard tools that don't suffer with package bloat, like Prettier and Typescript, which don't have dependencies. This issue is not inherent to the ecosystem.

I don't think it's the tools' fault. They were built to solve problems, and they solve those problems quite well IMO.

Sure, but I don't think those things are related. It's possible to solve problems without causing package bloat. Typescript and Prettier have no dependencies, for instance.

This is the primary reason why I love the .NET stack so much. Not only is a security update almost universally a non-event, but so are major framework revisions.

Updating .NET applications for security concerns in many cases boils down to letting windows update do the thing it should already be doing automatically. In a much smaller portion of cases for .NET Core, a security update is a matter of rebuilding a self-contained deployment and pushing it out to production. Neither of these cases requires editing any code or configuration.

Only in the transition from .NET Framework to .NET Core did we find any appreciable difficulty, and even then it was still within the realm of reasonable. Most of the pain here boiled down to usages of System.Drawing and DirectoryServices, both of which have alternatives that are supported on all platforms. We opted to use the compatibility pack instead, but would be OK if that was removed at some point and had to replace with the other implementations.

We have lots of sourcecode that has withstood the test of time because of these technology choices. Many files are completely unchanged since .NET Framework 4.5 was released and now running flawlessly on top of .NET Core 3.1. This is the only reason we are still in business right now.

I ended my journey with NodeJS (and AngularJS on the same day) when I attempted to update all of my packages after just a month of inactivity. Seeing the resulting pile of nonsensical dependency graph trash in my console may have radicalized me into using more "enterprisey" solutions when writing software that I might get put on pager duty for.

My experience has been the opposite. The Rails ecosystem makes updates straight forward and is very well documented. Been running various Rails apps for almost a decade now.

It's pretty good for incremental updates. It only asks a few hours a year to manage those.

Not so good when you want to upgrade a 5-year-old system. I inherited a reasonably well-built Rails app deployed with Ruby 2.2.1 and would like to update it, if only for security reasons. I can't even run that on a recent Ubuntu. On a system where I can run it, I run into dependency hell with the gems - need to upgrade some, pin lower versions of others. Possibly that could have been handled with pinned dependency versions the first time round, but that breaks the regular upgrade process.

That is indeed what I meant; I had to create debootstraps to even get it running on my laptop. And many of the gem updates broke the apis completely for no reason (move fast and don’t care?) I do not know: I remember a security update where the new version renamed most of the api methods while there was no reason to do so. I understand you can add new methods to keep backward compat; here they actually renamed functions so it was not backwards compatible and you had to change everything.

Simply put; we can cry about java or c# or php (raw php: not laravel; it has the same issues) but I can run 15 year old code on my current Ubuntu and it works fine. Maybe I need to change a few things but I do not have to rewrite a lot of it; it is more find/replace than anything. The feeling that software has to work in 50 years is important. Incremental updates are expensive and not needed for most companies, so software needs to support major version updates over decades. We know that now...

Straight-forward and documented is the minimum. Not having to think about it at all ever would be ideal. At some (huge) scale it will eventually become a thing that takes a year and a half and gets blog posts written about it, and I never enjoy losing a weekend to a microcosm of that: https://github.blog/2018-09-28-upgrading-github-from-rails-3...