Live data from Hacker News

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

mux.com

431–440 of 540 posts

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

#431

Earlier quoted context omitted.

> Because they are called "libraries" for a reason, it can do much more than "Hello, World", and they are routinely used for much more than that. There you go.

> When you're writing a specific program, e.g. it's never going to be anything more than "Hello, world!" , why would you use the fattest framework when you can write it in plain HTML? Emphasised the parts I think you should re-read

> 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?

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

#432
post #132

Earlier quoted context omitted.

You literally just run: > npx create-next-app@latest Press Enter a few times for default settings and voila, you have a hello world app up and ready to run.

With 700 dependencies, 200MB, and a massive security surface.

None of that gets to the browser.

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

#433

Earlier quoted context omitted.

Pure "content" sites don't need to be SPAs, but web "applications" suck ass rendered server side.

Citation needed. 99% of apps are basic CRUD apps. Aside from a few interactive pages - which you could even write with React - there's zero need for this bloat. No, your "application" is not Google Docs, Spotify, etc. It's not a SPA.

> 99% of apps are basic CRUD apps

Citation needed.

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

#434

Earlier quoted context omitted.

- npx create-next-app@latest - npx: command not found - install node / npx - npx create-next-app@latest - realise your node is too old - install nvm / node - npx create-next-app@latest - answer a bunch of questions - npm start - get an error: Error: ENOENT: no such file or directory, open '/tmp/my-app/.next/BUILD_ID' - npm run dev - hello world in browser

This is why web development (and python, don't get me started on the pain that is python) is not for me.

What do you code in? For any language if you don't have the toolchain set up, obviously it'll seem laborious to install it, it's not a knock on the framework used on top of the toolchain.

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

#435
post #132

Earlier quoted context omitted.

You literally just run: > npx create-next-app@latest Press Enter a few times for default settings and voila, you have a hello world app up and ready to run.

- npx create-next-app@latest - npx: command not found - install node / npx - npx create-next-app@latest - realise your node is too old - install nvm / node - npx create-next-app@latest - answer a bunch of questions - npm start - get an error: Error: ENOENT: no such file or directory, open '/tmp/my-app/.next/BUILD_ID' - npm run dev - hello world in browser

If you don't have the toolchain set up, it's not like it's different for any other language.

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

#436

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.

You can add a test after debugging, no one's stopping you. But yes, it's annoying to debug some UI issue and having to set up an entire integration test for an issue you already know is there and can navigate much more easily via a mouse than via linking through HTML tag ids.

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

#437
post #294

Earlier quoted context omitted.

Have you tried SvelteKit yet? I can't say it lacks magic, but that magic is focused on eliminating boilerplate, not hiding where everything is coming from and going to. It is jarring at first when you look at your code and say, "Wait, what else do I need to do?" And there's nothing left. const { count, setCount } = useState(0); becomes let count = 0; There is no more useMemo(…) or useEffect(…). They just don't exist.…

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 quite as useful. Be careful about which technology you want to be the central player.

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

#438
post #311
post #202

Earlier quoted context omitted.

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…

More like React scrambled to add a feature to check a box in a comparison chart with the upstarts no matter how cumbersome or disruptive the API changes ended up relative to existing codebases. The new frameworks were poised to eat React's lunch, they knew it, and they needed something quick to hold back the rising tide. They may succeed, but only due to inertia, not a better/cleaner solution.

> The new frameworks were poised to eat React's lunch, they knew it, and they needed something quick to hold back the rising tide.

Not really, the percentage of users for Solid, Svelte, and Remix are vanishingly small. They're essentially testgrounds for React anyway.

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

#439
post #316

Earlier quoted context omitted.

As a different perspective, I'm also old enough to remember when CSS and Javascript were invented , and I've been making websites since that time. IMO web dev has never seen better tooling than today, and user experience has improved tremendously over the years. What we used to call AJAX has grown from a neat side toy to a basic part of everyday life in the form of client components and SPAs. The server is still as p…

Well, React certainly has succeeded in increasing the client-side complexity, that's for sure. They seem to be making good inroads on increasing server-side complexity as well. Kudos to their contributions to excess CO2 emissions! I have yet to see a React project with more than five contributors fail to turn into a big ball of mud within 18-24 months, requiring either a periodic rewrite or resigned acceptance of tru…

> I have yet to see a React project with more than five contributors fail to turn into a big ball of mud within 18-24 months, requiring either a periodic rewrite or resigned acceptance of trudging through large volumes of mud to get anything done.

Not my experience at all, and I've been working with React for years. I've seen companies successfully transition to functional components from class components, all while maintaining years-long functionality. Just because you dislike React doesn't mean it's not successful.

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

#440
post #141
post #89

Earlier quoted context omitted.

Great doc sites are dynamic in heaps of little ways. Stripe started the trend of showing you code snippets with api keys from your account to test with. Frontend docs sites almost always include runnable examples, that you can play with inside the docs.

You can get dynamic functionality for docs sites without much JS at all. We've been doing it for years.

It's easier to integrate JS when the entire toolchain is all in JS. That's my main reason for using React Server Components over other static site generators. Also I like types via TypeScript.
Post reply on HN