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

201–210 of 540 posts

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

#201

Post by Swalden123 »

skippyboxedhero wrote: post #162
Illotus wrote: post #31

I guess you use what you are familiar with, but using react for doc site instead of using some off the shelf static site generator/cms with caching seems like wasted effort. More fun from dev point of view with react no doubt.

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.

Gatsby is in react

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

#202

Post by pevey »

jstummbillig wrote: post #180
awestroke wrote: post #135

Earlier quoted context omitted.

Well, PHP has no client-side rendering, so it's a weird comparison

PHP has as much client-side rendering as React SSR does. I think the sleight of hand that is happening right now, and that gets people a little confused, is that React is shaping up to be this thing that handles both front and the backend where other solutions can't do that. Sure – but it does that by overloading and complicating what React once was (neither of which per-se negative, I think it's just an apt descript…

React borrowed these concepts from Solid, SvelteKit, and Remix.

Not that there’s anything wrong with that. It’s pushing things forward. (And by forward, I mean, yes, also a little backward. We had server-side dominance with php, etc., then frontend-only with Vue/React… Now we finally get to serve our cake and consume it, too.)

I sometimes hear snarky comments about the proliferation of all these frameworks. But here is the tangible benefit of that “competition.” (Really more cooperation than competition)

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

#203

Post by Chris2048 »

hnfong wrote: post #199
bsenftner wrote: post #177

Earlier quoted context omitted.

Exactly! These frameworks enable people with 6 months of "software developer" education to enter the industry and enshitificate our careers with their minimum wage level understanding of actual software engineering, dragging all of us down to their salary level.

If your career can be significantly affected by devs fresh from bootcamp, you probably need to sort out your own issues than to complain here mate.

That would assume quality is valued by an employer, versus shitt apps.

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

#204

Post by CipherThrowaway »

jmull wrote: post #191
CipherThrowaway wrote: post #165

Earlier quoted context omitted.

Maintaining VBScript sucked 100x worse than TypeScript. How would you approach SSG with Classic ASP?

You’re moving the goalposts to a whole new stadium.

Classic HN conversation here.

"The web is too complex! All these web frameworks are too complicated!"

"Okay, what do you suggest instead?"

"I'd just use [completely unmaintainable technology from the 90s that is no longer supported by its vendor]"

"Okay, how would you approach [basic feature of the web framework]?"

"Stop moving the goalposts!"

Come on, you could at least come up with some hand-waving about cache headers and CDNs.

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

#205

Post by gear54rus »

mediumsmart wrote: post #12

In server-side rendering, clients are sent HTML that they can see immediately I noticed this too. You can put a plaintext file on the server and it gets transferred to the browser pretty fast. You can also put another plaintext file ending with .css on the server and it can make things on the first page move and look really nice just because the browser knows what to do with it. It’s a neat trick but still second to…

Sure, that's what we'll do! Sounds grand!

By the way, we need to add another feature to our page, would you mind looking through that file so there are no class collisions? What do you mean its too long? 50k lines? Pfft.. But at least it 'gets transferred to the browser pretty fast'

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

#206

Post by FridgeSeal »

taurath wrote: post #159
lelanthran wrote: post #143

Earlier quoted context omitted.

Well they don't look like they were created to manage complexity either, so exactly why are they used?

To give some abstractions out of the box, mostly, so you don’t have to reinvent the wheel - the demands of a lot of websites and applications nowadays include interactivity on every level, very fast and smooth ui population, and pretty animations. Sometimes the tools are great for working in huge teams on the same codebase, sometimes it’s for giving a lot of features to a smaller team.

> the demands of a lot of websites and applications nowadays include interactivity on every level

The demands of the PM maybe, most users just want something the works and gets out of their way.

> very fast and smooth ui population

Neither of which your average JS/SPA/behemoth is actually good at.

> and pretty animations.

I’ll give you this though, JS web apps certainly do rep some pretty animations, often at the cost of thrashing my CPU and ram.

Crazy idea, but maybe, if instead of spending ages building “interactivity” we just built “applications that worked”, we might actually have less mess, and build better products.

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

#207

Post by DigitalSea »

I'm old enough to remember when servers rendered everything and you used CSS and Javascript to enhance the pages after they were rendered. The web is in such a dark and overengineered place. It's almost unbelievable. It's why my approach to building apps is server-rendered first and then enhanced after the fact.

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

#208

Post by [deleted] »

tacker2000 wrote: post #100
Scarblac wrote: post #72

Earlier quoted context omitted.

> I also am baffled by the return to server side rendering as the new thing. It’s like people forgot that’s how it used to be. People want that back, but they also like React, and their existing component libraries, and they want to generate the backend pages with React. It's not that strange. And you can (I think) pretty seamlessly have part of the page rendered on the server, and parts still function on the client.

Yea but why do I need to use React for that? Is it because these devs can only do React and nothing else, so we will shoehorn everything into it? I mean, more power to them, if they want to do it and have 10x the complexity and take 10x longer than learning and using normal, already available tools.

[deleted]

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

#209

Post by DigitalSea »

meowtimemania wrote: post #101
ytoawwhra92 wrote: post #14

It's weird how projects like Turbolinks, intercooler, and pjax just don't get acknowledged in histories like this one.

htmx has been getting tons of attention recently

HTMX is cool, but it's honestly only in the conversation because the developer has leveraged memes and garnered popularity on Twitter.

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

#210

Post by sodapopcan »

loloquwowndueo wrote: post #176
phist_mcgee wrote: post #166

Earlier quoted context omitted.

For sure. Ever had to debug a bug deep inside of a webpage's code that relied on 5-10 preconditions to get it to appear? Without HMR, you're spending a lot of time F5ing and navigating to reproduce/fix it.

If only there was a way to programmatically reproduce the conditions under which the problem appears and then exercise the behaviour that triggers the bug. Then some code could verify whether the problem still appears. Once the problem is fixed this same “test” dark magic could help ensure the problem does not occur again. Pipe dreams, my friends. Pipe dreams.

“That’s just not, like, how my brain works, man. I have a different development ‘style’, ok?”
Post reply on HN