[nikanj]

I find it fascinating how frequently the best practices change, and how dogmatically people still want to follow best practices. As an industry, we spend absolutely incredible amounts of work refactoring working code into the new paradigm.

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

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

[rimliu]

I have a harsher take, 95% where react is used it is used without the need.

[000ooo000]

The minimum technology required to solve a problem isn't always the same technology that a team has experience with, has existing projects/code in, can readily hire for, etc. Nor is it necessarily the same technology capable of solving future problems. Besides, some people just like the mental model of some tools and enjoy working in that way. The idea that we have to pick the minimum tooling every single time usually seems like flawed thinking based on that out-of-context Tim Berners-Lee quote.

[tmountain]

Prior to React, most developers just invented a strategy for structuring code on the client side. What’s your preferred alternative?

[Varriount]

React isn't a way of structuring code though. It's a whole (huge) framework dedicating to making web apps/pages. And most of the time it seems to be used to replicate functionality that the browser can already natively do (for example, navigating to another page).

You want a good example of how a non-react website and its code might be structured, look at GitHub. At least from a user perspective, I've never had a problem using the back button or ctrl-clicking links while navigating GitHub - which is not something I can say of most other React and heavy-js websites.

[000ooo000]

>replicate functionality that the browser can already natively do

That's.. basically every lib. Welcome to abstractions.

[rjh29]

This used to be confined to web dev, and my backend job was happily tinkering away at 15+ year old code written in stable languages and frameworks, deployed via RPM/Puppet. But we took on too many graduates and now suddenly everything is being rewritten in new languages and we have an insane amount of Kubernetes config attached to everything.

[ibash]

Class components was the last good react idea.

[oaxacaoaxaca]

I miss class components!

(I know we _can_ use them still but it's hard to convince teams of people to stick with them and ignore what the docs say are best practices for the last five years.)

[teitoklien]

Functional Components are 10x easier and cleaner to use in React

[fire_lake]

Functional Components are not functional in the sense of functional programming. They are shared mutable state.

[patates]

Function-based components. They have vaguely functional aspects but they are not functional indeed. I think most people say functional because "function-based" is too long.

[lastdong]

If I recall correctly we have stateless functional components (not managing any state). Functional in React should mean immutable state.

[akritrime]

You could already use functional components before. The main issue with React now is all these hooks and effects.

[crooked-v]

The whole point of hooks is to substantially simplify "effects stuff", as compared to the total uncomposability of class components.

While the specific implementation of hooks has its bugbears, I think it's pretty telling that nobody else is using class components either, even in projects with fundamentally different engines like Svelte.

[azangru]

> as compared to the total uncomposability of class components

How do you mean? React components were composable from the get-go; this is practically the definition of a component: you take a piece of ui, you encapsulate it in a component, and then you can compose it with other components into more complex UIs.

Class components were reacting to component's life cycle as opposed to hooks that react to data changes; but there was nothing stopping you from extracting reusable pieces of logic into standalone functions and using them in lifecycle methods.

I thought the whole point of hooks was to support the React fiber architecture, because closures are immutable as opposed to class fields.

[cageface]

Hooks make it easy to compose logic and effects. The actual implementation has some serious warts but the fundamental idea is great.

The React compiler looks like it will eliminate a lot of the error prone manual dependency tracking that usually trips people up with hooks.

[thomasfromcdnjs]

I didn't like hooks from the get go because it was the first time I found the automagical behavior that web dev was somewhat leaving behind starting to creep back in.

It's insanely hard (nigh impossible?) to debug an aging app that has use useEffect's and useState's everywhere. (This wasn't the case with the class components (not suggesting that class components were the be and end all))

Now the Compiler sounds nice, and sure there is going to be a lot less code. But, at what cost, it does sound like it's just more magic, moved further and further into the React internals. Which I think unfortunately gives the developer less understanding and power.

I'm just ranting, it's not like the React lib itself is yet entirely divorced from it's principles circa half a decade ago, but I fear it may. Perhaps, they could promote and support more sub packages of React itself e.g. rendering, state

[mouzogu]

"move fast and break things" as zuckerborg himself said

most of the js ecosystem is made of stream of consciousness kludge that is constantly being "refactored" and "deprecated"

effing tiresome as hell dealing with that sh-t...and this mentality seems to have seeped entirely into nu-dev as i see it also in other ecos now

[lakomen]

And just what does a former PHP dev know about anything