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

131–140 of 540 posts

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

#131

Post by knubie »

holoduke wrote: post #125

I think i am getting old. These frameworks are so big and complex. For a simple web hello world you need a huge build and compile pipeline. And now its extended with serverside components. I really wonder what the overhead is. How many of layers of frontend and backend framework code is executed to get the hello world example running. I retreat back to my simple 10kb component framework in which i need only f5 to reb…

> For a simple web hello world you need a huge build and compile pipeline.

These frameworks were not created to solve “Simple hello world” apps.

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

#132

Post by M4v3R »

holoduke wrote: post #125

I think i am getting old. These frameworks are so big and complex. For a simple web hello world you need a huge build and compile pipeline. And now its extended with serverside components. I really wonder what the overhead is. How many of layers of frontend and backend framework code is executed to get the hello world example running. I retreat back to my simple 10kb component framework in which i need only f5 to reb…

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.

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

#133

Post by VagabundoP »

Slight newbie take here. I've just developed a personal webapp with python/flask/htmlx/tailwind. Its for my RPG group and its an interactive GUMSHOE character sheet with discord integrations through webhooks.

I used htmlx/hyperscript so I wouldnt have to get into JS - I find it a complete headache. Getting the balance between server-side and client side processing so its not a huge pain in my ass to debug also took a little bit of experimentation. But in the end I think I spend more time on styling the webpage with tailwind then on the htmlx/hyperscript which is a breeze to learn from scratch.

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

#134

Post by yard2010 »

ojkelly wrote: post #89
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.

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 use a static site generator like Gatsby or a variant of Nextjs (or even docosaurus), get MD(X) support and full features of react components when needed

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

#135

Post by awestroke »

alib wrote: post #55

What I love about this is how PHP and JavaScript had basically the same syntax (minus a $ symbol here or a var keyword there), and then NodeJS was like, but we want to run JS on the server! And now, 15 years later JavaScript has finally caught up and it’s basically the same as PHP, but with more acronyms and a steeper learning curve (to be fair, streaming data from server to client components using suspense is cool).…

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

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

#136

Post by tqkxzugoaupvwqr »

swyx wrote: post #2

https://docs.mux.com/ doesnt seem very interactive at all. i guess i'm being that guy but i'm wondering why it had to be in React, much less RSCs.

Yet performance is abysmal. I clicked on “API reference” and nothing happened for a second. Then the submenu opened in the sidebar. Another second later the content view updated. There is no indication of anything loading, there are no network requests to await. Incredibly, it’s dog slow on an M1 Mac.

If the viewport is 800 px or narrower, click on the menu icon (horizontal bars, top right), then click on a sidebar link. Do that a few times, you’ll notice it’s incredibly slow to react. Same with resizing the viewport, very sluggish.

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

#137

Post by ManniMo »

I get the impression that React is trying hard to catch up with the more modern, easier, faster and cheaper alternatives. But instead of fixing the root problems (rerendering and often required memoization, leaky abstractions) and make React easier, it becomes more complex.

If the end result was great, I would understand all the effort. But it isn't. React is even slower in real world than the benchmarks show. Next is even worth. I've seen recently many dog slow websites built with Next.

Really, I don't get. If the React team wants to improve React they should fix the core.

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

#138

Post by yakshaving_jgt »

ojkelly wrote: post #87
yakshaving_jgt wrote: post #79

The Yesod Haskell web framework has had this for I think more than a decade, and I'm sure it isn't the only one. It's not a bad idea, but it's strange to see old ideas presented as novel.

Isn’t everything a new take on an old idea? And that’s what makes them novel. As Sagan said, “If you want to bake a cake from scratch, you must first invent the universe.” We’re remixing everything all the time, nothing is completely new and that’s fine. We still move forward.

I see what you're saying and in a broader sense that's true.

More specifically though — in the world of web development — some ideas are actually [as good as] original. When CSR/SPA became well established as an approach in web development, there wasn't a time before it when that approach had been common.

The approach to web development described in the article however is essentially the same approach that web developers commonly used 10-15 years ago.

n.b. I'm aware the CSR/SPA approach is more like 20 years old, but I'm making a judgement call on how common common is. Furthermore, when the CSR/SPA approach was first explored in ~2002, what old idea was it a new take on? Flash? If so, what begets Flash? There was a time before the Internet, and it wasn't all that long ago.

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

#139

Post by christophilus »

M4v3R wrote: post #132
holoduke wrote: post #125

I think i am getting old. These frameworks are so big and complex. For a simple web hello world you need a huge build and compile pipeline. And now its extended with serverside components. I really wonder what the overhead is. How many of layers of frontend and backend framework code is executed to get the hello world example running. I retreat back to my simple 10kb component framework in which i need only f5 to reb…

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.

Just because it’s a one liner to install something doesn’t mean you aren’t installing a big, complex, over-engineered thing.

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

#140

Post by morbicer »

pavlov wrote: post #34

I wonder about the code with the heading “A Server Component with data fetching”. It shows a HTTP request made to the company’s publicly visible API endpoint. But this request is being made from their own server (the one that is generating the HTML + JS from these React components). Is the idea really that your front-end generator calls client APIs rather than internal ones (e.g. just making a database request)? That…

It's a limiting, but saner approach for any larger app/company.

It's the same logic why in OOP you have private members/methods. As owner/maintainer of some component you want keep stable public api and be able to iterate on the internals.

Letting any client willy-nilly directly fetch from database is unsecure and unmaintainable in future.

Post reply on HN