[wtf242]

It's insane how toxic the js environment is. it seems like if a project is over 6 months old, nothing will work. When I yarn install on an old project, i'm rolling the dice. I had a 2 year old next.js side project i was working on and the amount of work to make it work the latest version with just updating the dependencies and reading the upgrade docs were infinitely more complex than just starting over from scratch.

no thanks. I will stick with Rails.

[john2x]

The funny thing is that they eventually circled back to server-side rendering. It just has a cool TLA now.

[yen223]

React's server components is pretty fundamentally different from how something like Rails or old-school PHP does "server-side rendering".

It's a lot closer in spirit to something like Phoenix LiveWire.

[FriedrichN]

Just the fact that Yarn seems to be the dominant package manager now when it seems like last week it was npm. What will it be next week?

I truly wonder, do people use this stuff for software that is expected to be maintained for 5-10 years? I feel that with the speed at which everything changes, gets deprecated, discontinued, succeeded, etc. you'll spend a good chunk of your time staying up to date with the current js ecosystem. That doesn't seem very economic to me.

[colordrops]

Naw it's back to npm

[anonzzzies]

Pnpm ? Seems every week another flavour without any benefits.

[tentacleuno]

PNPM isn't exactly new; it's been in development since 2016[0] (which makes it 9 years old).

I've been using it for quite a while now. It has excellent mono-repo features, pnpmfile.js hooks, and it's just downright faster than NPM. Way, way faster.

I switched to it a couple of years ago, and it was definitely a breath of fresh air: no more waiting for 5 minutes for dependencies to install! I still find this to be the case when the odd create-XXX-app script finds itself using NPM.

[0]: https://github.com/pnpm/pnpm/commits/main/?after=5d1ed94e6c4...

[fire_lake]

pnpm has some advantages

[true_religion]

I have used yarn since 2018. It was developed in 2016.

What does dominant even mean in such a short term context? It hasn’t even been 10 years.

As far as companies go, we move so slowly that when someone brings up a tech fad, the fad is gone by the time the committee actually gets to decide. So we stick with the status quo.

[rjh29]

Basically npm fell heavily behind in development so people switched to yarn; it's back to npm now. This is over a timescale of 10 years or so.

[dudus]

I'm one of "those".

I'm using bun now, but I was on pnpm for a while.

[azangru]

To be fair to React itself, it evolves quite slowly and cautiously. It is almost the same now as it was in 2019. But the closer your stack is to the native browser apis, the more robust and long-living it will be, which is why I have faith in Lit.

[mu53]

Likely you are changing your node version during that 6 months. Similar to ruby with RVM, node has NVM. I create an .nvmrc file denoting the desired node version, and it works reliably all the time.

[interstice]

To be fair I’ve had similar issues with Rails

[thibaut_barrere]

In that regard, my experience has been the following churn scale:

JavaScript churns more than Rails which churns more than Elixir/Phoenix.

I believe this is caused by “how sound the fundamentals are” (technical debt in the language itself and its stdlib).

[creshal]

PHP devs meanwhile: You guys churn?

For better or worse, you can take 10+ years old PHP code and it'll mostly just work.

[rjh29]

I wrote a bookmark manager in 2005-ish using security-conscious PHP, and it still works great.

I rewrote it in React for fun and not only is it totally out of date, but Github's dependabot has sent me probably 200+ security advisories based on its dependencies.

[lakomen]

My handcrafted legacy.c64g.com site made in 2005 still works with php8.3 (I see I have to renew the cert). I just had to switch from mysql to mysqli. However my Symfony sites had to be rewritten. Friends don't let friends code using Symfony. There was no upgrade path. Deprecated components with no replacement. I was so fed up with all the bullshit from 2010-2013 with the OO fetishism the "treat PHP like it's Java" from fresh students and graduates that I had to abandon it and switch to Go, which gave me peace of mind and a factor 100 performance boost.

[kalleboo]

I maintain a PHP codebase that dates back 15 years and I can count the breaking changes on one hand, and they were all tiny one-line changes

[thibaut_barrere]

The backward incompatibility story https://www.php.net/manual/en/migration70.incompatible.php is not empty

[motogpjimbo]

In 10+ years of professional PHP development, the only time I've ever had to fix a codebase while updating the PHP version was when mcrypt was deprecated, and it was only around half an hour of work to replace it with a modern equivalent, including the time to re-encrypt the data.

Meanwhile, I've had the misfortune of inheriting a React application that would no longer build a mere six months after the original developer left the company. I've come to loath working on React projects due to the insane amount of library and tooling churn in that ecosystem.

[thibaut_barrere]

Not contesting anything related to churn and JavaScript, my experience has been similar.

Glad to hear those changes did not impact you re PHP

[creshal]

That was in 2015, and it barely impacted anything I touched. So, granted, technically not quite 10+ years, but you get worse churn in JS frameworks over an 8 months period. (Unless it's jquery.)

[therealunreal]

That's not it. The core issue is AAA sites vs apps. Let me explain.

Public sites need to load quickly and use progressive enhancement, work without JavaScript even. Next.js is driving this with server side rendering and hybrid approaches. They've done a great job so far.

Then there are applications that have a browser UI. These typically use a JSON-based API (REST, RPC, or GraphQL doesn't matter). These apps don't require server side rendering and their API backend can be anything.

In the latter model, you just host a bunch of static assets and point them to your API. No need for compute, everything is done client side (except API operations of course).

In the first model, you need to pay for rendering and it guides you into doing the API the same way. Closer to older PHP/ASP sites but on steroids.

This move caters to Next.js. IMO, as a lot of recent developments do.

[varunnrao]

The issue really rears its head when we consider that most are in the second category but "modern" frameworks like Next.JS don't really cater to that market.

I used React for a long time to build frontends for my REST APIs. When I started, CRA was the standard to get started with. CRA got deprecated and I wanted to shift to Next.JS since that seems to be a little more full-stack and I wanted built-in routing instead of relying on react-router. Once I got going on Next.JS everything turned out to be connected to Vercel. Even the tutorial at one stage expects you to sign up for a Vercel account. This really turned me off of React because there doesn't appear to be a single framework for people who want to build the latter category of web apps without either a) tying together multiple disparate modules/libs or b) signing up with 1 framework with 1 vendor. Either option doesn't appeal to me.

I shifted over to Angular (despite everything) because it seems to have finally stabilized and has a pretty good feature set for what I'm looking for. Plus build times on Amplify have really come down. Build times for similar sized apps take around 4 minutes(!) for React applications and routinely under and about 1 minute for Angular applications. I honestly just want a frontend framework where I can build a foundation fairly quickly and just get on with building features instead of worrying about if dependencies have suddenly been sunset or if the author made some breaking change to some key library I don't even interact with directly and right now this is Angular.

[lakomen]

> want a frontend framework where I can build a foundation fairly quickly

Vue with Quasar has been that for me. And previously Vuex-orm, now Pinia-orm. With a RESTful backend.

However lately I've been using React because of a graphql backend (I hate graphql) and it's a relay type graphql and the frontend relay library only works with React.

React itself is pretty easy to pick up. But Relay is a pain in the ass. Fragments, @arguments, @argumentsdefinitions, the naming is a super pain in the ass. And it's even more of a pain with Typescript and doesn't work with Javascript. Reusing queries is not possible because of the naming requirements. You can't just have a PostFragment, no you need to have a MainPagePostsFragment and a ProfilePagePostFragment and a PostDetailPagePostFragment etc. But I digress.

React has been surprisingly cute so far. But I've also just been with it for 1 version only, 18. I could imagine switching to it because of the ecosystem and because most frontend jobs are React jobs. You can easily embed it into for instance static HTML files, unlike Angular or Vue, keyword easily.

Angular syntax is beautiful, but the framework is too time consuming. I have recreated a real-time forum, which took about 3 years to build with Angular in 2 weeks with Vue.

Bottom line, Vue, for me, is the most productive framework. Angular, Vue and React are all very similar. Svelte is a bit alien, because of its state management and kit being the nextjs equivalent, but apparently the fastest because of the compiler.

[phantomathkg]

Sorry to ask, but what classified as AAA site?

[hagbard_c]

https://aaa.com/ comes to mind...

[anonzzzies]

I had the same issues with rails, although that’s a while ago; not sure if it improved.

[JakaJancar]

I've adopted the practice of avoiding libraries with major version > ~3. If you needed to re-design your API so many times, I don't trust your judgement enough to build on top of it.

That said, I still use React and... it's at 19.x :'(

[magnio]

React jumped from v0.14 to v15.0, so in reality it's more like major version 4.3 right now.

[JakaJancar]

Ah, cool, didn't know - joined the train late.

[lakomen]

Yeah but that's not just a React issue. It's even worse for Angular, but Vue's transition from v2 to v3 was pretty smooth because of backward compatibility. Svelte has no supported way to create a SPA anymore, you'd have to use Vite for that. It's SSR like next.js. Terrible.

But Angular is the worst in terms of backward compatibility and it has the worst state management too. It's like they took everything bad from React and made it a standard.