React on the server is not PHP
artmann.co
artmann.co
> 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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
If your site is in any way dynamic, you won't be able to cache much anyway
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.
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.
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 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!
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
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 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.
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.
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.
Are you tired yet?
I took this headline to be a dig against React on the server, but I guess the author intended the opposite.
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).
Here "PHP" is used as a generic term for "whatever crap we called web programming back in the 00s." Or maybe just "WordPress."
Flavour book: https://frequal.com/Flavour/book.html
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).
(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.)
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?
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.
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?
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...
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.)
So I am a mostly happy php developer that still has problems
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.
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!
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 ;)
Surely this is sarcasm...
We're moving to PHP++!