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

Things I wish I knew before moving 50K lines of code to React Server Components

mux.com

Post reply on HN
Print view View original

441–450 of 540 posts

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#441

Post by satvikpendem »

Cthulhu_ wrote: post #239
skippyboxedhero wrote: post #162

Earlier quoted context omitted.

It is statically generated. The reason to use React is so you have one language across the front-end rather than having some people using React on one site, and then people using Gatsby/Hugo for something else. Next.JS can do the same thing as Gatsby/Hugo but has more features and is in React.

But you don't even need to know what language your tool is written in if all you want is a static documentation site. This is a problem a lot of people have; they think in technology instead of actual problem solving. Just look at how many projects have been posted on here with a title like "$solved_problem... in Rust!" as if Rust makes everything better forever. It's marketing bullshit. It's self-gratification. It's…

> But you don't even need to know what language your tool is written in if all you want is a static documentation site.

Not if you want interactivity in certain parts of the doc site, such as what Stripe does with API keys. It's simply easier to add JS if the entire toolchain is JS.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#442

Post by satvikpendem »

JackFr wrote: post #217
skippyboxedhero wrote: post #162

Earlier quoted context omitted.

It is statically generated. The reason to use React is so you have one language across the front-end rather than having some people using React on one site, and then people using Gatsby/Hugo for something else. Next.JS can do the same thing as Gatsby/Hugo but has more features and is in React.

[flagged]

Then what is an actually good example in your analogy? I don't see how using a static site generator is anything like smashing your fingers, seems like a common enough solution to me.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#443

Post by melx »

satvikpendem wrote: post #423
anonyfox wrote: post #422

Earlier quoted context omitted.

Thanks for sharing the Elixir love! More people should do this openly I think, since it’s still vastly underrated and fellow alchemists seem to be too humble to evangelize!

It's nice but if only it had types. After using languages like TypeScript and Rust, it's very hard to go back.

You forgot to also say Rust is faster.. if all languages were very similar there's not much point in having those.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#444

Post by satvikpendem »

ttfkam wrote: post #437
satvikpendem wrote: post #428

Earlier quoted context omitted.

As long as a framework invents their own HTML-like DSL, I'm not using it. I've used enough Vue back in the day to know I wanted to move to React where I can use actual JS, as well as get excellent TypeScript support out of the box.

> As long as a framework invents their own HTML-like DSL, I'm not using it. Okay, that's a choice. > I wanted to move to React where I can use actual JS You… uhh… know that JSX was literally invented as React's own HTML-like DSL, right? And that TypeScript is not "actual JS", right? Just food for thought: HTML can exist and provide tremendous value on the frontend without JS. JS on the frontend without HTML is… not q…

I knew this comment was coming. JSX is not the same as the DSLs of Vue and Svelte. They often have poor support for TypeScript and cannot be mapped, folded over etc, because they are not "just Javascript with syntactic sugar," they are a much more rigid DSL. Trust me, I've made a lot of Vue sites, I know what it's like to use JSX vs that kind of DSL.

Never mind that TS is a superset of "actual JS," your point doesn't even touch my argument which is that I want type safety, such as when props are missing or invalid types, and so on. Even if TS is not "actual JS," that's a semantic argument and doesn't matter as long as type safety exists. I've even written sites in Rust via Yew, works great and outputs HTML at the end of the day.

> Just food for thought: HTML can exist and provide tremendous value on the frontend without JS. JS on the frontend without HTML is… not quite as useful. Be careful about which technology you want to be the central player.

Not sure what you're talking about with this point, I never said HTML isn't useful.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#445

Post by satvikpendem »

melx wrote: post #443
satvikpendem wrote: post #423

Earlier quoted context omitted.

It's nice but if only it had types. After using languages like TypeScript and Rust, it's very hard to go back.

You forgot to also say Rust is faster.. if all languages were very similar there's not much point in having those.

That's fine, that's why I continue to use Rust and not Elixir.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#446

Post by satvikpendem »

raphaelcosta wrote: post #29

Doesn’t make any sense for me why we are now using React in the backend, to render HTML… Let’s go back to 10 years ago.

Because it's nicer than most other templating systems, and when you want to add interactivity, it's nice to have everything in one language and paradigm. Plus, static typing support.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#447

Post by satvikpendem »

CharlieDigital wrote: post #331
ttfkam wrote: post #320

Earlier quoted context omitted.

After all this time, React's sheer tonnage of boilerplate still astonishes me. That abstraction leaks like useMemo(…) even need to exist in the first place… Folks want to solve their own problems, but they keep getting saddled with React's as well.

Evan You (creator of Vue) had a great quote on this: > The pain and suffering of hooks all roots from the mismatch between a dogmatic belief in the superiority of immutability and the harsh reality of the host language that is JavaScript (Feb 25, 2023) This fundamental misalignment with React and JavaScript is the billion dollar mistake.

Nah, I still think React made the right choice. I used to use functional languages so coming to the JS world and seeing that no lessons from that world were learned was disheartening. React, where UI = f(state), is an amazing model compared to the imperative jQuery model of before.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#448

Post by satvikpendem »

CharlieDigital wrote: post #182
lacrimacida wrote: post #164

Earlier quoted context omitted.

Could you explain how the opt out/opt in works? Im a bit confused

Take this example: const { useState } = React; function Person(props) { console.log('Render Person'); return ( { props.identity.firstName } { props.identity.lastName } ); } function App (props) { console.log('Render Hello'); const [count, setCount] = useState(0); const einstein = { firstName: "Albert", lastName: "Einstein" }; return ( setCount(count + 1)}>Increment ); } ReactDOM.render( , document.getElementById('con…

Well yeah, it's the difference between understanding structural equality and referential equality. I always got the sense that people who can't figure out why things rerender when simply never took any classes in college on the difference (which is likely true since many bootcamp devs don't take such classes, and the vast majority of them learn the MERN stack).

The reason I moved away from Vue is precisely due to the spaghetti nature of fine-grained reactivity. It's like people learned nothing from the reactive stream days during Knockout JS. In a big enough app, the state simply becomes unwieldy and I am always grateful for the unidirectional dataflow and explicit setting of data in React.

UI = f(state), and that's how it should be. useState and other hooks seek to keep state around since at the end of the day we need to make components that perform functionality, and it really reminds me of monads in functional programming. Coming from such FP languages, React was and still is a great paradigm.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#449

Post by satvikpendem »

cookiengineer wrote: post #152
Scarbutt wrote: post #15

Earlier quoted context omitted.

Network effects, react is where the jobs are.

> Network effects, react is where the _consultancy_ jobs are. Fixed that for you. I think this is the real reason.

No? Most jobs that are direct W2 for a company are also in React that I've seen.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#450

Post by satvikpendem »

ttfkam wrote: post #350
phist_mcgee wrote: post #256

Earlier quoted context omitted.

React is orders of magnitude more embedded than jQuery ever was. On top of that, the breadth and depth of its complexity and ecosystem and the solutions it helped build means it's really not going away in a hurry. Updating a 2013 site from jQuery to Angular was small potatoes compared to updating a site now from react to react2.

Embedded? I would have used the term "infectious". Its complexity and ecosystem will be its Achilles Heel. There are no small number of examples of folks rewriting their React apps in weeks or even a weekend in something like Svelte. SolidJS is "close enough" in code patterns that folks will be very tempted to jump ship. Vue now has a JSX option. But here's the kicker: frameworks like Svelte don't need wrappers aroun…

That could've been said about Java too but it doesn't mean it doesn't stick around. Complexity is orthogonal to sticking power.
Post reply on HN