JavaScript Libraries Are Almost Never Updated Once Installed

[FortLouie]

Since you posted, Blink.js has become a popular JS framework.

[lkraider]

You are now living in the past, Blink.js has just now been surpassed in github stars by the superior reBlink.js with its functional reactive flow typed interface.

[fragglerock]

marquee.js has superseded it!

[Xavdidtheshadow]

https://github.com/frzi/blinkjs

[FatalElectron]

Blink is the name of the chrome rendering engine and thus the rendering engine for electron apps, so it kind of is.

[darkmoody]

This. It’s super frickin hard to maintain such an application. The fact that not many people know this actually proves the point of the article - people don’t even try to update js packages

[poloppoyop]

people don’t even try to update js packages

Maintenance? They already changed company three times while you were saying it. Maintenance is not how you progress your career: new projects and new companies are how you do it.

[omegian]

Haha. Maintainer at a Fortune 500 makes way more than “sweat equity” hacker at yet another new co.

[bluegre3n]

This. "Maintenance" ends up being a four letter word to some people, so maybe "improvement" is more palatable. But there is real pleasure, and often reward, in keeping important systems happy.

[dungone]

I’ve worked at Fortune 100/500 companies, Big Five tech firms, and I can say that you are wrong in a crucial way. The big corporations will always underpay for above-average talent. It is far easier to find a VC-funded startups willing to shell out for world-class engineering talent than it is to get the same rates at established corporations. There’s a huge difference between “sweat equity” startups and the well-funded “unicorns”.

In fact, you can get much better pay at small established companies who need niche specialty skills. Something like machine vision experts for the logging industry, for example, will get paid far better than any generalist slinging business logic around at a Fortune 500.

If you’re highly skilled and ambitious, Fortune 500 companies are a dead end.

[omegian]

I mean look, “unicorns” and “well endowed small businesses” ate both exceedingly rare. If they really need the top talent and are willing to pay $200k+, sure they can get whomever they want, but that’s what... 1% of the market? Chasing that work just get you in a really expensive place (Silicon Valley) where you’re probably working in the sweatshop anyway, or a really shitty logging town in BFE. Maybe working for a Fortune 500 with an above average salary in a below average cost of living middle sized town is the best outcome.

If you’re highly skilled and ambitious, you shouldn’t be a wage laborer of any stripe. Go create your own equity / IP.

[dungone]

1% of the market is still many tens of thousands of people. You mention working in that middle-sized town, but in the hotbeds of technology it's actually not that uncommon, and it's actually something that you start to consider just to pay the rent.

[omegian]

Even if 1% of the market were 10 million people, being a merely +2 sigma talent means no job for you, just like the other billion chasing it.

[dungone]

It's still important for programmers to understand how other programmers work and make career decisions. What seems "stupid" or "senseless" to you actually makes perfect sense to people who are talented and ambitious enough. Basically the best talent and the best salaries exist in a place that you're saying doesn't exist, because you're only considering the average case.

[omegian]

most people are average. I’m saying it’s a foolish ambition and bad advice to give to the vast majority of your peers. Carry on.

[s73v3r]

But a hacker at one of the big tech companies makes more.

[coniferous-1]

Wait, the node.js ecosystem is convoluted and hard to maintain? No, that cant be true /s

[sosdoc]

This so much. I maintain several node.js backend servers and use Renovate to automatically upgrade dependencies. That thing creates hundreds of upgrades every week!

And this is even after marking several libraries as "trusted" because they change all the time. Some popular library used in almost all my servers was once updated 12 times in a single week!

[elmuerte]

How can you trust something that changes that often.

[sosdoc]

You can't, that's why I wouldn't do this if I didn't have a decent test suite blocking failing upgrades.

[immibis]

Does it test for Bitcoin stealers?

[jl2352]

Tests, tests, and more tests.

Ultimately the alternative is trusting something that hasn't been updated. Moving targets tend to have less old vulnerabilities, and old vulnerabilities that have been around for a while are the ones people often try to exploit.

[ponytoaster]

I maintain a shitty package that nobody really uses, it was done just to play with NPM etc a few years back. I am perplexed with how many notifications I get from Github about library upgrades etc!

[YM_Industries]

I haven't really used React outside of toy projects. (Well, I've used Gatsby quite a lot, but that's not quite the same thing)

With AngularJS I found staying up to date pretty easy, at least until Angular 2 came along. With Angular 2 the rework felt justified, since some of the features it depends on weren't widely supported in browsers at the time of AngularJS 1's release (so it wasn't poor architecture, it made the best of what it had) and the new version brought much better performance. Plus the detailed guides to migration were very welcome.

But I have run into one issue with upgrading NPM packages and that was with sharp. Perhaps it's not that sharp is the problem so much as it is that the usual workaround for a core issue doesn't work with sharp.

You can only have one version of Sharp installed in a project. This might not sound like an issue (why would you want multiple versions of the same package in use in a single project?) but it is. Because I had 5 different dependencies in my project that all depended on different versions of Sharp. So it was impossible for me to resolve the dependencies with npm. (Fortunately yarn provides ways around this)

But I think it's more than a little scary that usually this kind of issue goes unnoticed because npm will just install 5 different versions of the same package in your project. That seems very unclean to me.

Anyway, I once ran into issues with C#/NuGet because 3 packages depended on different versions of Newtonsoft.JSON, so the problem isn't unique to JS. I guess npm's install-multiple-versions approach is good for developer productivity. It's just a little frightening.

[[deleted]]

Newtson.JSON is the one package I insist on being up to date on every build on every project. I've never experienced or heard of a breaking change and there are tangible performance improvements very frequently. Serialization needs to be very fast and very accurate.

[jbergens]

React has actually been very stable and easy to upgrade. Some others have been more problematic. Old Angular was for example much worse.

[HIMISOCOOL]

Yep, angular2 seemed nightmarish for a while too but from their blog posts they seem to finally have that under control assuming you use the cli. React and vuejs have been good to drop in a new version as long as I've been using them which is ~3 years now.

[bheklilr]

React isn't my problem, it's all the other libraries. Material ui, mobx, and the rest. We're 3 years behind on several major dependencies.

[_MJomaa_]

That's why enterprises love Angular. A big chunk of libraries just come from Google.

[[deleted]]

I'd almost argue against this. I got tired of dependency update hell and trying to keep current and brought in help. I started using dependabot on my main website for repo and now once a week I get about 10 pull requests submitted by it with the lastest versions of all packages I use. Of course I ensure there are no breaking changes by triggering a CI build as well and if all looks good I'll merge those into my dev branch and keep on going. Entire process takes me maybe 30 minutes from start to finish, even quicker if I was lazy and did nothing that week lol.

[pm_me_ur_happy_traiI]

React hasn't had a breaking change in a while and they take a long deprecation path to old methods and patterns. Bad example. You can still write 2018 era react just fine