React on the server is not PHP(artmann.co)
artmann.co
React on the server is not PHP
https://www.artmann.co/articles/react-on-the-server-is-not-php
64 comments
NextJS is just for building the frontend. If you have an API layer written in Deno or whatever then you still need that.
Reading online there seems to be a lot of confusion about what NextJS is with questions like is it better than nodejs, is it a backend server etc.
It runs on a server, on nodejs, but it doesn't provide what most people think of as the backend. It serves the frontend files. It does a bunch of extra things for the frontend.
Presumably there is a way to run your own api code alongside it in the same node instances. Not sure if that's wise or not.
I personally prefer to start off with a plain react project with vite as the bundler and then host that statically without the extra SSR stuff. For an app website I think that's a better approach. For a informational website I'd probably look to other solutions.
Reading online there seems to be a lot of confusion about what NextJS is with questions like is it better than nodejs, is it a backend server etc.
It runs on a server, on nodejs, but it doesn't provide what most people think of as the backend. It serves the frontend files. It does a bunch of extra things for the frontend.
Presumably there is a way to run your own api code alongside it in the same node instances. Not sure if that's wise or not.
I personally prefer to start off with a plain react project with vite as the bundler and then host that statically without the extra SSR stuff. For an app website I think that's a better approach. For a informational website I'd probably look to other solutions.
NextJS is pretty much the go-to for making decent webapps, check out KeystoneJS if you want to make a custom CMS.
Thanks, but that doesn't address my question.
Let me rephrase: Is NextJS a full back-end, or is it only for presentation? Would you use it in combination with something like Deno, or instead of it?
Let me rephrase: Is NextJS a full back-end, or is it only for presentation? Would you use it in combination with something like Deno, or instead of it?
Next.js won't require a Deno backend. You can define backend data fetches [0] along with the UI Pages and routes for an API [1].
Of course the NextJS application could call out to a Deno backend as well, but the external app is not required.
- [0] https://nextjs.org/docs/pages/building-your-application/data... - [1] https://nextjs.org/docs/pages/building-your-application/rout...
Of course the NextJS application could call out to a Deno backend as well, but the external app is not required.
- [0] https://nextjs.org/docs/pages/building-your-application/data... - [1] https://nextjs.org/docs/pages/building-your-application/rout...
Thanks!
Who downvotes a completely relevant question? Pathetic.
If you need to clarify that something isn’t something else, because it isn’t obviously different, maybe the two are more alike than you’d like to admit.
On that note, I’m a happy PHP developer, PHP doesn’t suck anymore (https://youtube.com/watch?v=ZRV3pBuPxEQ), and there is no way to say JavaScript doesn’t have at least as many footguns now. (Personally, I think JavaScript’s footguns - like the ludicrous dependency trees and framework churn - are actually worse.)
On that note, I’m a happy PHP developer, PHP doesn’t suck anymore (https://youtube.com/watch?v=ZRV3pBuPxEQ), and there is no way to say JavaScript doesn’t have at least as many footguns now. (Personally, I think JavaScript’s footguns - like the ludicrous dependency trees and framework churn - are actually worse.)
I agree on all points but unfortunately php can't do things Javascript can do, as in manipulate the DOM, and run natively in the browser client side...
So I am a mostly happy php developer that still has problems
So I am a mostly happy php developer that still has problems
That’s a mostly solved problem. If you’re in the Laravel ecosystem:
https://livewire.laravel.com/
https://alpinejs.dev/
AlpineJS is for your menus and simple client-side interactivity. Livewire lets you render components server-side while handling routing, interactivity, updates, morphing, everything you need all in one. Even complex things, like cross-page persistent components, are possible.
Combine the two, you’ll be counting the lines of JavaScript you write in the dozens, on one hand.
Later, you can throw in Laravel Volt if you like your components single-file with a functional syntax; Laravel Folio if you like your routes defined by your folder structure like classic PHP; or throw in Filament for an entire UI library, form builder, table builder, and notifications delivery system.
https://livewire.laravel.com/
https://alpinejs.dev/
AlpineJS is for your menus and simple client-side interactivity. Livewire lets you render components server-side while handling routing, interactivity, updates, morphing, everything you need all in one. Even complex things, like cross-page persistent components, are possible.
Combine the two, you’ll be counting the lines of JavaScript you write in the dozens, on one hand.
Later, you can throw in Laravel Volt if you like your components single-file with a functional syntax; Laravel Folio if you like your routes defined by your folder structure like classic PHP; or throw in Filament for an entire UI library, form builder, table builder, and notifications delivery system.
> React on the server is not PHP
I took this headline to be a dig against React on the server, but I guess the author intended the opposite.
I took this headline to be a dig against React on the server, but I guess the author intended the opposite.
One of the most irritatingly shallow criticism of React has always been "ooh you're mixing html and control in the same file, it's PHP all over again!" The criticism is not particularly interesting or valid, given the differences between the two.
Back when I first learned PHP I recall the horror of seeing buckets of tutorials that involved writing database queries directly in the middle of templating HTML, but the materials appear to have gotten better from a brief glance (with W3schools, as always, teaching worst practices).
Back when I first learned PHP I recall the horror of seeing buckets of tutorials that involved writing database queries directly in the middle of templating HTML, but the materials appear to have gotten better from a brief glance (with W3schools, as always, teaching worst practices).
It looks like the author's memory of PHP stopped before modern standards were established. Which is to be expected, since they probably left PHP a long time ago to become an evangelist for another language/framework.
Here "PHP" is used as a generic term for "whatever crap we called web programming back in the 00s." Or maybe just "WordPress."
Here "PHP" is used as a generic term for "whatever crap we called web programming back in the 00s." Or maybe just "WordPress."
I think a lot of people make the mistake of conflating Wordpress development with PHP development.
Or just somehow think js is better. There is so much bad js code out there. Including react and whatever.
Which framework does he suggest? Next, remix or svelte kit? I’m sure there are more. Which one will become dominant?
What’s funny is that PHP got part of its bad reputation from poorly maintained, poorly organized codebases. Many PHP jobs involve modernizing that crap, which is gnarly.
However, that will one day happen to JavaScript. Imagine wrestling with a barely updated, decade-old JavaScript codebase in 2034.
I am of the opinion that it will be even worse than the old PHP app. At least the old PHP app didn’t have more than a dozen packages at most. Your job then will be to modernize a JavaScript app with 1000+ dependencies from one of the dozens of frameworks that didn’t make it. Fun!
However, that will one day happen to JavaScript. Imagine wrestling with a barely updated, decade-old JavaScript codebase in 2034.
I am of the opinion that it will be even worse than the old PHP app. At least the old PHP app didn’t have more than a dozen packages at most. Your job then will be to modernize a JavaScript app with 1000+ dependencies from one of the dozens of frameworks that didn’t make it. Fun!
I'd recommend reading the article, it's awesome!
But to answer your question, he doesn't suggest any frameword in particular. He's merely expressing his excitement about these full stack js frameworks.
And if I were to suggest which one you should learn, you should learn the least in-demand one, because that's the one you secretly want to learn ;)
But to answer your question, he doesn't suggest any frameword in particular. He's merely expressing his excitement about these full stack js frameworks.
And if I were to suggest which one you should learn, you should learn the least in-demand one, because that's the one you secretly want to learn ;)
"I'd recommend reading the article, it's awesome!"
Surely this is sarcasm...
Surely this is sarcasm...
[deleted]
I like PHP and javascript.
Jquery wasn't pretty but it did smooth over browser differences (as someone who had to target a blackberry browser, I still respect it.)
Vue/ React and company are pretty amazing. But sometimes I wonder if they're too much for a lot of the use cases they're used with. I find a fair number of sites that don't quite work.. that could have used a simple form. The "javascript form check" before submission seems to be quite frequent. Webpack is a pain frankly.
modern php is pretty amazing. Though the trend of getting on the upgrade hamster wheel and frameworks use of the latest/greatest makes it harder to like. When I run into a perl script at work, there is some relief that it will probably work, as perl just isn't changing (warts and all).
https://www.php.net/supported-versions.php
Jquery wasn't pretty but it did smooth over browser differences (as someone who had to target a blackberry browser, I still respect it.)
Vue/ React and company are pretty amazing. But sometimes I wonder if they're too much for a lot of the use cases they're used with. I find a fair number of sites that don't quite work.. that could have used a simple form. The "javascript form check" before submission seems to be quite frequent. Webpack is a pain frankly.
modern php is pretty amazing. Though the trend of getting on the upgrade hamster wheel and frameworks use of the latest/greatest makes it harder to like. When I run into a perl script at work, there is some relief that it will probably work, as perl just isn't changing (warts and all).
https://www.php.net/supported-versions.php
They definitely are too much. Htmx, for example, continues to increase in popularity precisely because so many full stack devs are playing with it and it seems to solve their problems.
I love Unpoly. It's a less verbose version of HTMX
Well Perl 6 tried to change too much at once and now the language is pretty stagnant, for better and worse. PHP's own v6 was something of a disaster, but the demand for PHP remained strong enough to keep trying. Possibly because of WordPress.
(IMO Perl also kind of died because of too many ways to do the same thing. In practice it meant every code base becomes bespoke.)
(IMO Perl also kind of died because of too many ways to do the same thing. In practice it meant every code base becomes bespoke.)
We live in exciting times! But also very confusing times.
I spent the last year transitioning from data science to learning full stack web dev and it was pretty wild. There isn't exactly an obvious entry point into learning all of this stuff and there are so many layers of abstraction now.
As hilarious as it sounds, I actually first tried to learn web development by building my first website with Next js on Vercel without even knowing basic html, css, js or what a webserver was. Needless to say, I hit a hard wall and decided to learn web dev from the ground up with html, css, js and flask.
I spent the last year transitioning from data science to learning full stack web dev and it was pretty wild. There isn't exactly an obvious entry point into learning all of this stuff and there are so many layers of abstraction now.
As hilarious as it sounds, I actually first tried to learn web development by building my first website with Next js on Vercel without even knowing basic html, css, js or what a webserver was. Needless to say, I hit a hard wall and decided to learn web dev from the ground up with html, css, js and flask.
after you are ready, how to get job in full stack web dev? as a junior developer? I'm spending weekends to learn web dev as well but wonder how to get a job on that as an experienced c developer.
JavaScript on the server is better than JavaScript in my browser because at least it doesn’t waste my battery.
Actually it would sort of be nice if these frameworks could be coded such that if I have JavaScript shut off, it just runs the code elsewhere and sends me the site.
Or better yet, just write HTML and CSS and be done with it. But that’s too hopeful.
Actually it would sort of be nice if these frameworks could be coded such that if I have JavaScript shut off, it just runs the code elsewhere and sends me the site.
Or better yet, just write HTML and CSS and be done with it. But that’s too hopeful.
> Actually it would sort of be nice if these frameworks could be coded such that if I have JavaScript shut off, it just runs the code elsewhere and sends me the site.
Remix does!
Actually, most (all?) of the major frameworks will do SSR on pageload and only use client-side rendering for re-renders. But yeah, Remix will do exactly what you're asking for and force you to do full-page refreshes without JS. If that's what you really want.
Remix does!
Actually, most (all?) of the major frameworks will do SSR on pageload and only use client-side rendering for re-renders. But yeah, Remix will do exactly what you're asking for and force you to do full-page refreshes without JS. If that's what you really want.
Nice! This seems like a reasonable compromise.
> Discover why this isn't a step backward but a leap forward in building powerful, efficient web applications.
There are certainly reasons to use JS on the server but efficiency is definitely not a big one. Even less when using React which is probably the slowest of the modern framework/libs doing SSR.
https://blog.platformatic.dev/ssr-performance-showdown
There are certainly reasons to use JS on the server but efficiency is definitely not a big one. Even less when using React which is probably the slowest of the modern framework/libs doing SSR.
https://blog.platformatic.dev/ssr-performance-showdown
Well, that's too bad. PHP got it right and every "new" technology has been quickly replaced with something "newer" (that makes all the same mistakes). Spring -> Ruby on Rails -> Django -> Angular -> Ember -> React -> Next/Nuxt/Noxt/Nixt/Nyxt/Nzxt/Corsair
Are you tired yet?
Are you tired yet?
a nice write-up, I happened to start learning next.js this weekend and in a few hours I actually like what I saw, will continue the learning definitely.
I measured the speed of this blog and it's finished in 5 to 8 seconds after a soft-reload. Even more telling is the use of http 1.1 on partials of this blog when all remote includes do h2 or h3...
This is a blog btw, so a static should do! I do domain management, animations and implement stats from logs on the fly. And i even have a markdown blog! ;)
My page loads in under 1 second with a hard refresh.
Backend for a combined full page controller or partials does 1ms rendering with logged in user. ofc stuff is cached, but the user should never notice. All system related calls are fast as f... and intended this way. DB with PDO takes most of this millisecond.
I do vanilla TS with fetch on the frontend which is responsive as a GUI and that's great, i can modify the DOM and do frontend stuff - and not more. Why would i? One call to the ldap-client in nodejs, even with bun, is already slower than my whole page.
One tool for one job!
If you can beat this wake me up for js on the backend.
This is a blog btw, so a static should do! I do domain management, animations and implement stats from logs on the fly. And i even have a markdown blog! ;)
My page loads in under 1 second with a hard refresh.
Backend for a combined full page controller or partials does 1ms rendering with logged in user. ofc stuff is cached, but the user should never notice. All system related calls are fast as f... and intended this way. DB with PDO takes most of this millisecond.
I do vanilla TS with fetch on the frontend which is responsive as a GUI and that's great, i can modify the DOM and do frontend stuff - and not more. Why would i? One call to the ldap-client in nodejs, even with bun, is already slower than my whole page.
One tool for one job!
If you can beat this wake me up for js on the backend.
Are you sure you aren't just counting the GA collect call around the 5.5s mark? Prior to that, for me, everything always finishes within 1.58s on a hard refresh. The "load" event fires in under 400ms, and if I enable Firefox's tracking protection (which blocks the Disqus widget from loading), the page always finishes within 300ms on a hard refresh, 160ms on a soft refresh.
I doubt that your observation of 5 to 8 seconds has anything to do with this blog's backend or frontend, unless you take fault with the Disqus widget it uses.
I doubt that your observation of 5 to 8 seconds has anything to do with this blog's backend or frontend, unless you take fault with the Disqus widget it uses.
https://gomakethings.com/react-is-slow-at-its-very-core/
What's your point? If you disable all remote and interactive stuff you get a fast page render? That's exactly what i criticize here. The page should be considered loaded when all is fetched and usable. And not "loaded" when the main parts from his server are transferred.
But yes, the Disqus takes the longest loading time starting at 4s. Scripts start at around 1 second to load. So yeah, you COULD argue the page is loaded after 1 second, but the point is, that it is not _RENDERED_ and functional and not all parts have been fetched yet.
Ofc your mileage may vary, i don't block disqus but use uBlock and the page is most likely hosted on another continent which makes latency another issue.
To make things fair i took to https://tools.pingdom.com/ and selected american and german servers respectively, which show 140ms for my page (Frankfurt) and still 800ms for his (from NA) which i think is mostly due to the use of http1.1. and ignores all remotely added scripts and tracking.
What's your point? If you disable all remote and interactive stuff you get a fast page render? That's exactly what i criticize here. The page should be considered loaded when all is fetched and usable. And not "loaded" when the main parts from his server are transferred.
But yes, the Disqus takes the longest loading time starting at 4s. Scripts start at around 1 second to load. So yeah, you COULD argue the page is loaded after 1 second, but the point is, that it is not _RENDERED_ and functional and not all parts have been fetched yet.
Ofc your mileage may vary, i don't block disqus but use uBlock and the page is most likely hosted on another continent which makes latency another issue.
To make things fair i took to https://tools.pingdom.com/ and selected american and german servers respectively, which show 140ms for my page (Frankfurt) and still 800ms for his (from NA) which i think is mostly due to the use of http1.1. and ignores all remotely added scripts and tracking.
> Ofc your mileage may vary, i don't block disqus but use uBlock and the page is most likely hosted on another continent which makes latency another issue.
The page is indeed slower if I route it through a German VPN, but all content including the widget still stops visibly changing in under 5s on a hard reload, 1.5s on a soft reload: everything past that is various tracking nonsense which presumably has no impact on functionality.
My bigger point is, no one but a bot is going to be using the Disqus widget to check the comments within 5 seconds of visiting a page on a blog they've never seen before. All substantial content above it stops moving within a second, from Germany or from the U.S. (Unless your RTT is especially bad where you live?)
I just don't see what your prescription would be here, except to tear out the widget entirely, just for the sake of improving a metric with no direct importance. Unless you advise that the author implement his own commenting system, which is a huge can of worms filled with spam, legally-sensitive user data, and so on. I certainly wouldn't take it as an indictment on his choice of frontend or backend.
The page is indeed slower if I route it through a German VPN, but all content including the widget still stops visibly changing in under 5s on a hard reload, 1.5s on a soft reload: everything past that is various tracking nonsense which presumably has no impact on functionality.
My bigger point is, no one but a bot is going to be using the Disqus widget to check the comments within 5 seconds of visiting a page on a blog they've never seen before. All substantial content above it stops moving within a second, from Germany or from the U.S. (Unless your RTT is especially bad where you live?)
I just don't see what your prescription would be here, except to tear out the widget entirely, just for the sake of improving a metric with no direct importance. Unless you advise that the author implement his own commenting system, which is a huge can of worms filled with spam, legally-sensitive user data, and so on. I certainly wouldn't take it as an indictment on his choice of frontend or backend.
I don't think this article is well written, it doesn't really articulate a point other than it's not PHP because
> we've developed solid principles for building UIs
There's not really any substance to this statement or the paragraph it's in. I would skip this article entirely, and I think a much more profound view of this concept is "Mind the Gap" talk by Ryan Florence about dissolving the concept of the network and explicit code needed to manage that: https://www.youtube.com/watch?v=zqhE-CepH2g
I am also miffed that the criticizers of React = PHP are often Rails developers who completely overlook that Rails is PHP on cocaine, it is implicit, untraceable database calls sprinkled across templates, and the more use the worse it gets and it quickly becomes un-optimizable. At least with React API calls are explicit, not magic!
> we've developed solid principles for building UIs
There's not really any substance to this statement or the paragraph it's in. I would skip this article entirely, and I think a much more profound view of this concept is "Mind the Gap" talk by Ryan Florence about dissolving the concept of the network and explicit code needed to manage that: https://www.youtube.com/watch?v=zqhE-CepH2g
I am also miffed that the criticizers of React = PHP are often Rails developers who completely overlook that Rails is PHP on cocaine, it is implicit, untraceable database calls sprinkled across templates, and the more use the worse it gets and it quickly becomes un-optimizable. At least with React API calls are explicit, not magic!
Agreed. I was expecting a technical justification on why they're not the same. After all the buzzwords and empty statements, I'm now more than convinced that they are.
I would say react server components are fundamentally different.
PHP starts off powered by the state on server (database etc) and ends there when it hits the client unless you hand it off to a completely different language/system: JavaScript.
It would be really nice if you could instead keep writing PHP-for-the-client which would let you reuse your templates/PHP code/etc but keep all the state on the client so you can instantly do things without round trips to the server.
That's what RSCs are and they are pretty great IMO.
PHP starts off powered by the state on server (database etc) and ends there when it hits the client unless you hand it off to a completely different language/system: JavaScript.
It would be really nice if you could instead keep writing PHP-for-the-client which would let you reuse your templates/PHP code/etc but keep all the state on the client so you can instantly do things without round trips to the server.
That's what RSCs are and they are pretty great IMO.
I stopped reading after the first laughing emoji
I can only imagine how frustrating it is for the average user when they click on an "unhydrated" button that does nothing. JS frameworks embracing SSR is definitely a step in the right direction compared to the fully client-side apps of the previous hype cycle, and yet in many cases can still present worse UX than PHP sites of yore.
> Now, here's where it gets exciting! We're not going back to PHP
We're moving to PHP++!
We're moving to PHP++!
Php#
If you prefer your full-stack development in Java, definitely check out Flavour. It gives you the benefits this article claims to want but without the weakly-typed languages and all of their attendant footguns:
Flavour book: https://frequal.com/Flavour/book.html
Flavour book: https://frequal.com/Flavour/book.html
It's actually the other way around.
React was originally designed as the PHP on the browser side. Facebook was a php powerhouse, Jordan Walke invented React based on XHP, HHVM, etc.
https://github.com/jordwalke/FaxJs
React was originally designed as the PHP on the browser side. Facebook was a php powerhouse, Jordan Walke invented React based on XHP, HHVM, etc.
https://github.com/jordwalke/FaxJs
It’s still HTML, CSS and something. It’s different but not that different except now you use JS frontend and backend. It’s also not 2002 anymore.
In some ways, React on the server is worse than PHP. Server-side rendering of client-side code adds a ton of complexity, and can even introduce performance issues that must be worked around before the app can be launched (e.g. needing to pre-warm caches).
I'm sure there are valid uses for server-side React, but at the end of the day, using server-side languages such as PHP or Rails (or even rendering pages in Node.JS if you like JavaScript) can be much faster and simpler.
I say this having been involved in an app rewrite that used Remix. The project has taken 2 years (and still isn't quite out), and the engineering leaders who made the decision have agreed that we probably could have rendered most of the pages in Rails and used JavaScript for a limited number of things. With that said. I am hopeful that the project will work well when all is said and done, but there were a lot of tradeoffs associated with going to a server-side rendering framework.
I'm sure there are valid uses for server-side React, but at the end of the day, using server-side languages such as PHP or Rails (or even rendering pages in Node.JS if you like JavaScript) can be much faster and simpler.
I say this having been involved in an app rewrite that used Remix. The project has taken 2 years (and still isn't quite out), and the engineering leaders who made the decision have agreed that we probably could have rendered most of the pages in Rails and used JavaScript for a limited number of things. With that said. I am hopeful that the project will work well when all is said and done, but there were a lot of tradeoffs associated with going to a server-side rendering framework.
what do you mean by performance issues like pre-warming caches? you mean with other backend frameworks you wouldn't have the same issues? or with clientside-only rendering?
The first time you server a page with a SSR-framework, it will be slow, and subsequently it will be fast when it is served from cache.
What I have seen is that, depending on the number of pages and frequency that each page is accessed, it may be necessary to pre-cache some or all of the server-side rendered pages to get good performance.
What I have seen is that, depending on the number of pages and frequency that each page is accessed, it may be necessary to pre-cache some or all of the server-side rendered pages to get good performance.
Define "slow". You shouldn't have to cache every page on your website just to get decent performance. Sounds like something else is wrong.
If your site is in any way dynamic, you won't be able to cache much anyway
If your site is in any way dynamic, you won't be able to cache much anyway
The use case I'm working with right now is eCommerce. Landing pages need to be served as quickly as possible to score highly on various page speed SEO metrics. I have seen a number of server-side implementations that need to have most of the common landing pages cached to score better than client-side rendered pages.
Many of these page renders require calls out to third-party APIs, which is responsible for some of the slowness. There are definitely optimizations that can be performed (e.g. caching the results of the backend APIs). But it's easier for less experienced developers to just cache the whole page with a reasonable TTL.
Also agreed that you won't be able to cache much (or as much) if the user is logged in. Logged in pages matter less for SEO, so we haven't focused too much on it.
Many of these page renders require calls out to third-party APIs, which is responsible for some of the slowness. There are definitely optimizations that can be performed (e.g. caching the results of the backend APIs). But it's easier for less experienced developers to just cache the whole page with a reasonable TTL.
Also agreed that you won't be able to cache much (or as much) if the user is logged in. Logged in pages matter less for SEO, so we haven't focused too much on it.
It's frustrating that when people discuss React on the server or frameworks like Next.js, the conversation rarely acknowledges the performance cost that comes with Server-Side Rendering (SSR). The excitement tends to focus on the benefits like SEO and initial page load performance, but the limitations and potential drawbacks of running JavaScript server-side are often overlooked.
As traffic increases, the server's ability to handle requests diminishes, especially under high loads with complex rendering. This is exacerbated by the fact that each request often requires repeatedly rendering the same React components from scratch, rather than reusing client-side resources.
As traffic increases, the server's ability to handle requests diminishes, especially under high loads with complex rendering. This is exacerbated by the fact that each request often requires repeatedly rendering the same React components from scratch, rather than reusing client-side resources.
I wrote a blog post about this a few years back and got lambasted for daring to question the wisdom of SSR.
That same post still gets plenty of views from people looking up on Google if they should use SSR though.
Doing everything client side means scaling asset delivery is trivial. A potato running nginx can serve an absurdly large number of concurrent users fetching the same static payload.
Those backend apis need their own scaling story, and different types of APIs have very different scaling stories.
What doing some rendering server side and some client side can do is create confusion as to what is done where. (And with particularly bad settings even leak api keys, oops!)
That same post still gets plenty of views from people looking up on Google if they should use SSR though.
Doing everything client side means scaling asset delivery is trivial. A potato running nginx can serve an absurdly large number of concurrent users fetching the same static payload.
Those backend apis need their own scaling story, and different types of APIs have very different scaling stories.
What doing some rendering server side and some client side can do is create confusion as to what is done where. (And with particularly bad settings even leak api keys, oops!)
> , the conversation rarely acknowledges the performance cost that comes with Server-Side Rendering (SSR)
This conversation is so old that most of the people having it already know this implictly so don't consider it even worth mentioning. I know I never do, because I started with things like php which works like that.
This conversation is so old that most of the people having it already know this implictly so don't consider it even worth mentioning. I know I never do, because I started with things like php which works like that.
I've met plenty of devs who have never seen php and who consider server side rendering to be magic because "Vercel takes care of it".
I was just explaining why it's not brought up that often. I wasn't making a claim as to whether it should be more often.
Hah! Fair enough.
I feel like the rush of developers in the last 5-8 years means a lot of history is just unknown.
People get all weird when I mention I self host all my projects for $10 a month on a machine I administer.
Half a core on a modern cheap VPS is equivalent to the massive server machines of the past!
I feel like the rush of developers in the last 5-8 years means a lot of history is just unknown.
People get all weird when I mention I self host all my projects for $10 a month on a machine I administer.
Half a core on a modern cheap VPS is equivalent to the massive server machines of the past!
well of course, but no matter what you do a "server" takes increased load as traffic increases (maybe it's just cheaper and simpler if it's a managed cdn)
you always have the option with react on the server of returning a minimal skeleton and client rendering the rest. the point is you can make those decisions case-by-case
you always have the option with react on the server of returning a minimal skeleton and client rendering the rest. the point is you can make those decisions case-by-case
I keep being puzzled by the SEO argument because google indexes client-side rendered pages just fine. Are there really SEO problems that are solved by SSR?
The initial page load argument is real, but is sort of a self-imposed problem because page loads would be fast if there wasn’t this massive bundle of JS code that’s 95% infrastructure and 5% actual site content.
The initial page load argument is real, but is sort of a self-imposed problem because page loads would be fast if there wasn’t this massive bundle of JS code that’s 95% infrastructure and 5% actual site content.
> I keep being puzzled by the SEO argument because google indexes client-side rendered pages just fine. Are there really SEO problems that are solved by SSR?
In theory, yes, in practice no. I've deployed SPAs for landing pages as well as server-side rendered or statically generated pages, and there was a huge difference in indexing and SEO between the two. Google can say they render client-side pages just the same, but I have not found that to be true at all.
In theory, yes, in practice no. I've deployed SPAs for landing pages as well as server-side rendered or statically generated pages, and there was a huge difference in indexing and SEO between the two. Google can say they render client-side pages just the same, but I have not found that to be true at all.
Mostly because the people still clinging to php are grifters and idiots, in my experience. I guarantee you can't save the php quagmire I was asked to fix.
All this Next.js SSR is just reinventing the wheel again with spaghetti code, only to be fancy and trendy. The next big invention will be template isolation, something that was done many years ago.
Now I'm doing the same thing, and decided to go with Deno because I wanted to learn JavaScript.
Does something like Next replace something like Deno, or does it work with it?