4 ms·

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 modif

by neya 5y ago

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

midrus 5y ago
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.
- Draiken 5y ago
  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.
- lanstin 5y ago
  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.)
  - jonnycomputer 5y ago
    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.
- heavyset_go 5y ago
  > 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.
- wreath 5y ago
  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.
  - iso1210 5y ago
    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.
    - wreath 5y ago
      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.
- neya 5y ago
  > So npm gives you warnings about vulnerabilities and that's a bad thing? > Alright, good thing it told me actually, let me update.
a1371 5y ago
You're comparing Elixir & Ruby with Babel, not vanilla JavaScript. You are putting your code on non-standard JavaScript, that's on you.
- dragonwriter 5y ago
  > 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.
  - austincheney 5y ago
    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.
    - dragonwriter 5y ago
      Well, yeah, but then you’re using modern TypeScript, not modern JavaScript.
      - Oddskar 5y ago
        Modern Javascript is a subset of TypeScript though.
Rompect 5y ago
Sounds a lot like the external packages are the problem.
adevx 5y ago
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.
deleted 5y ago
[deleted]
Master_Odin 5y ago
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?
z3t4 5y ago
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.
machiaweliczny 5y ago
Actually Elixir Phoenix 1.2 to 1.3 is painful transition.

by neya 5y ago

midrus 5y ago

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.

Draiken 5y ago
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.
lanstin 5y ago
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.)
- jonnycomputer 5y ago
  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.
heavyset_go 5y ago
> 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.
wreath 5y ago
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.
- iso1210 5y ago
  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.
  - wreath 5y ago
    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.
neya 5y ago
> So npm gives you warnings about vulnerabilities and that's a bad thing? > Alright, good thing it told me actually, let me update.

a1371 5y ago

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

dragonwriter 5y ago
> 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.
- austincheney 5y ago
  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.
  - dragonwriter 5y ago
    Well, yeah, but then you’re using modern TypeScript, not modern JavaScript.
    - Oddskar 5y ago
      Modern Javascript is a subset of TypeScript though.

Rompect 5y ago

Sounds a lot like the external packages are the problem.

adevx 5y ago

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.

deleted 5y ago

[deleted]

Master_Odin 5y ago

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?

z3t4 5y ago

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.

machiaweliczny 5y ago

Actually Elixir Phoenix 1.2 to 1.3 is painful transition.