Streaming Server Side Render in React 18 | Hacker News Reader

Streaming Server Side Render in React 18

github.com

42 pointsmaxam201715 comments

I haven't tried the code in the repository but form skimming it a bit it seems to have the same issue I had when I tried this approach - what should I do while developing?

What I mean is that this works, but in production.. I couldn't get this to behave properly due to FS caches of files it puts through the pipeline to finally stream it to the client.

So am I supposed to be using the usual React server thing to write code and use this in production? in this case, I can't account for run-time SSR issues that only come up when using this SSR approach.. so I can't trust my releases without "rendering" all the UI to see there are no issues.

What I personally ended-up doing is build-time (Jenkins) generation of all public facing pages and saving corresponding HTMLs, React-hydrating these on load.. and a normal skeleton `index.html` with normal React.render for the actual app pages which are behind login..

This of-course is not relevant if you have dynamic public pages you want to serve but that's a different use case than mine.

React gives me happiness in these unpredictable times

Sounds pretty dramatic on the surface, but it does indeed give great comfort to have a stable frontend library that's improving in all the right places. React + TypeScript powers the UI of my business and I've never felt more happy about my frontend code. Being on a dead-end framework library and still having to add features because you dread moving to greener pastures is pretty demotivating.

I couldn’t agree more. People are quick to criticize, but in a very long time spent building user interfaces for the web, I’ve never been more confident in and happy to build with a set of tools. TypeScript and React together are excellent.

There’s plenty to improve still, but like you said, it’s stable and improving in all the right places.

Unfortunately React + Typescript is not a complete solution for building websites. What people are “quick to criticize” includes tools like webpack, CRA, emotion, remotion, redux/recoil, babel, the 1000 modules and all the other crap required to build a single page. Experiences vary tremendously.

A "complete solution" is perfectly fine to hit the ground running, but will not stay complete once you go beyond an MVP. I started with WordPress with a bunch of plugins and after extending WP beyond its intended purpose decided I rather pick a set of high quality mainstream libraries (next.js, knex.js, passport.js, sharp, bcrypt, MobX, etc) to build upon than shoehorn a complete solution to my needs. I think Next.js has taken a lot of pain out of Webpack/bundling even though I have some gripes with the (SSR) data fetching API.

What are your gripes with SSR in Next? I have some too. I find the router in next is generally lacking, and there’s no proper way to say “render this on the server for the first request, but do this if the request comes from the application”. I believe there was a method to do it that was deprecated, but in my experimenting it was still not behaving the way I expected.

The main issue was that it was hard to prevent various levels of rendering in the page even though I knew it was redundant.

When using remix this is trivial to accomplish. I’m not sure I’m sold on remix entirely, but the routing capabilities are far better than Next’s.

Also some recent tweets from vercel suggest to me that they might be resolving this soon. Here’s hoping!

Routing is indeed another pain point especially with internationalisation and having multiple dynamic/translated paths to the same page. My issue with data fetching is about the depreciation of getInitialProps() without a good alternative in place: https://github.com/vercel/next.js/discussions/10874 I need a single place to load site translations, user data and what not, preferably without refetching this data on each page transition.

I also briefly looked at Remix and love the routing, but do not necessarily want Remix to dictate how I mutate my data.

Yeah, we’re on the same page with getInitialProps. Next needs something which accomplishes what people want from that, but with ongoing support from the team.

I think it’s a special circumstance but still important to support. I’m not aware of a work around at this point.

How does remix dictate how you mutate your data?

"How does remix dictate how you mutate your data?" I didn't word it correctly as Remix doesn't dictate the model. It does seem to have a strong opinion on how to handle form submissions. Trying to closely follow the browsers native form api does make a lot of sense in most situations, but I like a more JavaScript heavy approach to form handling. Especially since I have a lot of complex form interactions.

You’re not wrong.

I think a big part of this problem is that people need to know why they’re choosing a dependency and what problem it solves, and if that aligns with what they’re building properly. For example, if you choose redux, why are you choosing it? Why choose it over the context api in react with built in state management, or zustand, jotai, or etc. In any stack you should be able to answer these questions, not just JS in the browser, but my experience is that a lot of JS teams haven’t determined this properly. It’s a recipe for struggle because they end up using more dependencies and in house code to band aid the fact that their tooling doesn’t work well with their software.

The result is that the wrong dependencies and too many of them are used. This makes everything from building to testing to maintenance harder. A great goal on any team is to minimize the number of dependencies used in the first place; they’re often looked at as necessary to solve various problems, but they might not be at all.

Some degree of trouble is inevitable because the JS world is kind of crazy, but it doesn’t have to be bad.

"stable frontend library" - I disagree. How class components were deprecated is just ridiculous to me.

As far as I can tell, class components are not deprecated and still featured prominently in the official React docs. Did you mean something else?

Meh, to me it's indeed a product of our times. Someone came to us with the solution to all (frontend) problems - our unhappiness - and then you find out it's even more complex than what came before so we're working even harder for this new master. [1] I like React on a 10 line project, I loathe it on a 100k line project, the overengineering, the npm dance, the hundred of dependencies that are a gust of wind away from breaking the illusion of a coherent and working system. Now we just have wait for the solution to the React problem.

Sorry, this came out more depressing than I originally intended.

1: https://youtu.be/egNKT0k__2w

It's aight

Reply on news.ycombinator.com