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.
Things I wish I knew before moving 50K lines of code to React Server Components
31–40 of 540 posts
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#32Earlier quoted context omitted.
It seems most of the content is dynamically rendered (at build time with SSG). What alternative did you have in mind?
I'd rather use Blazor, or Jinja. But I hate react, js, and front end work, so maybe I'm not the target audience. I clicked the link out of morbid horror.
I haven't used Blazor, but I shudder at the thought of using Jinja to generate the HTML here. Rendering documents from OpenAPI spec benefits from being able to easily transform data, map, filter and so on - especially if you are displaying the JSON schema for request and response bodies (which docs.mux.com appears to be doing).
The experience of doing these transformations in template languages is pretty sub par.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#33Maybe it's just the circles in which I've been active lately, but I feel like a lot of time and effort is spent these days practically just moving code around between implementations, without much practical change in user experience. What drives this behaviour? I mean the question on a deeper level. An answer like "the technology hype cycle" just begs the question. Why does someone feel like they have to move busines…
I think that one factor is that staying on old tech is a risky career move both for the individual and the business. At work we have an Angular (the old one) app and while many new devs pick up some React, they definitely don't play around with ancient Angular versions for fun. So now we're stuck with a pretty big app using tech no one is interested in anymore.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#34I 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 seems kind of wasteful, and also potentially confusing from a API design standpoint.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#35Earlier quoted context omitted.
Why was it considered a bad move to go SPA? There are two main advantages of SSR; - API calls necessary to build the page happen in the data center instead of the public internet, so they're much faster. You can use a database query instead of an HTTP API call if you really want to. That results in a huge speed gain for a lot of sites. It also reduces the complexity of the page - devs don't need to build logic to wai…
The first argument leads to waiting to see anything vs at least seeing something. Many use cases the latter is preferable. The second case is a common misconception of modern SPA. Code-splitting has been around for a while now. When split across routes it's trivial to implement.
Or just don't even bundle if you can serve your users with ES6 modules.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#36"This was called client-side rendering (CSR) or single-page applications (SPA) and was widely considered a bad move." Why was it considered a bad move to go SPA? I generally disagree with this statement. But I feel like whenever this conversation comes up we're talking different applications altogether. A SPA is fine for a back office application. What it's not necessarily good for is a splash page or marketing page…
Why was it considered a bad move to go SPA? There are two main advantages of SSR; - API calls necessary to build the page happen in the data center instead of the public internet, so they're much faster. You can use a database query instead of an HTTP API call if you really want to. That results in a huge speed gain for a lot of sites. It also reduces the complexity of the page - devs don't need to build logic to wai…
Doing database lookups on the server was the primary reason people STOPPED doing server side render and shifted to JS+API. Why do we now think that the way we used to do it was actually better?
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#37At the point of server components I sort of giggle to myself that we've come full circle and maybe I can come out of my SSR bomb shelter and enjoy life again
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. I’m sure they’ll claim it’s different now because… hydration or something or another. As a former PHP developer who spent a lot of time both working on server rendered pages and converting server rendered pages to be API/JS (render the core in HTML+JS and use APIs with two way data binding to u…
Did you have a look at SvelteKit? It does that "hydration" magic, first page loads completely from server, then it can work like a SPA, only fetching required data.
It’s all JS, which we know from the frontend, all that "magic" is done by the framework in the background. You write it once, it works both ways automatically.
We already build 3 webapps using SvelteKit, still happy for the ease of use, or great "DX" as some call it.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#38Earlier 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. I’m sure they’ll claim it’s different now because… hydration or something or another. As a former PHP developer who spent a lot of time both working on server rendered pages and converting server rendered pages to be API/JS (render the core in HTML+JS and use APIs with two way data binding to u…
SSR is different I think because it can perform better, but given the state of most sites on the internet I think 2003 style rails is sufficient for most sites. And I haven’t met a JS-ey UI I have enjoyed using as much as a vanilla HTML one for most online stuff (drawing, games, 3D etc. excepted).
The RSC stuff seems to just add a vast amount of complexity with little benefit.
It feels like the end state here is going to be HTML+CSS with JS for interactivity using APIs, which is exactly what I was doing in 2006.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#39Earlier quoted context omitted.
Why was it considered a bad move to go SPA? There are two main advantages of SSR; - API calls necessary to build the page happen in the data center instead of the public internet, so they're much faster. You can use a database query instead of an HTTP API call if you really want to. That results in a huge speed gain for a lot of sites. It also reduces the complexity of the page - devs don't need to build logic to wai…
Doing database lookups on the server was the primary reason people STOPPED doing server side render and shifted to JS+API. Why do we now think that the way we used to do it was actually better?
Indeed, the longer you are around you see these cycles repeat again and again.
Thin client vs thick client has been a point of contention since mainframes and minicomputers.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#40Earlier quoted context omitted.
Why was it considered a bad move to go SPA? There are two main advantages of SSR; - API calls necessary to build the page happen in the data center instead of the public internet, so they're much faster. You can use a database query instead of an HTTP API call if you really want to. That results in a huge speed gain for a lot of sites. It also reduces the complexity of the page - devs don't need to build logic to wai…
Doing database lookups on the server was the primary reason people STOPPED doing server side render and shifted to JS+API. Why do we now think that the way we used to do it was actually better?
Where do you propose database lookups get done in the JS+API world?
Surely they are getting done on the server that hosts the API? Unless you are using something like Firebase or SupaBase which can sort of enable client side database access (but not really, it’s still doing it on a server, just their server and running the call through RLS or similar)