Comment by neya | Hacker News Reader

Comment by neya | Hacker News Reader

Parent Full thread

I maintain systems written in Ruby, Elixir and PHP over the years. Every server side code written by me even as old as 5 years ago, works with very little modification required for today.

But the Javascript part is the one that always causes me hours-days worth of work into Rabbit holes. And by JS, I don't necessarily refer to the language alone. It's the entire ecosystem.

Oh, `npm install`? You just found out you got like 1000+ vulnerabilities. Alright, good thing it told me actually, let me update.

BOOM! Babel doesn't support this specification in this file anymore because it's nonsensical so you have to do something else now. Ok, BOOM! Babel deprecated that now, you have to try this workaround. Oh, wait. Actually, there is no workaround. You gotta downgrade your node version.

Ok, let me downgrade. Oops, that package isn't supported anymore on this node version. Oh, you need to replace this because it's no longer maintained.

I literally never had to go though this pain with any of my Elixir backend projects.

Fuck Javascript

So npm gives you warnings about vulnerabilities and that's a bad thing?

You notice you have thousands of outdated dependencies and that's a bad thing?

I used to work a lot with python years ago, and the only reasons we didn't have this problems was because the packages management was so terrible that you didn't even notice you had to update dependencies or that they had vulnerabilities.

Diff being you usually have like five python deeps for every hundred npm deps a d you can do the old school thing and subscribe to the security alerts for those deps. The difference in number of deps means you have the cognitive space to understand them. Npm needed to automate because the numbers are too high. One of python’s old selling points was “Batteries included”. And the idea is fewer large library rather than a bunch of tiny libraries.

With a small number of deps where you skim the development DL, you know if there is a security issue or a cool new feature you want. Also it has more of the Unix C philosophy of don’t break stable APIs in new releases. So upgrading mostly just worked. (Stuff like deliberately breaking old SSL protocols aside). (Until python 3 of course.)

I got to pains to limit how many python external libraries I use, for all these reasons. But because Python is so capable on its own, it works.

Most languages I've used don't *need* to have 1000 dependencies like JS does.

They also don't have thousands of projects depending on ridiculous packages like left pad because they actually have a standard library.

The surface of vulnerabilities and the brittleness of the entire ecosystem is the bad thing, not the warnings.

> So npm gives you warnings about vulnerabilities and that's a bad thing?

> You notice you have thousands of outdated dependencies and that's a bad thing?

This is a weird reply considering that the OP literally said those were a good thing:

> Oh, `npm install`? You just found out you got like 1000+ vulnerabilities. Alright, good thing it told me actually, let me update.

The bad things are in the lines that follow.

Not OP but what I think they struggled with is fixing warnings. JS projects are like a poorly built house, things are constantly deteriorating and need constant maintenance.

I've got a new nodejs project that a colleague wrote about 6 months ago. It's already completely broken and needed a lot of effort to get working again.

On the other hand his php project from 2011 still works, just as my perl stuff from 2006 still just works.

This doesn't sound foreign to me. Node projects rely on a lot of dependencies (and so does their dependencies) so there is a lot of moving parts and it's prone to break.

> So npm gives you warnings about vulnerabilities and that's a bad thing?

> Alright, good thing it told me actually, let me update.

You're comparing Elixir & Ruby with Babel, not vanilla JavaScript. You are putting your code on non-standard JavaScript, that's on you.

> You're comparing Elixir & Ruby with Babel, not vanilla JavaScript. You are putting your code on non-standard JavaScript, that's on you.

Babel is the only way to use modern standard JS without excluding older browsers.

I completely disagree. The TypeScript compiler allows you to specify a compile target against a version of JavaScript. That means you can write modern TypeScript and have it compile to ES3.

Well, yeah, but then you’re using modern TypeScript, not modern JavaScript.

Modern Javascript is a subset of TypeScript though.

JavaScript is backwards compatible. What you wrote in JavaScript 10 years ago will still work today in all JavaScript engines.

Because you mentioned Babel I suspect you actually didn't use JavaScript - but a language that compiled to JavaScript. And this complicate things a lot and is probably the root cause of your wasted hours. The time you save upfront by using some framework you pay back later in maintenance once new versions are released and things get deprecated. In JavaScript itself nothing will ever get deprecated.

1: Trying to fix every vulnerability in any nested dependency is probably not what you want to do. In my experience only a tiny fraction has an attack surface and most are duplicates. 2: Webpack is a monster and updating webpack will always result in a lot of work. If possible use a well supported framework that incorporates Webpack, like Next.js or Nuxt.js. Updating will be a breeze. 3: Don't wait years before scanning for issues, update on a set schedule so it won't become a huge task once a critical issue is found.

Do elixir libraries just never deprecate stuff? Or just that their package managers never alert you about vulnerabilities so you can pretend like they don't exist and so never upgrade?

Actually Elixir Phoenix 1.2 to 1.3 is painful transition.

Sounds a lot like the external packages are the problem.

Reply on news.ycombinator.com