Live data from Hacker News

The tragedy of running an old Node project

abdisalan.com

341–350 of 412 posts

Re: The tragedy of running an old Node project

#341

Earlier quoted context omitted.

one of the most crucial packages that use node-gyp are bcrypt and argon2. Both are needed heavily for password hashing while implementing authentication and while pure js alternatives are available, they run terribly

That would be a good argument to not implement authentication again and go with a solid authentication and authorisation software like Keycloak, Zitadel, or Ory Kratos.

if only integrating keycloak was simple eh?

Re: The tragedy of running an old Node project

#342

Earlier quoted context omitted.

If you used pure Node.js, you wouldn't have any problems whatsoever, too.

Unlike Node projects, your dependencies don't break - they stay on nuget.org, and the projects compile just like they did when they were first implemented. Upgrading dependencies and project target is subject to the same restrictions as in other good languages. I know for sure that I can clone a random project on Github, hit `dotnet build` and usually expect it to work on the first try. The rate of bitrot for average…

This is true for NodeJS as well - dependencies on NPM cannot be removed, so at long as NPM keeps running, and as long as you've got a lockfile that precisely specifies all dependencies, you shouldn't run into problems running older projects. (Certainly I have never had an issue with this - the problems, if they occur, are always around upgrading. And like you say, this is subject to much the same issues in every ecosystem).

If this isn't enough, there are tools like Yarn which encourage vendoring dependencies to ensure that as long as you have a copy of the repository, the yarn CLI, and a valid version of NodeJS, you can always run the project.

Re: The tragedy of running an old Node project

#343
post #75

Earlier quoted context omitted.

Sounds like you are way too used to the javascript ecosystem if you think getting an old project to build should take hours...

What ecosystem are you comparing to? Any C/C++ project with even mild complexity has a good chance of being extremely difficult to build due to either missing libraries that have to be installed manually, system incompatibilities, or compiler issues. Python has like 28 competing package managers and install options, half of which are deprecated or incompatible. I can't even run `pip install` at all anymore on Debian.…

I don't know if any API does this, but I often wished that APIs I used could mark up just a tiny, tiny subset as @FutureSafe, like the opposite of tagging deprecated code, so that for smaller projects you could stick to only or mostly those parts and know that you can come back after 2 years or 20 years and things still work. Maybe throw in a compiler flag to verify that nothing not-@FutureSafe is used by accident. Sometimes you just want to write something small, once, and not have to actively maintain it forever. Outside of shell-scripts or retro-platform code you can barely write Hello World for any target today and feel confident that it will still run six months from now.

Re: The tragedy of running an old Node project

#344

Earlier quoted context omitted.

That would be a good argument to not implement authentication again and go with a solid authentication and authorisation software like Keycloak, Zitadel, or Ory Kratos.

if only integrating keycloak was simple eh?

If you are dealing with argon2 and bcrypt, I think you coud manage some JWT hell.

Re: The tragedy of running an old Node project

#345

Earlier quoted context omitted.

Network effects are very strong for languages. Better query languages than SQL could exist, but there's so much existing code and expertise out there that it's not worth the effort. Better backend languages than Java can & do exist but don't have the same enterprise popularity. Developers, projects and companies have an immense incentives to target the most popular programming language.

JavaScript's one advantage was that it was the privileged language in the browser. It has lost that now. JavaScript has entered its Walking Dead phase. It will gradually be displaced by all languages compiling to WebAssembly.

WASM has a lot of shortcomings. You can't even update the DOM without doing a worker dance.

Re: The tragedy of running an old Node project

#346
Made a site using nanogen ( https://github.com/doug2k1/nanogen ) about 7 years ago ... Anytime I setup a new machine I do a npm install on whatever version of node I end up on, and it..... Just works.

Beat SSG I've found, and all from a medium or dev article on a SSG in 40 lines or less.

Re: The tragedy of running an old Node project

#347
post #170

Earlier quoted context omitted.

> Javascipt is a horrible language because it basically is missing a standard library so you need external dependancies even for the most basic things that are already present in other languages That's not the only reason. :) Horrible syntax full of inconsistencies, bolted on type system with TypeScript helps but will always be bolted on, quirks everywhere, as if `null` was not bad enough they also have `undefined`,…

It's okay for you to have the opinions you do, but I have zero problems programming very complex systems with Javascript, even without Typescript (before Typescript ever existed). Javascript has always been the easiest language to build anything with for me . And yes, I know a dozen other languages including C, C++, C#, Python, Go, various flavors of Assembly, and more - but Javascript is still my favorite. YMMV.

> It's okay for you to have the opinions you do

Likewise.

> I know [...] C, C++, C#, Python, Go, various flavors of Assembly

That's good. But these are all languages that either lack strong typing and or are themselves rather quirky.

Only C# and Go stand out, IMHO, as languages that are recently designed. Even Python did not have user defined classes in the first versions, and some things thus feel off (__len__, __init__, etc.).

Also C# and Go still have implicit nulls all over the place. Their designs show ignorance for modern language design. Sum-types, explicit null, immutability, sound type systems -- all lacking in all langs you mention.

So what languages do have these IMHO "Game changers"? OCaml/ReScript/ReasonML, Haskell, Elm, Rust, Gleam, F#, Scala, Kotlin, ...

Those languages really showed _me_ something important: how it could be better.

There is another group of languages that also sits on a unique place in the solution space: the LISPs (incl. Racket, Schemes and Clojure). I found it very worth while to learn to program with them as well.

Re: The tragedy of running an old Node project

#348
post #327

Earlier quoted context omitted.

Ah, but that would require that the python interpreter look first in the local directory in case there's a virtualenv there, which would mean your system could break depending on which directory you ran bits of it from. Less than ideal. It's better all round to just assume that unless you're building something to be a part of the system itself, that the system interpreters just aren't for you. There's a special case…

That's the idea, yes. Do you have by any chance any experience with Node.js? Running a JS script is usually done in two steps: 1. npm install 2. node my_script.js First one downloads and installs all dependencies listed in a package.json file into a node_modules local subdir. This is equivalent to creating a pip venv, activating the venv, and running pip install against a requirements.txt file. Second one runs the in…

I have years of painful experience with node.js, yes. The critical difference between node and python is that there are no system-provided scripts on my system which have `#!/usr/bin/node` as a first line.

There are a load of scripts with `#!/usr/bin/python` (or similar) in `/bin`, which means package resolution can't look first in a local subdir otherwise all bets are off. Again: your system will break depending on which directory you run bits of it from. The system-provided process would be loading dependencies that it was not tested against. In case this is unclear, you do not want that to happen. It would be bad. On my system I can see python scripts involved in driver management. I do not want them to do unexpected things. It would be bad.

Python package management is a mess in lots of ways, but this particular choice isn't one of them.

Re: The tragedy of running an old Node project

#349
post #327

Earlier quoted context omitted.

That's the idea, yes. Do you have by any chance any experience with Node.js? Running a JS script is usually done in two steps: 1. npm install 2. node my_script.js First one downloads and installs all dependencies listed in a package.json file into a node_modules local subdir. This is equivalent to creating a pip venv, activating the venv, and running pip install against a requirements.txt file. Second one runs the in…

I have years of painful experience with node.js, yes. The critical difference between node and python is that there are no system-provided scripts on my system which have `#!/usr/bin/node` as a first line. There are a load of scripts with `#!/usr/bin/python` (or similar) in `/bin`, which means package resolution can't look first in a local subdir otherwise all bets are off. Again: your system will break depending on…

> which means package resolution can't look first in a local subdir

Sure it can, it's just a matter of examining where it's being run from.

I wrote python-wool to load packages from a venv if it finds one.

https://github.com/fragmede/python-wool

Post reply on HN