It's weird how projects like Turbolinks, intercooler, and pjax just don't get acknowledged in histories like this one.
htmx has been getting tons of attention recently
Things I wish I knew before moving 50K lines of code to React Server Components
101–110 of 540 posts
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#102Re: Things I wish I knew before moving 50K lines of code to React Server Components
#103Not sure if the OP is here but on Firefox clicking the "API reference" button on the top left causes the full page transition to stutter. The profiler says more than 150ms is spent in a getBoundingClientRect call in a componentDidMount triggering reflow + style computation and 30ms on set Element.innerHTML. That seems excessive especially since I'm looking at this on a recent M1 Macbook.
Same here, and same with “webhook reference” and “changelog”
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#104Re: Things I wish I knew before moving 50K lines of code to React Server Components
#105Earlier 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.
React and Server Components are also normal, available tools.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#106In 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…
I thought we had lost that technology.
Every CPU in the whole must regenerate websites from json descriptors. That's how it should always have been.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#107Earlier 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 think that's a really motherfucking bad piece of advice. Isn't there a version of that which is actually made by someone with some kind of ideas about readability and design? EDIT: http://bettermotherfuckingwebsite.com
And the broken TLS is part of jibe right.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#108Earlier quoted context omitted.
It's a problem because it slows down my machine and each js file which is added makes the ram and cpu problem worse, it just doesn't scale. We're using typescript so building only once a day isn't an option.
I'm sorry but that doesn't make sense to me (especially your last sentence regarding TypeScript). During development vite has HMR and you don't need to run build after every change. This is no different when using SSR. But I don't want to further argue. If you think that SPA is not suitable for your use case, that's ok.
Maybe I don't have the right wording, I'm not sure what it does exactly but running "vite dev" takes 2.5GB of RAM permanently.
It does reload changes very quickly so I guess it has some caching somewhere.
> But I don't want to further argue. If you think that SPA is not suitable for your use case, that's ok.
I personally never seen a use case which did not end up the way I'm describing, my 2 previous companies suffered the same issues.
I even warned my current company that there's a good chance that it would end up the same way and sure enough it did.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#109"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…
> It also reduces the complexity of the page - devs don't need to build logic to wait for things. The page just doesn't render until it has the data it needs.
Devs don't need that anyways, since frameworks like Angular provide this ootb, may it be dynamic template renders (ngif) or as a prereq for finishing routinh
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#110The web tech is truly a swinging pendulum.