Live data from Hacker News

My take on the current React and Server Components controversy

phryneas.de

51–60 of 78 posts

Re: My take on the current React and Server Components controversy

#51

With the amount of bs I had to go through when they dropped Hooks, I'll never use shiny new tech from the React Team again. I'm sure there are thousands of devs who feel the same. I think the React Team will soon be faced with an Angular 2.0 style situation where they are forced to break class components, hooks, etc to get people to use new patterns. The number of people who will do it out of goodwill has had to have…

>> when they dropped Hooks What? Gotta link?

If you think they meant ‘dropped as in removed’, what I think they meant was ‘dropped as in introduced’.

Re: My take on the current React and Server Components controversy

#52
post #13

Earlier quoted context omitted.

I had a similar situation a year or two ago and since then have had several juniors complain that we're using "old tech" or missing out on the latest packages. I gave up trying to be understanding and reason with them. It just seems new developers, and especially frontend developers see a shiny new package every week and want to try it. Before we put a stop to it we were lumped with a handful of projects that were fr…

So the moral of the story is that you should be using old timers to write your code? They've seen it all and no longer are impressed by the shiny new thing. All they care about is making it work and most importantly: being productive.

Adults should be present and in charge, yes.

Re: My take on the current React and Server Components controversy

#53

Disclaimer: I’m an interested observer, but an observer nonetheless. I don’t think I’ll have a compelling reason to use RSC (or even React in any form) for anything other than curiosity in the foreseeable future. But I’ve been somewhat eagerly following the RSC evolution with eager interest out of purely academic interest in some of the problem spaces it’s meant (or could be positioned) to address. With that disclaim…

I don’t think this will cause people to drop react. I think it will cause people to just ignore this new thing and carry on like they were before.

How are they going to do that? The only way it’s conceivable is a hard fork, or something equivalent, or some very abrupt architectural and strategic changes that would seem just as disruptive to users (and much more disruptive to heavily invested partners).

I made the same prediction about hooks, but the fundamental difference is that you can ignore hooks. You can drop in basically any state/effect system and interop with components using their own, or hooks, or whatever. But you literally can’t even import existing components or call existing APIs (even hooks!) without rethinking the call stack. Parents and children are much more coupled than they used to be. Some libraries will either earnestly adopt RSC, or will make minimal necessary changes to be compatible, and propagate the problem to each of their consumers. And they, in turn, will have to choose whether to adapt to these factors within React… or without.

And again, as an observer, it doesn’t seem like that prospect is being received very well. It seems like it’s being received the same way Angular 2 was: you’re in for some large dose of pain no matter what you choose to do, and “no one ever gets fired for choosing ___” feels a lot less of a safe bet.

And unlike the Angular 2 experience, the other options are increasingly viable and mature and well received. My knowledge transfer to Solid took a few hours playing with a toy project for fun. Which is notably far less time and effort than I’d expect to spend getting up to speed with React today.

I’d be happy to be wrong, I actually want the React team to succeed on several different highly principled vectors. But at minimum I think they’re going to need to really rethink how they’re communicating this set of changes and very probably how they’re rolling them out.

Re: My take on the current React and Server Components controversy

#54

Front end development doesn't have to be awful, particularly with how much JavaScript the language has improved alongside browser APIs. React made sense at one point because the abstractions it employed were common in other contexts: lifecycle events (intentionally avoiding the "hook" word here) are present pretty much everywhere in programming abstractions (on initialization, on deinitialization, on update, and so f…

I'm in the same boat. Redux + Pre-Hook React was very legible & straightforward... Post hooks React is strong on theory but weak on substance, and I've gone to just jQuery and Python for my latest project. I did migrate my last project the barebones JS MVP -> React and regretted it immensely. It took about a month and didn't provide enough value to make it worth it.

Complex Higher Order Components are some of the least readable and least straightforward code I've ever been exposed to.

Re: My take on the current React and Server Components controversy

#56
post #25

IMO React started going off the rails when they introduced hooks. The number of concepts you needed to learn started growing, and the old intuitiveness of React began to go away. On top of that, there was a mad rush throughout the ecosystem to implement them, many times poorly, leading to more confusion. RSC seems to be history repeating itself.

Hooks solved a real problem and I have not heard a single experienced React developer say a negative thing about them.

I've used react daily since the early days. I like hooks but I don't really know what the _real_ problem was that they solved. Getting rid of class components?

Re: My take on the current React and Server Components controversy

#57
post #7

Reading this makes me think I guessed the right way going “all-in” on Remix vs Next. It was a guess, but it’s just so much more intuitive and web standards friendly, serverless friendly, browser friendly…

Yea, I've been using both and really like the direction of remix. Why did react become so intertwined with nextjs and obsessed with ssr? I wish react stayed focused as a light spa library we all learned and loved and let the ssr frameworks do their own thing.

Re: My take on the current React and Server Components controversy

#58

It's disappointing the focus React has on server side. I feel like the project should have reorganised into the React Client project and the React Server Side project.

I share the same sentiment. I don't like this "in bed with nextjs" and obsessed with server-side thing. Server rendered apps have their place, but so do spas. Let the spa haters hate. You can make great, performant apps with strictly client side rendering. For some applications, it's the best choice.

Re: My take on the current React and Server Components controversy

#59
post #47

(I'm on the Next.js team) I appreciate Lenz's feedback and writing all of this down. I can empathize with how they and other library maintainers are feeling. There's more we can do on the Next.js side to help ease the transition (and this feedback will help us there, so thank you). One point of confusion in the community has been around client components. If server components are new and exciting, does that mean clie…

Today when creating a new next app, you get this:

> Would you like to use App Router? (recommended)

It seems like users shouldn't yet be funnelled by default into using RSC.

Re: My take on the current React and Server Components controversy

#60
post #23

How many of us are working on web applications that legitimately cannot be served as basic, server-side web forms with JS only as necessary for dynamic client-side UI (e.g. disabling buttons upon form submit)? How are things like SPA improving the end user's experience and/or adding value to the product? If you are struggling and want a no-bullshit stack, why not PHP or string interpolation in your favorite language?…

The point of using frameworks is to take advantage of complex code written by others that’s also well tested. This makes implementing common tasks faster, simpler, and less error prone.

I have a webpage for my wife that has one form to submit they sends an email to her. I used plain JS. It took longer than I thought to implement because I had to reinvent the wheel, so to speak. I had to write everything from scratch.

For a business where the website is changing frequently with many developers, being able to leverage a plethora of existing code and solutions is very helpful.

Heck, even for people writing plain JS, I bet you find yourself writing helper functions and small libraries to DRY you code and make common things easier. Framework invented!

Post reply on HN