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

21–30 of 78 posts

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

#21

Post by madeofpalk »

eyelidlessness wrote: post #16

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.

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

#22

Post by lucidone »

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 forth). These were aptly named "onComponentThing"s and grokable.

Hooks, and particularly useEffect, ruined it for me. I have given up trying to understand why changing button states or presenting modals has become so obtuse and frustrating. I don't care about updating my react-router and rewriting it again for the third or fourth or whatever time. I don't want another new testing library, another new "best practice", or another repeated mistake in the reinventing-the-wheel-cycle the React community seems obsessed with.

It's all so exhausting. I write Rails now with erb templates and some dumb javascript to toggle modals and change button colours. It's not cool but at least I can understand it six months later.

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

#23

Post by bob1029 »

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? These approaches are easily more productive than anything that has come out over the last 5 years. All the excuses for why this won't work are almost certainly traceable back to ego/resume-driven development pressure rather than actual technical justifications.

Bookmarking MDN and literally treating it like the web bible is the solution for most of this. You don't need a JS framework. You don't need a CSS framework. Definitely not as of 2023. Between big wins like grid & flexbox, I can't think of anything I absolutely need to vendor out anymore.

Once you take the training wheels off and fall a few times, you will learn that this stuff isn't that scary. You can actually write javascript like "document.getElementById" and retain ownership over your soul. The next step is convincing your teammates of the same and then deciding upon some common patterns to follow that make it easier to collaborate. Put differently, let the frameworks evolve naturally over time. Don't force them in from the beginning.

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

#24

Post by athesyn »

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.

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

#25

Post by athesyn »

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.

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

#26

Post by AgentME »

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'm not sure you understand what React Server Components are if you think server-side web forms with only the necessary client-side JS is in opposition of it instead of being exactly what it's about.

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

#27

Post by diob »

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, coding is just a joy for me these days.

Maybe I'm happy because I'm not jumping to each new framework trying to micro improve things, but honestly I'm not sure.

Coding the frontend in 2023 compared to 2013 feels like a piece of cake.

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

#28

Post by bob1029 »

AgentME wrote: post #26
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'm not sure you understand what React Server Components are if you think server-side web forms with only the necessary client-side JS is in opposition of it instead of being exactly what it's about.

> I'm not sure you understand what React Server Components are

Not in depth, but that's kind of my point. I don't really need to anymore.

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

#29

Post by diob »

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.

Yeah, I jumped ship from Marionette / Backbone when hooks came around, they finally got me to go "wow, that's way way better".

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

#30

Post by chrisco255 »

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 worked on an enterprise stack that started as ASP.net web forms, with C# used instead of PHP (this is not a C# vs PHP debate, the core problems exist no matter what backend form stack you use). The app was created in early 00s and by the early 10s, it was hundreds of pages. While everyone thought our application was mostly a C# app, by 2013 or so, we actually had more lines of JS than C#. Every time a dev needed to add some dynamic behavior to the site, they would import Jquery, or Jquery UI, add a plugin or few, add some inline JS on a CSHTML file, add a css file, etc etc. Eventually the entropy of that sort of thinking, of treating JS as a second class after thought, as like something you can casually inject or bang out on a per page basis, cost us a great deal on product momentum, refactoring, modernization, mobile compatibility, and more.

Facebook itself is a PHP app. React was invented to solve similar problems for Facebook.

If you're building a basic form app and you're able to make a business out of it in 2023, by all means, use some Jquery, a dead simple form UI and go to town. But if that app starts to evolve beyond a few screens or if more dynamic behavior is required, you owe it to yourself and your team to use a proper JS framework and toolset.

Post reply on HN