[indymike]

After building two companies with Python, and then one with Javascript, I can see a huge difference. With Python, you get a predictable development velocity. With Javascript, there's lots of unpredictability (this is rapidly improving) because of thrash in the ecosystem. It's hard to overstate the value of predictable timelines and predictable development velocity when building a business.

[technics256]

Curious where in javascript you saw a lot of unpredictability?

[lmeyerov]

Maintaining JS is a treadmill on fast: takes a lot of work to stand in place, which is horrible if you are trying to get anywhere.

We have been ripping out node bc basic backend frameworks are too small and mercurial, so breaking API changes every year on simple things like making an HTTP request has meant a lot of time not spent on our users. The ROI is often ultimately miniscule perf, and ironically, CVE fixes from such a cowboy culture. (We are also ripping out node bc current inability to work with data ecosystem well + shitshow that is build times / maintaining them.)

Frontend has been getting better. Part of that is we have largely stopped adding any dependencies and been chiseling down to react + a few components, and between them + the webpack team, focusing on the few teams we trust to respect end user code more than they value whatever feature idea that month.

I spent years on making JS better and we have built stuff to make it sing, so bittersweet business decision driven more by the unmaintainable code culture than the language (npm/node are growing up, V8 is amazing, React achieved a lot of what early framework people marched for, ... ).

EDIT 1: Part of the technical problem may be around npm <> semvar and in turn, the dev culture around it. Dutifully updating semvars upon breaking changes may have given a false sense of being friendly for maintenance. Major upgrades are still necessary in practice due to peer dependency requirements triggered by CVEs etc. It's ~awesome to now see breaking changes in better modules. However, having to do via searching github stinks, and horrifying how many there are. This is still a far cry from not consistently breaking everywhere, gofmt, etc.

EDIT 2: I don't blame OSS devs for hobby projects unrelated to their work and with no claims of aiming for prod ready / corp use. But as soon as we get to core node infra teams and their VC sponsors causing a bait-and-switch on infra focus, or tech leads at unicorns & bigco's doing their here today / gone tomorrow thing, etc., I get heart pain around adding any dependencies around this broken tech<>social ecosystem.

[jonnytran]

In the JS world, this is why Ember is so awesome. People criticize it for including everything and the kitchen sink, but most frontend apps that go anywhere actually need all that. And Ember guarantees that it all works together, with a clear upgrade path.

[kevan]

An example of this from my experience: I was working on a side project and ended up doing 2 major version upgrades on a core JS library (maybe routing?) before I even completed the MVP. Definitely not what I wanted to spend my time on at that point.

[otoburb]

I believe Deno links to dependencies directly so that you can still rely on old(er) versions, but not sure it would have helped in this case.