Does anyone know if CSS-in-JS and Context support is planned for RSC, or is there a technical limitation which means they’ll never be possible?
Things I wish I knew before moving 50K lines of code to React Server Components
111–120 of 540 posts
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#112Doesn’t make any sense for me why we are now using React in the backend, to render HTML… Let’s go back to 10 years ago.
Having a templating system in ‘that environment’ is worth its weight in gold IMO. I’ve been switching between Svelte and Django templates a lot lately, and Svelte just…knowing about the DOM, makes the experience so much nicer. I haven’t come across a non-JS template system that does this. And yes, I was there for PHP and jQuery and whatever.
I have to agree, Django templating (last I saw) was stuck somewhere in Web 1.0
Jinja2 is better, but most of the time, I would just build the API and not bother with rendering anything on Django itself
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#113Earlier 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.
"at least seeing something" leads to jira or teams where you open a thing and then its entries slowly pop in and shift as they get loaded. An illusion of a site being there that can't be used because you can neither focus on the text nor use any of the inputs as they shift beneath your eyes.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#114Earlier 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. People want that back, but they also like React, and their existing component libraries, and they want to generate the backend pages with React. It's not that strange. And you can (I think) pretty seamlessly have part of the page rendered on the server, and parts still function on the client.
Yea but why do I need to use React for that? Is it because these devs can only do React and nothing else, so we will shoehorn everything into it? I mean, more power to them, if they want to do it and have 10x the complexity and take 10x longer than learning and using normal, already available tools.
> I mean, more power to them, if they want to do it and have 10x the complexity and take 10x longer
The server side components didn't seem to me at a glance significantly less convenient then say a normal PHP server stack.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#115That seems like a tremendous commitment for such a recent technology.
Yeah I do wonder what the VCs think of these kinds of big bang rewrites, whether they know or care
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#116Earlier quoted context omitted.
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.
Partly due to frontend framework hype, I would say. If we take traditional backend web frameworks, like lets say Django, you could simply look for Django devs and would find plenty, even though it exists for a long time. Choosing a hyped JS framework is what is the risky move, because people jump ship quickly. There are design decisions in Angular for which I would never even consider Angular for development.
When angular.js came when you needed to do something highly interactive it's competitors used to be either amature hour hipster shit frameworks or hacking stuff using jquery.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#117I feel the history explanation isn't that great, making it look like the modern web development simply reinvented PHP. There are nuances to every technology that make developers choose it over another. Still looking for a good blog post on the evolution of web development since PHP+jQuery.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#118would htmx have fixed this problem ?
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#119In server-side rendering, clients are sent HTML that they can see immediately I noticed this too. You can put a plaintext file on the server and it gets transferred to the browser pretty fast. You can also put another plaintext file ending with .css on the server and it can make things on the first page move and look really nice just because the browser knows what to do with it. It’s a neat trick but still second to…
To cap it all off, I'll add some dynamism with cgi-bin magic.
Why use kubernetes and the cloud when you can FTP or rsync your code onto a box?
Simpler times.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#120Does anyone know if CSS-in-JS and Context support is planned for RSC, or is there a technical limitation which means they’ll never be possible?
For Context support, I think the reason it's not supported is because Server and Client components have different lifetime. In theory they could add something like Server Context, that's accessible only to Server components.
For CSS-in-JS, those are all 3rd party libraries, so they need to adapt on their side. For example, `styled-components` uses Context heavily, so they need to re-think their approach. For `css-modules` adapting to Server components looks doable, but requires substantial amount of work.