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

491–500 of 540 posts

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

#491

Post by rco8786 »

chasd00 wrote: post #398
rco8786 wrote: post #285

Word count: complex: 9 complicated: 2 I've tried Nextjs's app router, and server/client components, and there are more footguns and gotchas than you can shake a stick at. Maybe it'll get smoothed out over time, but right now it is downright HARD to keep the mental model of your app when server and client code is constantly being intermingled, imported, and exported back and forth to each other.

I'm advising a NextJS team now and acting as a liaison to a system they're integrating with. Even the devs in the NextJS code every day get confused about what's running on the server and what's running on the client and the consequences of both. I can see the attractiveness to a setup like this. Back when I was much more involved in actually typing out code it was always a pain to switch mentally from backend side c…

> the supposed advantage of having one language for both backend and frontend

Agreed that switching languages isn’t an issue. But being able to share code between backend and frontend is a pretty nice bonus

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

#492

Post by CuriouslyC »

Draiken wrote: post #487
Ambolia wrote: post #481

Earlier quoted context omitted.

>99% of apps are basic CRUD apps You run into the edges of pure HTML forms on day 1 of the project if you have to listen to any feedback or requests from the users.

So because a few forms need validations you turn your whole application into a JS hellhole? That's the crux of the issue. It's not that JS isn't needed and small pieces of interactivity aren't nice. But we chose to turn everything into JS despite only really needing it for very small pieces of the app. Back a few years I'd have small JS bundles included in specific pages that needed interactivity. Later people frowne…

You can absolutely render react components into non-root nodes to inject interactivity into static sites. It's a good approach if you're serving a bunch of static content and you want a calculator or interactive visualization, for example.

The point at which you should consider a SPA is when you are sharing data between most of the "pages" in your app, and there are multiple data sources surfaced in any given "page." In this case, you're going to have to jump through indexdb/localstorage hoops just to avoid losing that data on every page transition, dehydrating/rehydrating multiple types of records then passing them around via a context or somesuch. In that case you're on the hook for complexity either way, but the SPA version performs better at the cost of some SEO.

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

#493

Post by solardev »

satvikpendem wrote: post #426
layer8 wrote: post #347

Earlier quoted context omitted.

The problem is that browsers started out as hypertext clients and unwittingly evolved into application platforms to implement, among other things, custom hypertext clients in it. Somehow “lets add more features to make hypertext more capable” turned into “you’re on your own now to implement a usable application with this big incoherent pile of impedance-mismatched features”.

You might be interested in this article by the creator of the HTML5 spec: https://news.ycombinator.com/item?id=34612696 He talks about using WASM for applications and HTML/CSS/JS for basic websites.

The article link (not yours, but the link to the article from your link) doesn't seem to work.

What does he suggest we do about the UI layer? Draw pixels on a canvas from WASM?

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

#494

Post by dham »

xutopia wrote: post #406
butlike wrote: post #354

Earlier quoted context omitted.

I agree for the most part. Collapsable dropdowns and jQuery drag-and-drop are nice-to-haves, but I also clearly remember the hellscape of state management in js/jQuery and I'm not to keen on going back to that.

To this day I don't understand people saying this. Can you describe a project or instance where it was tough? I never had any issues even in complicated projects with thousands of lines of JS.

Developers didn't understand event delegation, so entire codebases were filled with $.live, on and off events. If you componentized behaviors with jQuery it wasn't all that bad, although I'll admit it could get somewhat gnarly.

The problem, from what I saw was nested forms and trying to hold state on the client when the server should have been asked for the state. This lead to template duplication and trying to hold too much state on the client.

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

#495

Post by dham »

satvikpendem wrote: post #472
ttfkam wrote: post #469

Earlier quoted context omitted.

You may prefer it to jQuery's model, but that doesn't make React's model good. Try SolidJS. Similar ethos to React but far less boilerplate and performance-killing repaints. Less code is better, functional or not.

Sure it does, it is good because it's functional. I could similarly write a convoluted yet highly short Perl expression, less code is not always better. I tried Solid. Signals are not new, I've used Knockout before and it turns into a spaghetti mess after a few years. I guess people today simply aren't old enough or experienced enough to know what eventually happens with fine grained reactivity.

https://www.solidjs.com/guides/comparison#knockoutjs

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

#496

Post by satvikpendem »

solardev wrote: post #493
satvikpendem wrote: post #426

Earlier quoted context omitted.

You might be interested in this article by the creator of the HTML5 spec: https://news.ycombinator.com/item?id=34612696 He talks about using WASM for applications and HTML/CSS/JS for basic websites.

The article link (not yours, but the link to the article from your link) doesn't seem to work. What does he suggest we do about the UI layer? Draw pixels on a canvas from WASM?

Try this link: https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC...

Yes he says to use a language that compiles to WASM for the UI parts to draw pixels on the screen.

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

#497

Post by satvikpendem »

dham wrote: post #495
satvikpendem wrote: post #472

Earlier quoted context omitted.

Sure it does, it is good because it's functional. I could similarly write a convoluted yet highly short Perl expression, less code is not always better. I tried Solid. Signals are not new, I've used Knockout before and it turns into a spaghetti mess after a few years. I guess people today simply aren't old enough or experienced enough to know what eventually happens with fine grained reactivity.

https://www.solidjs.com/guides/comparison#knockoutjs

That page doesn't really answer why it can solve the issues of Knockout better. Eventually the same problems will arise, of spaghetti code among things reacting to other things reacting to yet more things.

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

#498

Post by solardev »

satvikpendem wrote: post #496
solardev wrote: post #493

Earlier quoted context omitted.

The article link (not yours, but the link to the article from your link) doesn't seem to work. What does he suggest we do about the UI layer? Draw pixels on a canvas from WASM?

Try this link: https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC... Yes he says to use a language that compiles to WASM for the UI parts to draw pixels on the screen.

Isn't this a redo of Flash and ActiveX, then?

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

#499

Post by satvikpendem »

renegade-otter wrote: post #485
satvikpendem wrote: post #432

Earlier quoted context omitted.

None of that gets to the browser.

The whole point is to have JS on front-end and beck-end, right? What is serving the JS? Isn't the server Node? And large security surface means just one compromised package is required to get on the server side. If an npm update gives you security warnings after a few weeks of a vanilla project just sitting there, something is very wrong.

Sure, you could say the same about any language too though. I've used static site generators in Rust too, or Python, it's the same problem. People still use them because the benefits outweigh the minute risk of being compromised.

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

#500

Post by satvikpendem »

laputan_machine wrote: post #486
satvikpendem wrote: post #431

Earlier quoted context omitted.

> why would you use the fattest framework when you can write it in plain HTML? I mean, don't use "the fattest framework" then, who is forcing you to use it for writing hello world?

As you get more experienced in programming you'll inevitably inherit projects that you didn't have any say over, when that time comes come back to this comment, I'd be interested to hear if you still feel the same way.

I have inherited such projects. But it seems like you're talking about code that is no more complex than hello world, as you've quoted, so it wouldn't be too complex to do in any language or framework. Now if you do inherit a larger project that you don't like, well, you either work on it or you switch jobs.
Post reply on HN