hackernews client

The tragedy of running an old Node project

But software (in my experience) always lives longer than you expect it to, so you need to be sure that your dependencies will be maintained for that lifetime (or have enough time to do the maintenance or plug in the replacements yourself).

otabdeveloper4

6 hours ago

Yes indeed, that is the solution to modern IT problems - never update your Ubuntu 18 containers and you're set.

(Wish I was joking, but sadly I'm serious.)

ohthatsnotright

4 days ago

If you're looking for a stable target you should not even consider Next.

jmathai

2 days ago

Just avoid JavaScript frameworks altogether.

user

4 days ago

[deleted]

jeberle

4 days ago

Not sure if I'd call out Jekyll as a paragon of stability. The last time I touched it, I made sure to write up detailed notes. In fairness, it's the only time I interact w/ Ruby.

https://jeberle.github.io/jekyll-setup

arp242

4 days ago

Those mostly seem the standard Ruby/Jekyll/GitHub Pages setup instructions?

I think the experience of code rot is universal and increases with the amount of dependencies you have.

mperham

4 days ago

> I think the experience of code rot is universal and increases with the amount of dependencies you have.

This is true but there's also a factor from the language/framework in use. Node is especially bad because of it generates huge package dependency trees. Go is especially good because of the large stdlib (which I use to minimize deps in https://github.com/contribsys/faktory) and excellent backwards compatibility.

3 days ago

What does Java or Python have in their stdlib that go doesn’t?

3 days ago

> Spring generates bytecode, and Lombok is a language extension. You're effectively writing code in another language that's very similar to Java.

That's the reality of using the language in production projects.

Same as how you're likely to see more than just Python or Node being used in projects that list them in the tech stack, because there's native dependencies and tooling used.

signal11

a day ago

Old Spring versions < 6.1 are obsolete, so you do have to upgrade Spring in many scenarios as well. No security fixes for them unless you pay for support.

andai

4 days ago

I spent an hour or two figuring out how to even download Java, whether I need to give Oracle my home address, use a third party JDK etc. Then it turned out the standard built in GUI library I needed was no longer standard or built in. (I also used it ten years ago and it was a much better experience then.)

trinix912

3 days ago

JavaFX? I’ve been there too, had to install it with maven and waste a few hours getting the maven xml just right for it to bundle the entire thing into a runnable jar (one that doesn’t require shipping extra files). Not the most convenient, but I get that they wanted to split it off the JDK release cycle.

sorokod

3 days ago

To save you time in the future:

https://adoptium.net/en-GB/

Haven't used javaFX for a while but this is worth a shot

https://openjfx.io

Suppafly

3 days ago

>I spent an hour or two figuring out how to even download Java, whether I need to give Oracle my home address, use a third party JDK etc.

My son found a disk with some of my old java project from college 20 years ago and that's about what it took to run them, first figuring out how to even download java and then making some minor changes to get them running. I think we gave up trying to get the actual applet based ones to run.

fian

15 hours ago

I know this is a late response, but for anyone curious you would need to use an official Oracle or Sun JDK/JRE from Java 8 or older. OpenJDK doesn't include support for applets.

4 days ago

Right, I'm just clarifying for others who may not know the difference that Node doesn't have a monopoly on instability.

There are a very small number of projects that specifically make it their goal to be backwards-compatible effectively indefinitely, and Maven is one of those. It's part of what people who hate it hate about it, but for others it's the main selling point.

lowboy

4 days ago

Well, the article is about npm, a package manager for node. Vendoring dependencies into source is a choice, albeit one that I don't often reach for.

cesarb

4 days ago

> Well, the article is about npm, a package manager for node.

And Maven is a package manager for Java. The main difference IMO? The usual way to do things in Maven is to always use exact versions for the dependencies. When I specify I want some dependency at version 1.2.3, Maven will use version 1.2.3 of that dependency even if 1.2.4 or later already exists.

lowboy

3 days ago

Pinning to exact versions has been supported in npm for most, if not all of its life.

That’s the usual way to do things in most teams working on app code I’ve been a part of (as opposed to library code where version ranges are preferable).

ivan_gammel

4 days ago

Maven is also stable and requires only JDK to run. You can unzip it to desired location and add to PATH - it will be ready to go in a couple of minutes.

It will not build all old projects out of the box, of course. Specific versions of plugins may not be compatible with it or some dependencies may break on modern JDK. But chances of hitting this issue are much lower than in JS/NPM ecosystem.

trinix912

3 days ago

Might be an unpopular opinion but I like it that way. It means that I can pull an old Gradle version and the build should succeed. Unlike maven where I’ve been bitten by plugin xml syntax changes and such.

jvanderbot

3 days ago

3 days ago

Yeah, that's nice, unfortunately it's the built-in Microsoft stuff like WPF that keeps breaking between versions.

a1o

3 days ago

Note Microsoft still removes downloads of previous versions of Visual Studio that aren't the latest - now you can only download VS2022 unless you have some mysterious paid account that has access to those - I don't have in either my personal or my corporate so I don't know the details

trinix912

3 days ago

This is true and is a pain if you’re stuck on something like Windows 7/8.1 (or 10 in the future). The installer being a web installer that auto-updates on start also means that downloading an older one doesn’t help at all. The only way seems to be to pirate the Enterprise offline installer which of course isn’t really an option.

timrobinson33

4 days ago

As it happens I've recently upgraded a 2 year old project with both node and C#

It was open much the same in both. If you're happy using outdated and unsupported components with security issues AND you can get hold of the right version of the dev tools and plugins AND your hiding environment still supports the old platform, you can maintain the old version with minimal change. But should any professional developer do this?

HeyLaughingBoy

2 days ago

It depends.

In domains where software is expected to run for years, if not decades, it's common to archive the entire toolset, along with libraries and SDK's in case you need to fix a bug/add a feature 10 years later. Obviously, in this case you can't have dependencies sitting somewhere on a server you don't control.

There are also situations where this is forced by regulation: you need to recreate build xxx.yyy.zzz 7 years after release because a customer reported a serious bug and it needs to be reported to the relevant regulatory agency and investigated.

david_allison

4 days ago

Not any more. Security vulnerabilities in dependencies now break the build by default.

It's arguable whether this is the correct decision, but it makes things slightly harder than they used to be

toyg

4 days ago

> C# devs can open decade+ old solutions without issues

For some definition of "without issues"...

nisegami

4 days ago

I wish I lived in the world you described but trying to onboard a new dev onto an existing (edit: ancient) C# project at my job is frequently a multi-day endeavor.

JansjoFromIkea

4 days ago

I think there's much bigger deviations from long term stability the closer you get to a GUI as things deviate further from ideals into brute force hacks for stuff to look right.

Can remember trying to update a Unity project so it'd be still buildable for 64-bit Mac devices. The very first version bump I done resulted in several critical libraries no longer working and there being no clear alternatives to swap in.

horsawlarway

3 days ago

As someone who has migrated old ASP/silverlight projects and BHOs... seriously, this is complete bullshit.

This depends highly on what dependencies are in your C# solution.

Same for his node project. If he'd stuck with dependencies that are just plain js - I'd bet money his project would have installed & built just fine.

By the time you're hitting the native addon apis and doing things like compiling python and C/C++ code... you're going to feel all the pains of those ecosystems too.

thrw42A8N

4 days ago

Lol, I left C# because I couldn't solve this issue and in Node.js it's particularly easy - just keep a nvmrc file and a dependency lockfile.

demosthanos

4 days ago

It's also two hours that would have been completely avoided if the author were familiar enough with Node to know to pin the version and not try to install 4 years of updates in one shot.

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.

Even Rust, which is usually great and has modern packaging and built-in dependency management, often has issues building old projects due to breaking changes to the compiler.

All this is to try to say that I don't think this is some problem unique to JS at all - but rather a side effect of complex interconnected systems that change often.

A big reason Docker and containers in general became so popular was because it makes this problem a lot less difficult by bundling much of the environment into the container, and Docker is very much agnostic to the language and ecosystem running inside it.

treflop

4 days ago

Java has a great ecosystem. It’s well thought out and I can compile and run 10 year old projects no problem. In fact, I wish everyone had just copied Java’s model instead of inventing their own worse model.

I love Python but it has a terrible package ecosystem with mediocre tooling that has only gotten worse with time.

JavaScript has gotten better but it seems they are just re-learning things that were long figured out.

When I see new package managers, I just see a list of problems that they forgot to account for. Which I find strange when there have been many package managers that you can learn from. Why are you re-inventing the wheel?

demosthanos

4 days ago

In JetBrains's Developer Ecosystem 2023 survey, 50% of developers were still regularly working in Java 8 [0]—the exact kind of "stick with the old version of the runtime" solution described in TFA.

[0] https://www.jetbrains.com/lp/devecosystem-2023/java/

4 days ago

I've been involved in bringing real old Java 1.4 and 6 and whatnot up to 17 and from classic app servers into cloud, can take a bit of work but it's pretty straightforward, mostly switching out deprecated methods to their successors and copying over boilerplate config from similar applications.

mleo

4 days ago

Depends on the frameworks in use. I have done the same as you in bringing code that was originally started on 1.4 up to 17 and now 21 and it just took grunt work, but not too crazy since most of it was bog standard Java.

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

neonsunset

2 days ago

In the last few years C# did away with implicit nulls. Nullable and non-nullable object references are disambiguated with T? and T. There are multiple keywords and expressions to further make it nice to work with these. You would be correct to note that there are "nullability holes" in certain edge-case scenarios, particularly around JSON serialization. But other than that it's a pretty smooth sailing.

If you do use C#, you may also want to add <WarningsAsErrors>nullable</WarningsAsErrors> to .csproj too.

cies

2 days ago

I know it's a bit like Kotlin. I heard though that C#'s move still has some std lib bits that are nullable.

neonsunset

2 days ago

The idea is not to never have nulls. It is pointless (ha) - the way to understand T? vs T in C# is like an optional.

The entirety of standard library is annotated since long time ago. All new and not so new projects are also null-aware. Pretty much either completely legacy libraries or libraries that explicitly removed Nullable: enable that is set by default for all new project templates do not have those.

As I mentioned previously - it isn't perfect, but the level of "good enough" of NRTs in .NET is such that the nullability is a solved problem.

leptons

2 days ago

I prefer Assembly before any of the fringe languages you mentioned. There are no types in Assembly, and I rather like it that way. If you know how to work with data, then there's very little confusion about what you're doing.

And there's a reason practically nobody uses the languages you mentioned, and Javascript is so wildly popular. Most people don't really like or need type nagging systems. Sure, if you're trying to launch a rocket or doing something like building medical equipment or something else that requires covering your ass, then yeah, sure, go ahead and type the hell out of it. But for most programming tasks the languages you mentioned are overkill and frankly too obscure to use.

cies

2 days ago

JS is popular due to it being the only browser lang. Did you forget that?

Also: TS popularity shows that not everyone in the JS community agree with you.

For server side web dev you will find that statically typed langs (Java, Kotlin, C#, Go) are a big chunk of the pie. Sure it also comes down to taste, but if you work in a large team, having stronger types can greatly help to keep the codebase in shape. (better IDE refactor tools, clearer for noob, harder to hide/ check in rubbish to git)

If you are afraid by obscurity, have a look at Kotlin!

leptons

2 days ago

Typescript is still nowhere near as popular as Javascript, and likely never will be. It's overkill for the vast number of uses of Javascript.

cies

One can argue that this decision should be revised by debian but you should not install packages on system python installation for working into projects. Always use virtual environment.

Ameo

4 days ago

No that does not work either. You get an error like this:

» pip3 install supervisor error: externally-managed-environment

× This environment is externally managed ╰─> To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install.

As far as I can understand, they did this on purpose to dissuade users from installing packages globally to avoid conflicts with other Python environments.

Anyway, I'm not trying to argue about if that decision is right or not - I just wanted to use it as an example for my case that the JS ecosystem isn't alone and may even be far from the worst when it comes to this kind of issue.

elashri

4 days ago

I understand that, you can use `--break-system-packages` or change configuration `python3 -m pip config set global.break-system-packages true`.

Python is different here because in many linux distributions, there are many tools that rely on you system python. Python unlike node is not limited (in practice) to web applications. that's why you have to be more careful. So while I understand you are using this as an example, I don't feel that your comparison is apple to an apple.

LamaOfRuin

4 days ago

>Python unlike node is not limited (in practice) to web applications. that's why you have to be more careful.

They may or may not be running Node.js specifically, but I believe that many Linux distributions, as well as Windows, include JavaScript code in core applications. I don't see this as particularly different, except that they might choose to assume a single standard system Python that is able to be modified by standard Python development, whereas I would rarely expect that to be the case with however each component chooses to execute JavaScript.

elashri

4 days ago

Apps that rely on OS provided Webview and electron apps are totally different situation. This is exactly what I said. And no, they don't use any standard nodejs installation like python. And they are different as I said. so this is still apples to orange comparison.

LamaOfRuin

4 days ago

>Apps that rely on OS provided Webview and electron apps are totally different situation.

No, they're not. I'm talking about core apps and services that are essential to a functional operating system. This is exactly the same situation. The difference is choices made by the OS and language ecosystem about how to manage dependencies in various use-cases. It is an apples to oranges comparison because of those decisions and not because of the language.

jcelerier

3 days ago

Which apps would that be ? I'm pretty sure there's zero node server running on my desktops & laptops at the moment

regularfry

fragmede

3 days ago

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

> As for compiler issues, just run it with the same compiler.

And when the same compiler doesn't exist for your new machine?

Freezing everything makes things easier in the short term, but much harder in the long term.

viraptor

4 days ago

This is not even JS specific. All of Python / Ruby / other changing runtimes will require some upkeep. Even C recently needs some attention because clang updated default errors.

user

4 days ago

[deleted]

In exchange for needing to run C? How many hours would it take to build a Node app equivalent in C, I wonder.

regularfry

4 days ago

0 would be fine. I'd take 0. This could all have been avoided if the interpreter version had been recorded by default somewhere. That's all this needed.

mattgreenrocks

4 days ago

Other ecosystems usually do not have problems to the extent the author had.

hathawsh

4 days ago

I am deep in the Python ecosystem, and I love Python, but I have to admit that Python has the same issue. Reviving a medium-size project after 4 or more years usually means I have to catch up on a lot of new surprising deprecations. That's not because there's anything wrong with Python; it's more of an economic issue: the authors of active libraries have little or no economic incentive to support old, deprecated versions, so they just don't. That's life in the modern world. It is a deep problem that should theoretically affect every large software ecosystem because very few library authors can predict the future with great accuracy, and very few open source library authors have any significant incentive to support old ideas.

tmpz22

4 days ago

> That's life in the modern world. It is a deep problem that should theoretically affect every large software ecosystem because very few library authors can predict the future with great accuracy, and very few open source library authors have any significant incentive to support old ideas.

I disagree. This is an easy problem to avoid with minimal due diligence, people just choose convenience and make unnecessary tradeoffs.

* Use the standard library (ironically not available for Node projects). It will be built with better backwards compatibility almost every time. What deprecations do occur will likely be VERY WELL documented with much quicker adaptions.

* Limit third party dependencies. Do you really need an ORM for your apps 40 sql queries? How long would it take you to scaffold it with GenerativeAI then make it production-worthy without the ORM? 1 hour? 5 hours? 20 hours?

* Pick technologies with better track records. Maybe don't use Beta software like Swift Data for your iOS App. Maybe choose golang for your API even though it'll take a little bit longer to build it.

Nadya

4 days ago

And this is how you end up with rewriting the world and spending more time rewriting dozens of existing libraries to avoid adding them as dependencies and less time working on the problem you're actually trying to solve because you're fixing the same dozen bugs that the first person already went through the trouble of fixing for you had you simply used their library instead of eschewing it and having to learn everything that they had already learned for you. Often times because the problem space is deeper than you could have known before getting into the weeds and hopefully you don't get bit by sunk cost and decide to do yourself a favor and just use a library instead of continuing to work on solving problems that aren't related to what you set out to do.

There's a balance to be struck between LeftPad scenarios and "Now there are 37 competing libraries".

hathawsh

4 days ago

Exactly. The right thing to do is study each dependency and decide whether the reward of having the problem solved quickly is worth the many risks of adding dependencies.

I'll acknowledge here that there seems to be a significant difference between Python projects and Node projects: in my experience, a small Python project has a handful of dependencies and maybe a dozen sub-dependencies, while a small Node project usually has a handful of dependencies and a few hundred sub-dependencies. That's where Python's "batteries included" motto does seem to help.

tmpz22

3 days ago

> There's a balance to be struck between LeftPad scenarios and "Now there are 37 competing libraries".

I think we're actually in agreement. My assertion is that for projects which want to avoid constant maintenance, particularly small projects, you can make architectural decisions some of which could significantly improve the maintenance outcome. Of course there are trade-offs to those, and if you make the wrong architectural decisions it can cause more harm than good.

Maybe I'm glib for calling it "easy" but for many leftpad scenarios it really is a "holy crap why did you think that was ok" scenario in my experience. Lets avoid those scenarios when we can.

pjc50

4 days ago

> How long would it take you to scaffold it with GenerativeAI then make it production-worthy without the ORM?

Having a machine do codegen to map your queries to objects is still an ORM, except now it's nondeterministic and not updateable.

(mind you, I come from C# where you simply use LINQ+EF without worry, or occasionally Dapper for smaller cases)

paulddraper

a day ago

> Use the standard library (ironically not available for Node projects)

???

Node.js has an extensive stdlib [1].

Contrast that with Python which practically requires a 3rd party HTTP client.

Or Java that doesn't even have JSON support.

[1] https://github.com/nodejs/node/tree/main/lib

lmm

4 days ago

> That's not because there's anything wrong with Python

It's absolutely because there's something wrong with Python, the package management, and also the type safety. JVM languages haven't had these problems for 20+ years.

the_mitsuhiko

4 days ago

> I am deep in the Python ecosystem, and I love Python, but I have to admit that Python has the same issue.

The same problem in Python is much easier now because you can ask the uv resolver to limit itself to some earlier point in time.

You can do `uv pip install --editable . --exclude-newer=2022-01-01` and you will end up with a resolution from two years ago. Since uv can also install older python versions automatically you can easily bisect you to a newer point.

cle

3 days ago

Will uv even be around in 4+ years? No idea.

the_mitsuhiko

3 days ago

I don't know either, but think even if it's not, whatever will replace it, will at least have to achieve feature parity.

4 days ago

Also, Gatsby has dependencies that aren’t even Node. I have had it break too.

thiht

OTOH with Node I always find myself in dependency hell with dealing with old projects.

fbn79

3 days ago

In my experience this only happen if the project does not have a lock file and does not specify a node version (two good practice that must be followed).

cies

2 days ago

I'm talking about upgrading dependencies. Something that's rarely easy in a JS/TS project with lots of dependencies.

em-bee

4 days ago

it took two hours just to get the project running as it was 4 years ago. wait how much time it will take to upgrade everything to new versions.

and dare i say this is the lucky case. i had problems reactivating some older project because some dependencies were not version locked and newer versions of those were incompatible with other versioned ones. then it took forever to figure out the right versions. and i think i even had situations where the old version wasn't even available anymore (perhaps because of a linux dependency that wasn't available anymore on my newer linux system)

DecoySalamander

4 days ago

It took 2 hours to realize that project build for a specific version of node should be run with that version of node. And even that was self inflicted since author didn't vet dependencies and used something build as a C++ node addon instead of actual JS (my bet it was to have a slightly easier time writing CSS).

kwertyoowiyop

3 days ago

And even though it builds, there’s no guarantee it’ll work properly.

antihero

4 days ago

Yep, this could have been sorted by one line in a .tool-versions file and using mise or asdf.

ericmcer

3 days ago

Exactly, you would have to compare it to other package managers to make it fair.

Npm at this point is probably the most used and most worked on package manager in history. If it is still one of the worst ones that is actually kind of interesting philosophically.

molszanski

4 days ago

4 days ago

Did you read it? The author did not actually resolve the issue, only figured out that it should build with older Node version.

abdisalan

4 days ago

You’re absolutely right. My rational brain agrees and chalks it up to poor project management. However… emotions run high when you have zero idea why something isn’t working and the process of elimination is pretty taxing. So the point for me is venting / maybe someone will read this and remember to write their node version down!

MatrixMan

4 days ago

> Two hours of my life gone, just to pick up where I left off.

If I had only wasted two hours every time I had to use npm for some reason I'd be significantly ahead of where I am now.

kiru_io

2 days ago

Doesn't that apply to any it-issues you don't know how to solve?

MatrixMan

did you experience this breakage using poetry too?

uludag

4 days ago

The worst part isn't just that it's nearly impossible to run/update an outdated JS project, but that this process will repeat itself ad infinitum.

On the flip side, anything that uses vanilla JS without a build will most likely run just fine, probably till the end of human civilization.

graypegg

4 days ago

I truly believe some flavour of "Javascript Classic" (some future state of JS before some big shift in syntax/mass migration to something else), C and x86 instructions will follow humanity for the rest of time. There will be javascript somewhere aboard the interstellar spaceships of the future, and we will still complain about it.

mst

4 days ago

I think it was 'A Deepness In The Sky' that posited so many layers of legacy underlying the starship control systems of the era that one of the most crucial positions on a ship was that of 'Programmer-Archeologist.'

wpm

3 days ago

That sounds great. Added to my list.

I adore the idea of somewhere on the Star Trek Enterprise, underneath the isolinear chips, the EPS conduits, the warp containment field control mechanisms, somewhere, if you dig far enough, override enough, you can get an LCARS screen that is all black, with a small `$` in the upper left and a blinking text cursor, waiting for a command.

jeffrallen

3 days ago

I am already a programmer archeologist, and it's one of the most rewarding parts of my job. Though my most recent project is regrettably well written and maintained. :)

elzbardico

4 days ago

Well, even Fortran is still around us in some lapack code in numpy and in a lot of the stuff behing scipy, so, a lot closer than a lot of people can imagine.

Basically a lot of AI depends on a bunch of absurdly optimized numeric libraries writen in Fortran.

Fortran is well into the way at becoming a centenarian programing language at 74 years of age.

pavel_lishin

4 days ago

My grandchildren will live to see Vernor Vinge's programmer-archeologists troubleshooting PHP issues on the Wordpress install responsible for life-support around Alpha Centauri.

kwertyoowiyop

3 days ago

Just bobble some programmers now.

3 days ago

The Webassembly dev experience is awful, and it needs to be glued together with JavaScript anyway. 99% of web code doesn't care about the performance difference, and anything GUI is wasting more time jumping back and forth to JavaScript to save any time at all.

peutetre

3 days ago

> The Webassembly dev experience is awful

It really isn't. Wasm is just a compilation target now.

spacebanana7

3 days ago

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.

peutetre

3 days ago

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.

spacebanana7

3 days ago

JavaScript’s main advantage is being commonly familiar to most software engineers.

The English language similarly lost its position as the preeminent imperial language a long time ago, so too with Latin & Rome. It takes a long time for a popular language to die because everyone wants to speak what everybody else speaks.

saulpw

3 days ago

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

em-bee

3 days ago

4 days ago

YMMV but I had a 4 year old project whose only dependencies were socketio and express and it booted right up. So stick to stable, mature projects and you're likely to be fine.

authorfly

4 days ago

Just watch out because socketio must be version matched for client-server or you will get the most annoying errors and state inconsistencies in the world. That's a scary production update let me tell you. Version 2.3.0 still scares me to this day after trying to upgrade that without production downtime.

cxr

4 days ago

> it's nearly impossible to run/update an outdated JS project

You corrected yourself, but it's worth emphasizing here: a _NodeJS_ project, you mean.

Unless you're using non-standard APIs, stuff written to run in the browser generally keeps working just as well as it did before, no matter whether it was written 2 years ago or 10.

wink

4 days ago

It is showing its age though, particularly around the edges like what you're saying.

regularfry

4 days ago

Quicklisp is a start, and I like that it's a Debian-style distribution because it can at least move towards making the assertion that everything in the distribution is mutually compatible. The problem is that the underlying ecosystem has no culture of saying "version X of library A is only compatible with versions Y+ of library B". You can put that info in the asdf system definition but I don't see many examples of it.

The other problem is rate of updates, and that's a symptom of it basically being on one person's shoulders to keep it ticking over. I can't readily think of another major language ecosystem with that characteristic. It just seems really fragmented.

liontwist

4 days ago

Quicklisp is merely a registry for getting libraries, not shipping code. Download what you want and use asdf.

regularfry

4 days ago

Yes, that's what makes it immature. There doesn't seem to be anything in the ecosystem to handle version resolution. Qlot is a start towards that in that you can at least specify alternatives to get yourself out of a hole, but you still ended up in the hole in the first place.

liontwist

4 days ago

I think it’s a good thing. I don’t want npm for Common Lisp.

regularfry

3 days ago

Which bit is it that you object to?

Edit to add: this wasn't intended as a gotcha question, so apologies if it came across as one. I have issues with a lot of details about how npm works and the ecosystem it supports. I think it's possible to avoid them, and aim for something more like a bundler or a cargo, but again there are issues there (certainly in the former's case, I have less experience of the latter). Getting to a good answer that works for CL means understanding both the problem space and the known solutions elsewhere.

It might be that "a better quicklisp" is enough?

liontwist

3 days ago

Sure, I didn’t take that negatively.

Let me start with facts:

- npm actually downloads multiple copies of each library, when needed to satisfy conflicting version requirements. - this is only possible due toruntime features of JavaScript. In most languages like C this causes symbol collisions. - I think this is a problem in Common Lisp too due to packages being global. Maybe there is a fancy way to rebuild packages at load time. - this is why the Debian style release makes sense. Either everything loads together, or not.

Opinions - I want to know all my dependencies. I treat them as my own source, so tar downloaded is close to my mental model. - For c projects I usually have a make file with curl commands tied to exactly url. If I want to update I manually change the url. - quicklisp already has a nice way to make an isolated folder just containing your code and its dependencies to be loaded with asdf. It gets out of the way once you have downloaded your libraries.

regularfry

3 days ago

Yes, that "feature" of npm isn't something you'll find elsewhere. It's not inherent to the problem of version resolution. Just about anywhere else you'll just get an error message that the version resolution isn't possible, if there's no available combination to satisfy all the requirements.

That one design attribute of npm probably more any other feels like they did it because they could, not because it was a particularly good idea.

skybrian

4 days ago

Go’s minimum version selection is the way and I don’t understand why other ecosystems haven’t adopted it. You’re be able to compile an old project with all the library dependencies it had at the time it was released. It might have security issues, but at least you start with a version that works and then can go about upgrading it.

It also helps that if some library dependency generated Go code using a tool, the Go source code is checked in and you don’t have to run their tool.

Macha

4 days ago

Getting the exact dependencies it had at release is a solved problem in Node and most other languages with lock files too.

It's just no guarantee that those old versions work on the new system, or with the outside world as it exists by time of installation - which can be as true for Go as any other language. If the XYZ service API client still gets you version 1.2.37, that's not actually any help if 1.2.37 calls endpoints that the XYZ service has removed. Or a cgo package that binds to a version of OpenSSL that is no longer installed on your system, etc.

vessenes

4 days ago

This is why I say it's a cultural problem, not a technical problem. In goland, changing API calls in minor versions is pretty much a sin. At least it's something you'd do .. carefully, probably with apologies. In node, it's extremely routine to re-pin to newer modules without worry.

4 days ago

It’s the same with R. The only thing preventing many ancient packages from running under new versions of R and vice-versa is the fact that the package author simply set the minimum version to whatever they happened to be using at the time.

gr4vityWall

3 days ago

I recently migrated a project to Node.js 8 (!) to Node.js 14 (hopefully just the beginning), and I can relate to this post.

In the JS ecosystem, I'm aware that Meteor is one major framework that takes backwards-compatibility seriously. Updating a project on an ancient version to a less-ancient version usually is not too hard. They try to keep APIs the same and introduce compatibility packages where possible.

Meteor 2.16 to Meteor 3 introduced major breaking changes due to an underlying technical issue that had no workaround. They had to refactor the whole project from using Fibers-based concurrency to typical async/await.

node-gyp in general has also been a source of issues in the past for me as well.

More recently, ESLint changed their configuration file format and all existing tutorials suddenly became outdated.

I firmly believe the ecosystem does not have to be like this, and we would save a lot of man-hours by being more committed to API stability where possible.

yawnxyz

3 days ago

> Meteor 2.16 to Meteor 3 introduced major breaking changes

3 days ago

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

sgt

4 days ago

I've actually had a node project go bad in a mere 4 months. It must be a new record. That was about 4-5 years ago though.

Hopefully the ecosystem as improved since then, but it was nearly impossible to get going.

Some packages had been changed and the version number overwritten with incompatible packages, and the conflicts were plenty.

jerf

4 days ago

One of the things I'm intrigued by is that JS people, and the other couple of ecosystems where this is a big problem, go out to learn another language (as a good T-shaped developer does), and then start posting frantic questions to the new language's communities about how this popular library hasn't had a commit in six weeks, is it dead, oh my gosh wtf aaaaaaaaaaa.

It's OK. Not every language ecosystem is so busted that you can reliably expect a project not to work if someone isn't staring at it weekly and building it over and over again just in case. Now, it's always a risk, sure, no language anywhere is immune to the issue [1], but there's plenty of languages where you can encounter things from 5 years ago and your default presumption is that it's probably still working as well now as it did then. It may be wrong, but it's an OK default presumption.

[1]: Well... no language in common use anyhow. There's some really fringe stuff that uses what is basically content-based references for code dependencies, but I'm not aware of anything that I'd call "production quality" that even remotely looks like that, and is immune to someone just plain making an error with the semantic versioning or whatever.

toast0

4 days ago

> frantic questions to the new language's communities about how this popular library hasn't had a commit in six weeks

Lol, my perspective is almost the opposite. If it's got a lot of commits in the last six weeks, I need to look for something that's stable. Unless there's a good reason for so many commits; I feel like that many commits means it's in active development, which implies the requirements and interfaces aren't yet determined and who wants to rely on that?

rootnod3

Client, not server.

toast0

4 days ago

If it has an issue tracker, you can look in there for things that look like real issues and are unaddressed.

4 days ago

Absolutely not. Not on the client side anyway.

I know of one application by a large multinational that requires java in the browser to run. Almost impossible to run now because of security restrictions.

This is all, of course, still totally stupid - but I did find myself thinking how much worse comparable events in JS have been for me over the years. What would have been easily an entire afternoon ended up taking 15 minutes - and a chunk of that was just double checking commands I'd long forgotten.

kaptainscarlet

4 days ago

That is nothing..Try building your Android project after leaving it idle for a week. Or better yet, try building you react native project you left for 2 days.

91bananas

4 days ago

OMG I feel this in my soul. Try looking at one of the gradle files wrong in a kotlin multiplatform app with shared ui.

abdisalan

4 days ago

Hold on, you had to do binary surgery using an OpenSSL version from an old box you had? I salute the dedication.

marcosdumay

3 days ago

3 days ago

I think the other foot-gun here is that the official recommendation is that library crates not check-in their lockfile (I assume because that prevents downstream crates from freely taking updates to common dependencies).

This has the unfortunate side-effect that while downstream apps might still build, the library itself (and any examples in the library repo) may not compile after some time...

vulcan01

4 days ago

This is why Nix (with flakes), in a git repository, will refuse to use a lockfile that isn't being tracked by git.

pornel

> For those reading this who don't know much about node

I would prefer to remain blissfully ignorant, thank you!

com2kid

4 days ago

IMHO TypeScript is the best mainstream language to write code in right now. It is incredibly expressive and feature rich, and you can model in almost any paradigm you like. The ecosystem around it allows you to choose whatever blend of runtime vs compile time type safety you prefer. Lots of people just runtime type check at their endpoint boundaries, and use compile time for everything internal to a service, but again, the choice is yours.

The Node+Express backend ecosystem is also incredibly powerful. Node is light weight, the most naïve code can handle a thousand RPS on the cheapest of machines, and you can get an entire server up and running with CORS+Auth+JSON endpoints in just 5 or 6 lines of code, and none of that code has any DI magic or XML configuration files.

JS/TS is horrible for numeric stuff, but it is great for everything else.

philipwhiuk

4 days ago

Why did you click on "The tragedy of running an old Node project" then

ramesh31

4 days ago

>Really wonder how that wart became such a critical tool used by so many packages.

The original dream for Node was that it would simply be a glue wrapper around libuv that allowed for easy packaging/sharing of modules written in C++. But everyone just started writing everything in JS, and the ecosystem ended up as a mish-mash of native/non-native. Ryan Dahl stated this was indeed his biggest mistake/regret with Node, thus we have Deno now.

com2kid

4 days ago

> But everyone just started writing everything in JS, and the ecosystem ended up as a mish-mash of native/non-native.

Because the native written stuff breaks all the darn time and it creates cross-plat nightmares.

My stress levels are inversely proportional to how many native packages I have to try to get building within a project, be that project in Python, Java, or JS.

JS+Node runs on everything. Prepackaged C++ libraries always seem to be missing at least one target platform that I need!

mst

4 days ago

The CPAN 'Alien' infrastructure is great for this, you have pseudo-modules that you can depend on that use vendor packages if available and build the damn thing for you if not.

It's considered ... rude ... in most cases to write a module that needs to build against a native library without also having an Alien dist to handle making sure said library is there by the time it's trying to build against it.

Opinions on perl as a *language* ... vary, let us say ... but I wish people who didn't like writing perl would at least look at how our infrastructure works and steal more of the good parts to make dealing with their preferred language less painful.

int_19h

4 days ago

Seamless native builds are quite doable, but the tooling needs to be very deliberately designed around that. For a good example of how far this can be taken, consider https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

com2kid

4 days ago

mkoryak

4 days ago

i forgot all about node-gyp. The only memories I do have of it are the errors and thinking about gimps.

beardyw

4 days ago

I'm pretty sanguine about languages and frameworks, but I draw the line at node. I have seen so many horrors visited by dependencies, often to do just one thing where 2 or 3 lines of code would do the job anyway.

When I was managing teams, whatever the language, I would ban any new dependencies which I didn't personally agree with. A lack of control just creates a nightmare.

CognitiveLens

4 days ago

Was that kind of control well-received by your teams? Out of context, it sounds like it would be pretty rough to be an engineer on a team where your manager had sole control over what tools you could use - I suppose it might make sense for junior devs or a very small codebase, but I would caution against taking that stance in a team where you want to facilitate mutual trust

mst

4 days ago

Provided the manager only rarely exercises the power, and is open to being persuaded not to, having somebody able to veto risky dependencies can be really quite useful.

Normally when I'm the one with that power we rapidly get to a general understanding of what's small enough that I (a) probably won't care (b) will take responsibility for tweaking the schedule to makre time to get rid of it if I do.

And 'big' dependencies are generally best discussed amongst the entire team until consensus is reached before introducing one anyway.

beardyw

4 days ago

Well back then there were fewer options, but the result was that completed products were easy to work with. Perhaps we live in different times.

3 days ago

Yeah, Nix pretty much solves this problem. The other day I wanted to try a really old version of spaCy for fun/historic interest. spaCy 1.8.2 installed freshly from the binary cache on NixOS-unstable as if it was still April 2017.

brokencube

4 days ago

My first step now when trying to resurrect old projects is to create a Docker container for it - that way I can install any old versions of anything (like node or PHP) I need without having to worry about it polluting anything else on the system.

everythingishax

4 days ago

This is literally every "hot new thing" since 2000.

4 days ago

I had this exact problem with multiple Node blog engines in the past. Constant version breakage was incredibly frustrating. I eventually moved to Hugo. A single binary which I committed with the blog files. Zero issues even years later. I can build the blog on any new machine within seconds. Which was the other revelation of Hugo. 10 seconds to build an 800+ post blog vs minutes using Hexo or similar.

anonzzzies

4 days ago

We run node code that's 10 year old. No one dares to touch it; we just run it in docker and hope nothing goes wrong.

stall84

3 days ago

It's not just personal blogs as many of y'all know.. this is a daily struggle in any SDE mainly working in web .. I am constantly lamenting the fact I spend like 70% of my time at my main job (large financial company) just trying to get my environment , or the application's environment in a position to actually develop on the application itself .. It's insane. I f'n love javascript .. it's allowed a lot of us a doorway into software engineering where a lot of us realize how ... 'special' js and related web development are ;) .. But man it can make you really want to smash the computer some days.

melbourne_mat

4 days ago

First thing I would have done is upgrade the version of Gatsby to latest. Did the author try that?

If upgrading is difficult because of 4 years of breaking changes, blame Gatsby for not being backwards compatible. Also blame your original choice of going with a hokey framework.

Speaking of hokey framework: 167 dependencies and 3000 versions of Gatsby in npm.

Eric_WVGG

3 days ago

The first thing I would have done is check the version of Node.

That's a quick fix, upgrading a framework is a guaranteed min hour of poking around before the system is even running.

I dunno why `engines` isn't in every `package.json` file, would certainly have saved me hours of nonsense.

baq

4 days ago

blaming anything or anyone gets you exactly zero seconds closer to getting the job done.

tomgp

4 days ago

You could perhaps reframe "blame" as identifying the source of the problem and iunderstand why it can be a useful excercise (aslo none of us here are trying to solve the problem really, just wasting time on the internet). In this case Node and it's atendant ecosystem are certainly a part of the problem but I would agree that Gatsby is a bigger part of the issue as they don't seem to have any interest in taming the Node dependecy management beast. I've had to dig into Gatsby projects mere months old and it really was like opening a can of worms.

Eric_WVGG

3 days ago

> In this case Node and it's atendant ecosystem are certainly a part of the problem but I would agree that Gatsby is a bigger part of the issue

I disagree completely. Regardless of what you think of Gatsby, Node versioning is a simple problem that affects nearly every javascript project. It should always be the first thing you check.

I made this dumb obvious mistake again just last week, looking for a little time to audit all my `package.json` files for `engines`.

brunoarueira

4 days ago

I think many issues goes with bad version or, in some edge cases, not vendor dependencies. I'd good and bad experientes on multiple programming languages, some bad examples:

- bump patch or minor version from a react package but the maintainer rewrote the entire project breaking a lot of things, following semver it's bad to expect things don't break like that for such version; - another example, the ruby gem is removed/yanked from rubygems.org and you'd to find a fork available

On the end, we need to ensure the good practices from software engineering about tests and good release management, the last btw is decades old

JansjoFromIkea

4 days ago

node-sass is to blame for like 95% of these node-gyp issues in my experience, it's not that much grief to deal with but it's hard to grasp how it was allowed to hang around so terribly for so long

pier25

4 days ago

> it's hard to grasp how it was allowed to hang around so terribly for so long

It's not hard. The explanation is simply that the dart version of SASS (the sass npm package) is much slower than node-sass.

At one point it was like 20x slower and I believe right now it's about 2-3x slower.

https://github.com/sass/dart-sass/issues/1534

sn0n

3 days ago

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.

droptablemain

a day ago

As a rule of thumb if you are jumping into a legacy node project the first thing you should try is a sequentially older node version. Could've reduced his two hours to two minutes.

alganet

4 days ago

node-gyp was a mistake, building of native addons should have been an explicit separate step all along.

em-bee

4 days ago

i could not tell from the article whether this was a site with a backend using node.js or if it was just a frontend depending on node.js for the build tools.

for the latter i get around the problem by avoiding build tools altogether. i use a frontend framework that i can load directly into the browser, and use without needing any tools to manage dependencies. the benefit from that is that it will ensure that my site will keep running for years to come, even if i leave it dormant for some time. the downside is that it is probably less optimized. but for smaller sites that aren't under continuous maintenance this is a reasonable tradeoff. i built all my recent sites that way using a prebuilt version of the aurelia framework.

incidentally just today i tried to research if i could build a site with svelte that way. well, it turns out that although it should theoretically be possible, i was unable to find a prebuilt version to do so after a few hours of searching. for vuejs i found one within minutes. i'll be learning vuejs now.

see this thread for a discussion on going buildless: https://news.ycombinator.com/item?id=41479365

mst

4 days ago

I've been experimenting recently, with quite some success, with having a 'libs.js' file that pulls in and re-exports everything external I want, and providing a script that applies 'bun build' to just that.

I haven't yet decided if/how I want to include a prebuilt version of it in the repo, I *think* I may go the approach of having a commit that modifies libs.js and/or the lockfile and then an immediately following one that commits an updated prebuild ... oh, huh, actually, I should probably also consider doing those two commits on a branch, then forcing a merge commit so they land on master atomically but it's easy to tease out the human changes and the regen changes by poking inside said merge commit ... yeah, like I say, still thinking about exactly how to do this, don't mind me.

Also for even simpler cases I've been using the preact-htm prebuild directly, since htm gives a lit-style html() tagged literal consuming function that can produce vnodes for preact so I can mess around without needing something that understands jsx between my editor and my browser window.

3 days ago

Yeah, I can see how you read my initial comment, and given the combination of "I could probably have been clearer" and "my approach does not seem to be one people take very often" it makes sense for you to've read it how you did, hence me turning the verbosity up to 11 for my second attempt at explaining it :D

Given the javascript is still inside a <script> tag I would presume any editor that can handle a normal HTML page with some inline javascript wouldn't notice the difference, yeah. Hadn't honestly though of that since one of the first things I do in any editor is turn all the file format handling stuff off because I'm a curmudgeon who thinks in https://github.com/n-t-roff/heirloom-ex-vi

Yes re external templates; my usual approach to 'keeping the code and template close together' is to have them open in adjacent 80x24 xterms.

You might find mobx of interest - I tend to use that for state modeling no matter the framework doing the rendering - everybody seems to be getting very excited about 'reactive signals' these days and ... they basically all have their own implementation that feels, to me, like Yet Another NIH Of A Tiny Subset Of MobX ... except invariably missing at least one feature that I really wanted.

Which is how I ended up with my own libs.js on a current project, the sum total of which is

    export { render, createElement, options as 'preactOptions', Fragment } from 'preact';
    export { observable, action, computed, flow, createAtom, Reaction } from 'mobx';
    export { observer } from 'mobx-preact';

and then on the fairly sporadic occasions that I need to adjust the exports I have a shell script that does a tiny bit of bookkeeping and then runs

    bun build --format=esm src/web/libs.js >bundle/web/libs.js

so I run that, and then go back to forgetting that the build process (and the node_modules directory it's sourcing those libraries from) exists.

I also have about 20 lines' worth of custom dev server that will serve the bundle/ file preferentially over the src/ file if it exists, plus a couple other minor things.

But this is, for me, all about keeping things as simple as possible barring some slight effort towards ergonomics, plus knowing that I understand every part of what's going on so I don't end up stuck in a "one of my abstractions is leaking and I've no -ing idea how or why" type situation (hence also my very minimalist choice of editor, any time I try a more clever one I fairly rapidly end up in a situation where the tab completion does the wrong thing so I just type everything out anyway, or where the syntax hilighting produces colours that give me a headache, or ... just colour me a curmudgeon who learned his chops on ancient BSDi and Solaris systems, I don't expect anybody else to want to use my dev environment but it works for me).

Anyway. None of this is to try and convince you of anything much, I just thought you might find my setup vaguely interesting. I'll stop waffling now :D

em-bee

2 days ago

Given the javascript is still inside a <script> tag I would presume any editor that can handle a normal HTML page with some inline javascript wouldn't notice the difference

i agree. it's been a while that i looked at vuejs, and i don't know why i came away with a different impression before. must have not looked closely enough.

i haven't seen mobx before, but when i read the description i wonder why i need it. my preferred framework is aurelia and as far as i can tell aurelia already does what mobx claims to solve, in particular this part (from the mobx github page):

Trying to update a record field? Simply use a normal JavaScript assignment — the reactivity system will detect all your changes and propagate them out to where they are being used

it is actually the primary reason why i like aurelia. with aurelia i don't even have to mark properties as observable. it figures that out on its own based on the bindings i make in the html template.

though mobx may be interesting when i work with other frameworks that don't do that. i'll have to keep that in mind. (edit: it looks like it may come in handy when statemanagement becomes complex: https://stackoverflow.com/questions/39454579/best-practice-u... )

keeping things as simple as possible barring some slight effort towards ergonomics, plus knowing that I understand every part of what's going on

yeah, i like that too.

I just thought you might find my setup vaguely interesting

i do indeed. thanks a lot for that. my own setup is actually also quite simplistic, but not deliberately so. it's mostly lazyness. i simply don't want to be bothered to put a lot of effort into a better dev setup. i'd rather work on actual code. so i start with plain vim without any addons, and only slowly change stuff when i run into a problem that really bothers me. solaris, AIX, irix is where i started.

mst

2 days ago

When I start with "plain" vim the first thing I do is drop in https://trout.me.uk/X11/vimrc to nerf it back to as close to ex-vi as I can get - because my muscle memory comes from classic vis (between the mostly-BSDi job and the mostly-Solaris job I did devbox sysadmin for a software house, so I got to handle Solaris, AIX, IRIX, Tru64, SCO OpenSewer, and a couple others all at the same time ;) my experience of ex-vi versus vim is "when I typo in ex-vi it beeps at me, when I typo in vim it activates yet another feature I didn't know existed and breaks my concentration."

I took a quick look at aurelia after you mentioned it and am clearly going to have to take a deeper look at some point, I'm curious how it's handling all that under the hood, and for cases it handles well it does indeed look really rather nice (though being me I'll need to take it apart before considering using it, automagic reactivity is really cool but only when I can reliably dry-run its path through the framework in my head as I'm writing the code that (ab)uses it).

(so, cheers for mentioning aurelia, all the best conversations involve both/all people involved coming away with extra things/ideas to poke at :)

Anyway. To mobx:

I think the best may to understand mobx before you've actually used it is roughly "it not only provides simple reactivity stuff, when stuff starts getting more complicated you'll find that the more powerful tools you wanted are already there, implemented, and will show you what they're doing in the devtools out of the box."

As an example, computed() is very handy (and the one mobx feature other than just "reacting to changes" that most frameworks' reactivity implementations *do* copy, although I have vague memories of them not always copying it as thoroughly as I'd like) - so this is a bit of a "too simple" example but we're in HN comments so

    class SomeData {
    
      @observable rawData = [];

      @observable sortBy = 'someField';
    
      @computed get data () {
        let { sortBy, rawData } = this;
        return rawData.toSorted((a, b) => (a[sortBy] - b[sortBy]));
      }
    }

(sort function designed for numerics only, dumbass example is dumbass)

and then assuming your display component is tracking its dependencies somehow, a change to the `someData.sortBy` field will automatically expire the cached `data` element and notify the component so it can re-render, at which point `data` gets recalculated and re-cached (and all this will show up as events in the devtools if you've stuck them into your page somewhere).

Since aurelia is basically taking apart your bindings to figure out what to observe, I think it wouldn't be able to track that, and you'd instead have to make sure that when `sortBy` gets changed it fires a trigger to recalculate the `data` field (and then aurelia *would* notice that getting set to a new value).

(aurelia may be smarter than I think, but the only way I can think of for it to *be* the necessary amount of smarter would basically be to implement a subset of mobx's makeAutoObservable and I don't think it does that and I don't think given aurelia's (clearly consciously chosen) aesthetic it *should* do that)

I'm tending towards having viewstate kinda objects as a layer and then model objects behind them, so `rawData` would delegate to the model objects in the above example - then the code that modifies the data I'd be persisting to a backend doesn't have to think/know about how it's going to be displayed, but if you modify it - `addTodo` or an `editTodo` or similar - the change notifications will propagate outwards, expiring things in the viewstate, causing things in the view to notice and re-render themselves as required.

This is especially noticeable to me when e.g. I'm writing a data viewer onto a table of log entries (or something in that vague area, *handwaves vigorously*) and I want to have a 'Refresh' button - that triggers something in the model layer that does a `fetch()` call or whatever, and then sets the new model data to whatever the backend sends back ... and then everything re-renders, keeping all my display choices intact because the viewstate layer didn't get touched.

My experience of learning mobx included a number of "oh for crying out loud, I've implemented half of this feature the hard way in three projects before now" moments - and *that* was what made me fall in love with it.

You might also want to bookmark (and then mostly ignore for the moment) mobx-keystone, which is Even More Complicated under the hood, but provides fairly simple syntax for declaring a tree of reactive state classes that provides (typed if you're using typescript) constructors for you, tree snapshots if you want to be able to save your session state to the backend to resume later, and mutation event logging as JSON-able objects that also includes reverse versions so you can get full undo with a fairly minimal amount of effort (I never, ever want to write undo functionality by hand again, that always required a significant amount of bourbon). Not necessarily to actually *use*, mind you, but seeing what keystone is capable of was useful to my understanding of what mobx itself was capable of.

I ... there's definitely a "would rather be writing code than yak shaving my setup" aspect to my choices, but it's definitely also a question of having as few layers as possible between me and What Actually Happens so things reliably behave how I expect them to behave. Debugging is much more fun for me when I can be confident I'm debugging *my* code rather than there being a decent chance I'm actually debugging how I've misunderstood something else two layers down.

(also, if you're not doing anything particularly strenuous, I'd suggest having a look at bun as an alternative to node, all my 'real world' and/or work stuff is node and I'm not particularly offended by it, but bun is definitely a smoother and more DWIM experience for me, at least so far)

em-bee

a day ago

i get you on vi. i was there (3000 years ago ;-), although only at the tail end of it in the early 90s. i switched from emacs to vi because of my sysadmin job.

i am really curious what you make of aurelia once you take it apart. please ping me if it is not to much trouble. i discovered aurelia when angularjs 1 was being redeveloped into angular 2. rob eisenberg was invited to the angular team based on his work on durandal but when his ideas were not accepted he left again and built aurelia instead. aurelia is not perfect either, but it was way better than angular 2 or vue at the time.

on your mobx example, you are right, aurelia doesn't track everything. it may be able to handle some level of complexity but i certainly had situations where i had to explicitly send a signal to get aurelia to update values.

exabrial

3 days ago

2020 is not "old".

"Not Invented Here" is whats going on. Developers of this age need to learn this.

A recent exmaple is the RPI Foundation nullifying thousands of internet tutorials renaming "/boot" vs "/bootfs". Ask yourself a serious question, did that actually improve anything? No it did not.

pavel_lishin

4 days ago

> node-gyp

We're in ... let's call it a transitional period at work. I've got something like a dozen versions of node being managed by asdf. And in half of the projects I work on regularly, I consistently get warnings about this particular project failing to build.

One day, I'll actually look up what it actually is, and what it does, and why it's being built, but is apparently optional.

mst

4 days ago

It's basically a set of tools to make building native modules easier, that said modules then use to deal with their binding to C/C++/etc. code.

Everybody complains about it, and understandably so, but if it didn't exist you'd probably instead have one set of potential similar problems *per* native module which has a good chance of not actually being better overall.

The counterargument is, I guess, "well, only people who can write their own high quality build setup in-tree should be writing things that bind to external code," and I do sometimes dream of that, but it's not hard to see the downsides of living in *that* world instead either.

aronhegedus

3 days ago

Cool that you managed to get it running after just 2 hours. Same thing applies to python projects, a little note in README saves so much time in the future, I always try and use virtual environments and specify a specific python version so I can just nuke and reinstall everything

kylehotchkiss

4 days ago

Dealing with node-gyp cost me at least 5 hours a month in the 2010s. I'm so very happy to not see those errors in my console anymore.

philipwhiuk

4 days ago

Native code in an npm module should be regarded as a massive red flag.

hombre_fatal

4 days ago

Then I ran `devbox init` and installed whatever it told me that was needed. `devbox shell`.

Havoc

3 days ago

Node/JS seems particularly fragile in this regard thanks to the complicated maze of dependencies and sub dependencies and flavour of the month framework syndrome

iamsaitam

4 days ago

At first I thought it would be a decade old project, but 4 years isn't old by any standards is it?

Anyways, npm ci should have been the first attempt, not npm install so that it installs the same package versions defined in the package-lock.json. Then as others have mentioned, pin your node versions. If you're afraid of this happening again, npm pack is your friend.

In the end, op could have done a bit more. BUT I'll give it to him that when bindings are involved, these things take more time than they should

tacone

2 days ago

My take is one should be especially wary of packages that depend on C libraries and need compliation. You get to be extremely bound to what the OS distribution has to offer. If that's the case, docker is probably the safest solution.

3 days ago

> nor would you generally expect your C++ project to build if you swap one compiler for a different one.

it's absolutely the expectation for C++ projects to support building on GCC, Clang and MSVC

Etheryte

3 days ago

Maybe these days this is the case, last I used C++ about a decade ago though, this was most definitely not guaranteed to be so. This thread [0] is a good quick overview of the type of issues you used to run into, and often you didn't even need anything fancy to hit those edge cases. If life has improved in the meanwhile, that's good of course.

[0] https://stackoverflow.com/q/51866968/1470607

shepherdjerred

3 days ago

People love to hate on frontend/Node

SeriousM

4 days ago

We use package.lock and docker image with local folder binding to run legacy node projects. Eg. docker run -v local:inner node:12 command

jollyllama

[deleted]

Aeolun

4 days ago

You spent only two hours on this and you think it’s too much?

Also, do not run shit on a node version that is years out of date and out of service. Also, update your damn packages. I know I sound cranky, but running anything internet facing with god knows how many vulnerabilities in is an exceedingly bad idea.

CI solves it because it proves that it can build in the pipeline, using a well defined environment.

No guessing at which node version you need or any other dependencies that may be required.