My take on the current React and Server Components controversy • Hacker News Board

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

#61

Post by sebazzz » Thu, Jul 06, 2023, 2:55 AM UTC

chrisco255 wrote: post #30

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…

> you owe it to yourself and your team to use a proper JS framework and toolset.

In 2023 JS is no longer necessary, for instance, Blazor also works fine, and works great for small teams building just LOB apps.

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

#62

Post by eyelidlessness » Thu, Jul 06, 2023, 2:57 AM UTC

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.

Okay, I’ll volunteer. Hooks solve a real problem in a really unidiomatic way that makes real code hard to understand. They put invisible function boundaries around return values and create state machines inside the body of functions which don’t correspond to the actual function body.

I could say the same thing about Solid and its reactivity, and I have. But at least with Solid you know where the magic begins: an opening JSX tag. With hooks, it’s everwhere and you can’t know where magic and non-magic share a space because it’s externalized to linters which have limited capabilities to cross module boundaries.

I don’t like any of this magic but I’ll take “it happens predictably at an angle bracket with a well defined next character” any day.

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

#63

Post by 000ooo000 » Thu, Jul 06, 2023, 3:14 AM UTC

I used React for about 5 years, pre-hooks. I thought it was good, felt productive using it (thanks MobX). I have been putting it on my resume, but I'm starting to think I should be avoiding React jobs because of this churn and grief in the ecosystem. Hooks was bad enough but RSC seems like strike 2.

Have been using Lit.js in a hobby project and I'm really enjoying it. I'm not big on how stylesheets don't penetrate the shadow DOM but otherwise it just feels like I'm back writing heyday React.

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

#64

Post by aloha2436 » Thu, Jul 06, 2023, 3:20 AM UTC

sebazzz wrote: post #61

chrisco255 wrote: post #30

Earlier quoted context omitted.

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…

> you owe it to yourself and your team to use a proper JS framework and toolset. In 2023 JS is no longer necessary, for instance, Blazor also works fine, and works great for small teams building just LOB apps.

Blazor Server and WASM both have issues that make them non-starters for me, namely latency quickly gets out of hand for the former and the latter is far too heavy. The (unfortunate?) reality is that Javascript is unavoidable if you want good bundle sizes and client-side interactivity.

I find HTMX is a better alternative if I'm trying to write as little JS as possible, I find it smooths over the latency issue better and just lets me write normal web app code that feels like a SPA to use.

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

#65

Post by chrisco255 » Thu, Jul 06, 2023, 4:05 AM UTC

sebazzz wrote: post #61

chrisco255 wrote: post #30

Earlier quoted context omitted.

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…

> you owe it to yourself and your team to use a proper JS framework and toolset. In 2023 JS is no longer necessary, for instance, Blazor also works fine, and works great for small teams building just LOB apps.

Hi, do you have an open source repo of something you've built in Blazor? Would love to check it out. While it sounds interesting, there are still numerous limitations to wasm. There's no garbage collection, I'm curious how large Blazor apps are at scale on larger code bases, I'm also curious how well that works with either a PHP or Ruby stack, for example, and how easy you find it to integrate with other frameworks outside of the Microsoft stack?

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

#66

Post by kaba0 » Thu, Jul 06, 2023, 5:58 AM UTC

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…

Hooks have been available for 4 years now. Also, take a look at the official site: https://react.dev/learn

It is literally a few pages and you can be ready to go with it. Especially that react didn’t drop backwards compatibility. I honestly don’t get all this negativity. There used to be a new framework in FE circles each month, but for several years now the churn has slowed to a halt.

Also, it literally just rerenders the state again if it changed. That’s it. There is hardly an easier model to exist.

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

#67

Post by kaba0 » Thu, Jul 06, 2023, 6:02 AM UTC

eyelidlessness wrote: post #62

athesyn wrote: post #25

Earlier quoted context omitted.

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

Okay, I’ll volunteer. Hooks solve a real problem in a really unidiomatic way that makes real code hard to understand. They put invisible function boundaries around return values and create state machines inside the body of functions which don’t correspond to the actual function body. I could say the same thing about Solid and its reactivity, and I have. But at least with Solid you know where the magic begins: an open…

The magic used by react is very limited, one just really has to look a certain way for a few function calls, as if they were declarations and not abuse it. It’s also not particularly hard to grok what’s behind the “magic” if someone is that inclined - there are frameworks with orders of magnitude more of that.

Sure, solid is better in that respect, but react couldn’t have done any other way if it wants to work without a compile-phase.

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

#68

Post by kaba0 » Thu, Jul 06, 2023, 6:08 AM UTC

shipscode wrote: post #35

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.

As mentioned elsewhere, hooks have very little criticism from any remotely experienced developer who used them, as they are simply an easier/better mental model.

It is probably also easier for that “2nd or 3rd rate dev”, unless it is a legacy project where pre-hook react is mixed with it arbitrarily (and God save us, not even the “seniors” know what to make of that)

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

#69

Post by eyelidlessness » Thu, Jul 06, 2023, 6:56 AM UTC

kaba0 wrote: post #67

eyelidlessness wrote: post #62

Earlier quoted context omitted.

Okay, I’ll volunteer. Hooks solve a real problem in a really unidiomatic way that makes real code hard to understand. They put invisible function boundaries around return values and create state machines inside the body of functions which don’t correspond to the actual function body. I could say the same thing about Solid and its reactivity, and I have. But at least with Solid you know where the magic begins: an open…

The magic used by react is very limited, one just really has to look a certain way for a few function calls, as if they were declarations and not abuse it. It’s also not particularly hard to grok what’s behind the “magic” if someone is that inclined - there are frameworks with orders of magnitude more of that. Sure, solid is better in that respect, but react couldn’t have done any other way if it wants to work withou…

Both of them have the same magic, just different variations of it. They both create artificial thunks around something, with special memoizations you haven’t defined right outside of them. React does it at the outside of a component, regardless of how the component is defined. Solid does it at the outside of the outermost angle braces of the returned JSX expression. Both are “spooky action” as the saying goes. Both are “at a distance”, but Solid can much more easily be reasoned about.

And I have no idea why people (including React team members) keep saying React doesn’t have a compiler. That’s literally the only thing that makes it not plain JS.

Edit: and the compiler isn’t as specialized as Solid’s dom-expressions, but it’s definitely not just a DSL over an otherwise equivalent function call. There are special cases for specific props, and they have similar special case rules with Solid. And that special casing has only been more true over time, some people used to write React.createElement directly, but I think approximately no one writes the new jsx(…) directly because it’s specifically intended to be a compile target.

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

#70

Post by andrewstuart » Thu, Jul 06, 2023, 7:42 AM UTC

epalm wrote: post #51

andrewstuart wrote: post #42

Earlier quoted context omitted.

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

Yeah I guess “dropped” has opposite meanings.