11–20 of 216 posts
I then save this to my NAS.
Otherwise literally everything will break.
Running an app that I wrote only 3 years ago will blow up.
> During the past 5–6 years of my JavaScript experience, every time I wanted to go back to any of my projects—from tiny to big, server-side or front-end—there was always a challenge, a problem to tackle or an obstacle to overcome before I can update or sometimes even just run my program. why i moved mostly from writing node cmd tools to using bash. don't need to go on a bunch of side missions every time i run npm ins…
npm ci is your friend.
Sure, but this friend is also changing. Suddenly now it verifies peer dependencies. Oops.
> During the past 5–6 years of my JavaScript experience, every time I wanted to go back to any of my projects—from tiny to big, server-side or front-end—there was always a challenge, a problem to tackle or an obstacle to overcome before I can update or sometimes even just run my program. why i moved mostly from writing node cmd tools to using bash. don't need to go on a bunch of side missions every time i run npm ins…
No it's not.
There's lots of dependencies and they continue to be developed.
It's not too much and its not rapid. It's just constant.
> During the past 5–6 years of my JavaScript experience, every time I wanted to go back to any of my projects—from tiny to big, server-side or front-end—there was always a challenge, a problem to tackle or an obstacle to overcome before I can update or sometimes even just run my program. why i moved mostly from writing node cmd tools to using bash. don't need to go on a bunch of side missions every time i run npm ins…
A month ago I found a bug in command line utility I wrote in C# and hadn't touched in 8 years. I checked out the project and opened it in Visual Studio. And it compiled. I fixed the bug and it just worked. End to end it took half an hour. I feel like there is an advantage to libraries and tools managed by adults with long term skin in the game.
I don't use js because it is the hot new thing, but rather because it is simple. (But I avoid messy and obscure npm repositories wherever possible for example.)
Tonight, I tried simply compiling an example super-high-profile project that recently reached 1.0 (Matter protocol impl). It took me an hour of chasing down Linux dependencies to build on my Ubuntu server, while I gave up on building on my mac altogether after comments on issues suggested sym-linking various homebrew packages around my system.
We are still new at experiencing docker-packaged projects, and there’s few heavily used tools that work well. Many big companies have solved this problem internally, but not out in the wild. HN has often discussed GUIX or NIX systems, but I’ve yet to see a “real” open source project that uses anything but make/docker or language specific tools (npm, cargo, etc).
> During the past 5–6 years of my JavaScript experience, every time I wanted to go back to any of my projects—from tiny to big, server-side or front-end—there was always a challenge, a problem to tackle or an obstacle to overcome before I can update or sometimes even just run my program. why i moved mostly from writing node cmd tools to using bash. don't need to go on a bunch of side missions every time i run npm ins…
My software in js from 7 years ago still works.
In the early 2010s, the industry was dominated by mature and stable ecosystems, such as Python/Django and Rails. Then Node came about, and when it was still extremely immature, it got a ton of attention as an army of front-end devs started to flock to it. "We are backend engineers now too!". Doesn't work that way. Node has been basically re-learning all the lessons learned a long time ago, and many lessons it didn't…
> re-learning all the lessons learned a long time ago
Because this is the same crew that sailed on the ship that sang the "over 30 is over the hills" song. In fact, wasn't our own /u/pg cheering this 'very wrong idea' of completely discounting experience on the side?
Surprise, surprise. Experience actually matters.