91–100 of 540 posts
In 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…
Doesn’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.
Doesn’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.
Plus if your frontend is react, it’s much easier to keep all the html generation in one place.
Earlier quoted context omitted.
It seems most of the content is dynamically rendered (at build time with SSG). What alternative did you have in mind?
http://motherfuckingwebsite.com/ styling is sufficient for technical docs. I hate the scroll hijacking and other shenanigans on modern docs sites.
Earlier quoted context omitted.
Static file generation. People are suggesting that tooling creates HTML files from templates at compile time and then served as plain HTML.
Going by the response headers, it seems that most if not all of the HTML served by docs.mux.com consists of cacheable static files. As the OP article mentions, using React for static generation is one of the big use cases for RSC and Next. Which templating technology would you recommend for the use case instead? Keep in mind that generating HTML from OpenAPI specs can become complex and will require plenty of maps, f…
Are there a lot of server side template languages that can’t do this?
This is straight-forward stuff.
Earlier quoted context omitted.
http://motherfuckingwebsite.com/ styling is sufficient for technical docs. I hate the scroll hijacking and other shenanigans on modern docs sites.
I agree re: scroll hijacking and with a preference for minimal styling, while noting that the styling on docs.mux.com is pretty minimal compared to other docs sites. What I'm wondering is what the anti-React folks are recommending for generating HTML and/or DOM itself in the docs use case, since most of it needs to be dynamically generated from OpenAPI definitions.
Granted the pages probably wont look as good as what they have here or be integrated in their larger docs, but yea its possible.
In 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…
What is this sorcery you speak of?
In 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…
Earlier 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…
> 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.
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.