Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My take on the current React and Server Components controversy

phryneas.de

Post reply on HN
Print view View original

31–40 of 78 posts

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

#31

Post by chrisco255 »

diob wrote: post #27
bob1029 wrote: 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?…

I would say the app I work on falls into the need for SPA, so I naturally love React. Hooks are where I actually jumped to React, from Marionette / Backbone and it's been love for me ever since. I don't do CSS in JS stuff, I stick to Tailwind for my needs there, so I guess we're in agreement on that. But I'm so crazy fast in React + Tailwind that I really don't understand the frustration. Combined with Typescript, co…

Do you use next.js as well or just client side react?

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

#32

Post by shipscode »

lucidone wrote: post #22

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.

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

#34

Post by calderwoodra »

athesyn wrote: post #25
shaunpersad wrote: post #15

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.

Totally agree. I've been developing with React for a couple years and before that I was an Android developer for about a decade. React is such a breeze to use compared to the complexity that goes into developing with other frontend frameworks.

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

#35

Post by shipscode »

madeofpalk wrote: post #14

In the past few years I think the ‘JavaScript community’ (whoever that is) has done a decent job at dispelling the reputation of ‘silly js devs, making a new framework every other week that you have to learn’. This React Server Components seems to be a bunch of effort on throwing all that good will down the drain. It seems like they’re really excited about this new API and the react and nextjs teams have just charged…

Sounds like the initial hooks launch. A lot of goodwill was used up with that. It might look fine behind the desk at Meta on the React team, but on the ground on real world 2nd and 3rd rate dev teams the damage has been immense. You have entire teams of devs that can't understand useEffect for 2-3 years.. can't say that about pre-hook React.

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

#36

Post by zaphirplane »

esskay wrote: post #13
mmmeff wrote: post #4

I had a junior on my team propose we switch our year old project to Next’s app router. After telling him no, I became concerned that I was becoming all the lead developers I’ve worked with in the past that shut me down and, at the time, seemed to be holding back innovation on our team. I get it now. I totally get it.

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…

The thing is a library usually advertises how they address a painful experience in other projects. That is the hello world fallacy, there is a blog about it.

Basically you see how elegant or easy to do X in a new library but you don’t see how complicated it is to do Y. Y is complex in the new library and simple in your existing library

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

#37

Post by shipscode »

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 been diminished to a minority percentage of React enthusiasts.

Personally, I just rock jQuery for my personal projects. I get the same dollar coming over the wire with a way faster time to live and reduced complexity.

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

#38

Post by recursive »

bob1029 wrote: 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?…

I generally agree with your overall philosophy. But I have one disagreement. String interpolation is subject to XSS, when used to generate HTML. Yes, it's possible to sanitize and escape, but you have to remember to do it every time.

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

#39

Post by ovao »

athesyn wrote: post #24
mmmeff wrote: post #4

I had a junior on my team propose we switch our year old project to Next’s app router. After telling him no, I became concerned that I was becoming all the lead developers I’ve worked with in the past that shut me down and, at the time, seemed to be holding back innovation on our team. I get it now. I totally get it.

>I had a junior on my team propose we switch our year old project to Next’s app router. that doesn't sound like a big change.

It’s quite a big change, depending on how many routes are in play. Migrating to App Router is non-trivial.

Thankfully, the pages directory model is still just fine, so there’s no immense pressure for existing apps to migrate, and it can be done somewhat incrementally.

Post reply on HN