It is important to note that my jQuery code and vanilla JS code are performing what amounts to dangerouslySetInnerHTML operations (in React terms). In the case where you don't know the provenance of the data, or you have not properly sanitized it, this can lead to an XSS vulnerability, though the code shown here does not have an XSS vulnerability because the user input is not reflected. Please take care if you choose to use the JavaScript in the PHP or Rust examples (which is not recommended) to sanitize the code, or to create DOM elements programmatically and only set their innerText to avoid potential for XSS attacks.
Not a fair comarison at all. Far from it. PHP is a bare server language. RSC+React is a library on top of "Javascript" which is a client language. Use laravel-breeze+alpinejs as a library ontop of PHP and see the difference. Thats what will be a fair comparison, not this..
@@VincentUchennaOk Question for you, if I put both of these sites side by side and you were not able to bring up the inspector or view source, if you were able to only interact with it as a regular customer would, could you tell which was which? Would you know which was React and which was PHP? Would just a regular customer using the site care if it was created using React or PHP? From the customer perspective the two apps are the same. Thus, it is a fair comparison. Not all sites are huge mega-complex monstrosities. Not all sites need a framework to build them.
@@jherr That's not my point. I get the fact that they both look alike from a customer point of view. But in terms of technical comparison, it's far from fair. And I feel the pain from most PHP devs right now. Thank God for Laravel, etc.. and all those building tools to make the language most accessible like what nextjs is doing with React. And to look at it more critically, data is every company's business and power, so every Ceo would trust a safe and full featured backend server over a new tech like RSC, than compare frontend technologies. My point is this, every CEO will safely add new frontend tech to their reliable backend, than add new backend tech to their reliable frontend, always... It's inside out, not outside in.. That's why is think this RSC might struggle to take root for long..
Fantastic video Jack! Thanks a lot for taking your time to do this comparison. On a side-note, for heavy PHP users these days there is another library that really shines and it's alpinejs, it's lightweight, fast and integrates easily with php.
@@jherr on that note, the TALL stack is being implemented in my team (tailwind, alpine, laravel and livewire) and I'd be curious to hear about how livewire and alpine look/feel to someone so familiar with the React world such as yourself.
@@marcuss.abildskov7175 you are right but at the same time, in this video Jack used NextJS and compared it to raw PHP, it doesn't make sense either to compare an SSR framework to a full language, but here we are anyway. NextJS offers so little to the development experience in comparison to everything laravel has to offer, it would indeed not be fair to compare both.
Yup, Laravel adds quite the overhead. And maybe use php-fpm with e.g. nginx, since PHPs built-in Webserver is only meant for debugging etc. It's rather slow.
The RSC patterns completely break down when you start to scale up an application. It becomes very difficult to remain consistent in how you use them. We ran into issues where we were just declaring "use client" on most components and only using the RSC as a data fetching layer. This led to issues with prop drilling from the top data component down to child client components. At that point, we just ditched the re-write project for 3 of our big Next apps. People hate getServerSideProps, and I get it, but I'd rather have that implementation over RSCs, as it sets a boundary, and the component receiving those props is just a client component. It just makes way more sense to me. I would look to something like Remix with its action/loader paradigm if I wanted to move away from NextJs, should they sunset pages and gSSP().
Great content, easy to listen to, and highly informative. One thing possibly worth emphasizing further -- Response times or throughput for hello world style cases shouldn't carry too much weight. In many (most?) apps, most of the heavily lifting will be dominated by things outside app code, the database being the most common. So unless maximum performance at pretty much any cost is your goal, something that emphasizes developer productivity for web apps often hits the sweet spot. (i.e., something like PHP for a web app vs. Rust, C, C++). Even from a perspective of placing a high value on performance (see judyrecords for example) it wouldn't be a good choice to write/re-write it in a lower level language to eek out 10ms.
I'm just a junior developer, but I also agree with the "we still don't know the best practices for the relationships between RSC and RCC". I believe, without clear instructions on how to handle these two, it might get messy really quick.
yay I'm just glad people are talking about Php again. I love it and I think it's one of the easiest languages to pick up if you want to start wrapping your mind around server-side!
Although it was a really nice comparison and a wonderful job at it as always from you Jack. I find it hard to really trust any of the data we got simply because a more complex app is needed to accurately measure many of the benchmarks performed in this video. If a base case App is all we care about, then framework builders should make their framework as simplistic as possible, since their out of the box "create--app" will probably be the most performant in that scenario. But then, in a large project, that will no longer be true because of all the extra stuff needed to make a good App. All in all, what I'm trying to say is that this video is likely a "micro-benchmark" scenario that should be taken with a grain of salt. Either way, great job! The video still highlights many ways of accomplishing the task and is a valuable source of information like always from you Jack, keep up the good work!
Hey Jack thanks for all the vids. Super cool to see. One kind of weird comparison is using php dev server. Do you think it would be a much fairer comparison for all to use a proxy server like nginx and runtime/process manager more typical to how node and php are deployed in production services? NGINX -> PHP FPM -> some php stuffs NGINX -> node upstream server via PM2-> some node stuffs You could try an Open Swoole for PHPs server and probably got nearly the same speed of the Rust server form testing I've seen with it. THanks for the vids!
Great video! It is cool to see PHP again as it's what I cut my teeth on back in '08. At work I'm still just using plain old client side react with Vite for the dev server. Since all our features are behind a login, SEO doesn't really matter to us. Also, as cool as all the SSR stuff is, I struggle to see the advantage of switching. We have a lot of complex UI stuff and I wonder how RSC will change it.
Not sure about php, but it is very similar to asp webforms and postback, if you want async components it looks very similar to asp webforms with updatepanel postback, from 2005. The code and approach of react server components and server actions seems very similar.
Really cool video ! I love those stats comparisons ! Rust is really impressive. And I do agree, the more i use the app router, the more i feel frustrated by having small tiny bugs, and I don't always get why is that happening.
1. Thanks for adding my comment in your video. that make my morning 2. at the end of the video, where you show the charts it would be nice that it indicates what result is better (Page Size (Kb) Lower is better), Response Time(s) Lower is better, Request Per second Higher is better) In that way it is clear what is the optimal value on the chart. Thanks!
Fantastic video Jack! Thanks a lot for taking your time to do this comparison. I want to ask you if you can can give us an example about how to setup react server component with express or how to integrate react rsc with existing express app thanks !
Excellent video Jack..!! I think there needs to be rethought in direction major JS frameworks are going. With cut throat competition in JS frameworks space they are just coming up with features which are not well thought out and more of a patchwork. Just look at syntaxes like "use client" and than there are special folders in NextJS with '(' syntax, all this I consider not very mature design. It works but it's not clean. Putting server functionality in client side frameworks is not adding much of a value. The whole JS full stack thing started with developers able to share models and some common functionality between both client and server so both always remain in sync and JS is the only option which is widely supported in both client and server. However, doesn't matter how much optimized JS runtime engines are at the end of the day JS is a "scripting language" and all variables/functions in JS is merely an "associative array". There is nothing much compiler/interpreter can do to get more performance. Just look at perf numbers...languages like PHP which is not known for performance are easily beating JS by miles. Matured systems like Java or .net core will easily beat JS and PHP by miles. In my opinion rather than overengineering this JS frameworks React should continue to improvise on client side and let server side systems handle their things for the better.
Thanks for making this video. It must have taken a lot of time. I still thinks React is going the wrong way. What NextJS is achieving now can be done with simpler code like you showed here. This can still be much better by using AlpineJS or Tubro
What would be the bundle size if instead of using a client component with a server action you just used a server component and filtered the json response using query params?
I think I did a bundle size check pre-client component and the numbers were really close to with the client component. Not using client components does not mean a zero sized bundle. Not even close. It still includes React, and still does hydration. It just hydrates from the JSON payload instead of re-running the client components.
The component model and state management of React is hard to beat. I'm still sticking w/ React, but for now I will have to use the pages dir because the app router is still too slow.
Great illustration of why "view as a product of state" is such an attractive offering. Important lesson for new learners about where we came from and why Nextjs/React w server actions is a huge plus in terms of DX.
Great vid! I was expecting to see "components" being listed as a huge advangtage to PHP, for me that is the killer feature of React. Also I wonder how would affect the results if you used a PHP framework like Laravel or Symfony.
Yeah, that's true. You are correct. That would be the first and primary benefit. I guess I skipped over that to isomorphic rendering of said components.
Hey Jack, Great content, you are among the only few content creators who make videos about intermediate to advance topics. Kudos for that. Can I request a video regarding usage of React query in NextJs App directory?
I'm doing a DevShare presentation at work this week on React Server Components. We have a lot of PHP code at my work. This video is great. We should just sit and watch this instead!
That was a great video Jack, although as an avid PHP fan I was screaming at you for using jQuery so I'm glad you mentioned Vanilla JS towards the end. Very interesting to see that Rust server at the end too. I wonder if there's some future where we use Rust to deliver the SSR'd part of a page and React (or some other framework) on the front to handle the CSR?
Hmmm, that would be tricky because you'd have to get the hydration setup exactly right. Basically the Rust templating code (or whatever) would have to exactly produce the same HTML to match what the JS code is going to do. So you have an even more drastic version of the two languages problem that we have with PHP and we "solved" with isomorphic rendering.
I like Rust but we don't have the DX of Javascript and React, I try using Yew and Leptos for SSR and reloading during development is too slow because we need to compile each time.
I actually plan to refactor my apps to HTMX and alphine, django and just make overkill todo app list with authentication in each front end framework with nextJS, Nuxt, Sveltekit, Etc Etc. incase future job applications wants a sample of those lol. the only constant in JS eco is the changes monthly. instead of correcting some lapses from previous push I ended up updating new version and breaking changes in frontend I'm so tired 😢
So should we move back to PHP and use vanilla js for smaller projects? When no node js server is possible, do you recommend using react like WordPress does in their block editor? Finally, if you are building a php and vanilla js app, do you actually recommend fetching php served pages? Doesn't that take forever every time you make a change?
Do you need to serve thousands of requests per second for your smaller projects? If no, it doesn't matter. WP block editor serializes to html which is then directly rendered by the front-end. There's no relation between the block editor's use of React and what is displayed by the WP template. I would never. If you need an SPA, build a front-end client and REST API. If you just want static pages (e.g. blog), serve them rendered directly with PHP. Put Varnish cache in front if you need to handle russian bots.
The issue is the entire point of react and these types of libs was (at the time) to cut down on server costs, aka moving the work/rendering to the client. Literally the only reason why you would use nextjs or any of the "kit" solutions is if you absolutely *need* good SEO, which entails SSR for search engine discovery and indexing. For small or personal projects, that's not a concern and even past that, searches are starting to adapt to single page apps. In other words, use your favorite framework to make SPAs and a barebones backend to serve the files and return basic blobs of json. I can elaborate on my stack if you want, but if you do roughly as I mentioned you can run a 15$ a month vps that can handle roughly 1000x the traffic nextjs does.
WP "Gutenberg" is probably the worst experience of using React I have ever had-and I am not even talking about the outdated tooling, which I have replaced myself with a custom Vite plugin.
Am I wrong in saying that you are comparing a full frontend framework with jquery which has no data binding? Like mentioned by others use alpine, htmx or at least some jquery plugin for data binding. But yes hard to beat RSC in react
there are lots of ways of do somenthing in web development or in software in general, I guess you have to put in a weighing what you need, what you want, ex: performance, friendliness development, eco system, all that dependent on you and your team, and it can change overtime, I'm sure there is a good reason of why multiple companies started its projects with ruby on rails regardless it wasn't super popular, like everything in the life it depends.
It has similar performance numbers to pages in terms of raw throughput. Better TTI though than React. Not as good as the vanilla JS version, since even with its aggressive lazy loading it's not going to be lower than 0.4Kb.
Hi Mr. Herrington, few things to say by being honest and transparent; 1. When devs are comparing Nextjs and RSCs to PHP is in terms of DX, which means you are mixing business server logic ( sql queries, etc) in same file with view / presentation client layer (with interactivity + jsx). Since react release state in functional components was already bad, because you are also are mix business logic (interactivity logic) with presentation layer (jsx) in client side. In PHP you can and should do that separation where in NextJS at the moment you can not, similar like SvelteKit and NuxtJS do, by create a separated only for server logic. 2.Make no sense comparing server only language (Vannila PHP) with js runtime nodeJS framework like NextJS (Which include a client side framework / lib like react), And what you made with PHP is not secure because of XSS and the same on jquery and vanilla js. Where NerxtJS since is a framework and using jsx, is safe. 3.Why using php built in server when in real world you use server like Apache http or ngnix with PHP interpreter ? Also make no sense. And you should mention the version of PHP. 4. Why not comparing Vanilla PHP ( like said in point 2 make not sense) with React client side instead of jquery or vanilla js? 5. From start this comparison make no sense, however a transparent comparison would be using a php framework like Laravel or Symfony with and without react, which would be save to XSS in this case also. Beside when you bring rust to this, you dint with vanilla rust, you use frameworks too. So ya just another foot gun. So in this simple example, what is the point of using nextjs, when you can use vanilla PHP with Vanilla js which are pretty fast, slim and easy to use and even can save some money with hosting and in human resources. JS ecosystem are AWESOME . LOL.
Outside of #3 I disagree, from the customer perspective all three of these web experiences are symmetric and therefor comparisons can be made fairly. Your argument seems to boil down to PHP isn't comparable to NodeJS because it's not JS.
@@jherr I think you didnt understand the point #1. And you are not comparing PHP vs NodeJS. Which itself, at least for, also make no sense comparing a language with a run time, Even worse you are comparing Vanilla PHP with a nodeJS framework, nextjs which include reactjs. like i mention in #2. Sorry but i am not the only one mention this, just read other comments. And read my #5 if you want to be fair.
@@jediampm I hear you, but you aren't addressing my point that, within the confines of this simple app, from the customers perspective they are symmetric and therefor comparable. As for the security and XSS, what is the actual exploitable vector for an attack outside of a man in the middle attack.
@@jherr Why you mention customers, like people that use the app ? I am talking in devs perspective with DX in mind. comparing and making an app with vanilla way, only with pure PHP to a nodeJS framework make no sense , period. It like comparing nodeJS to NextJS, make no sense too. When i mention #5, i mean in terms of comparison, compare nextjs to Laravel + livewire, for example, so between frameworks. And when you use a frameworks also are avoiding XSS in this kind of examples. And you didnt mention why not PHP with React LOL.
@@jediampm So a comparison is only fair when you have a similarly heafty framework to weigh down the client? The fact that the application still works and runs as expected to the customer means nothing?
Perhaps filtering is not the best use case to illustrate server actions. I believe filtering, at least at low-medium scale, should be done fully on client. If we send all initial data on first request and keep it on client, there is no need to make additional requests and make server do extra work. And, depending on scale of our data, multiple searches could result in much bigger data transferred than full data set on initial load. For performance I can suggest looking into bun runtime. It can be used to make fast api server, but it is still in development, so it cannot run entire frameworks in its own runtime yet.
Great video. Why does your PHP script fetches a json file over HTTP for every request? For much better performance, this json file could be fetched directly from a file without calling another webserver. The performance would then be much faster.
React actually did always look like PHP but it was client side. The re-render of the page when you POST new data is what the virtual dom emulates but in a better and more efficient way. PHP isn't bad because of how you could render templates, it was bad because of PHP the language and finicky environment it ran on.
However in case of PHP as language, the fault is on Developer for not separating business logic from presentation layer. Where in case of React is a choice of the creator since the release of functional components with state you have that look of mix . It easy to point out the fault to the language instead of the dev choices. LOL
@@jediampm I'm thinking more about how PHP was a language that had no real design direction and was just a haphazard pile of awkwardly implemented functions around C code. It's better now though but hard to get away from legacy code.
@@jherr I appreciate the distinctions you tried to make in this video, but I think often a times people promote this notion that "JavaScript apps are fast and php is slow" without really making an accurate comparison between the two. I've done a bit of work in both ecosystems. From my point of view the Laravel way offers a lot more than the full JS ecosystems. Also I don't think that the JS ecosystems are just naturally more performant. What is more important is just how you build your app.
While the PHP example is fine, I feel like we would need an actual real-world example using a framework to make it apples to apples. As for Rust, rocket is great, although if your really want performance then actix is something mindblowing :)
In general the PHP approach is pretty slick and simple. The problem I have with it is DX and docs. They are highly inferior to JS frameworks. Furthermore the frontend feels "decoupled" in a bad way, since you have your code spread across many places. Template file, js, CSS, PHP controller, ... And then there's the highly discussed scaling issue. On every request, everything is bootstrapped and run. Sounds like a ton of overhead to me. In the plus side your server is basically idle when there is no request. I can confirm the large Drupal apps slow. That's why these projects tend to have a lot of caching. Laravel Livewire might be a solution to this. I didn't try it, but I doubt that it handles reactive rendering as well as a js framework
Well, as it turns out this video is getting some Rust love. Someone has already given another implementation of the Rust example, this time using Axum, and it's up in the repo now.
Nowadays it is no longer necessary to use jQuery, javascript has been greatly improved, I always prefer to write vanilla javascript than to include a lot of code that is not fully used.
If you watched all the way to the end I use vanilla JS instead of jQuery. And I updated the code on the github repository to do it without using innerHTML and it's still really small.
IMHO, probably going to end up somewhere between NextJS pages and PHP. There is an upward bound on the amount of speed you can get out of a Node server.
Who cares? Data source is a json file distributed with the app. If you can rewrite that, setting html is the least of your worries. Also good luck finding a SQL injection in a static file ro DB lol.
what theme you using for vscode? i think for smaller and simpler project php is simpler and good but for bigger projects you need react,vue. using php so nice to see on yt. nice video :)
What drives me nut is the cost of hosting a nextjs application. But with php you can host your application on a shared hosting- just copy your files and paste.
FWIW, I really don't know Rust, I used a combination of ChatGPT, Stack overflow, API documentation and... engineering skill. To just kinda wing it. Turns out it wasn't entirely terrible. On the plus side that experience gave me a lot of confidence that AI is still just a tool and not a replacement. There is no way I could have done that without being an engineer with previous experience in C/C++, Go, Rust (a little), Java, etc.
Thats actually quite an easy question to answer if you think about what the app directory is doing. Something that hasn't really been discussed in the comparison is that app directory removes all bundled javascript so the page is significantly smaller than the pages version. if you have real data heavy pages then sure the initial page load my be slightly slower but the overall performance of the page will be much much quicker. All that logic to work out the dependency tree on server vs client components must have an overhead.
"app directory removes all bundled javascript", that's actually not the case. Even when the app was RSC only at the start it was still a ~80Kb release bundle which is run on startup to hydrate the client. The difference is that with the App Router the hydration uses the VDOM serialized as JSON at the bottom of the page. And with the pages model the application is re-run on the client with the serialized data from getServerSideProps in order to do the hydration.
PHP is honestly better than RSC/Nextjs for the mental model they are going for. I feel like React/Nextjs strengths are still for creating a minimally hydrated SPA with fast interactions. If we were to compare interaction speeds with a json api call, it should be better than PHP or RSC. RSC are currently the worst of both worlds. If I want fast interactions I would go for a SPA. If I want fast page loads I would go for static/PHP/Rust
Yeah. I probably took it a bit more literally than that. :P But because this is such a React channel I did want to show some kind of drastically different alternatives. I see React being misused a reasonable amount. I don't mean bugs, I just mean "I wouldn't have used React for this site." And the alternatives aren't bad. And things like Laravel's Hotwire are, in their own right, very cool and potentially a better fit for a lot of applications.
I love the examples but is this comparison fair? PHP's built-in server is way slower than using nginx or even apache. I think the metrics will be a 🤏 different if used with nginx. Of couse, rust is still going to dominate.
JSX is just unrivaled tech for HTML construction: (1) XSS-safe by default and ensures proper construction of (2) attributes and (3) tags. A huge part of what makes PHP annoying is needing a template language for 1 and you can still mess up 2 and 3.
Last I looked to get the speedups from Bun the server needed to use specific extension points in Bun, and nothing yet had done that. Could be wrong though.
PHP is nice until you need to return UI from some function. Either you return a string mess, or you opt into output buffering which has its own footguns or end up with some templating abstraction with indirections. There's a reason why XHP and later JSX was invented :)
@@yungifez Yes, but then you're using a framework just like using React/NextJS. My point was that the comparison with RSC and PHP doesn't make much sense, even just for templating. RSC definitely has the upper-hand there.
It is important to note that my jQuery code and vanilla JS code are performing what amounts to dangerouslySetInnerHTML operations (in React terms). In the case where you don't know the provenance of the data, or you have not properly sanitized it, this can lead to an XSS vulnerability, though the code shown here does not have an XSS vulnerability because the user input is not reflected.
Please take care if you choose to use the JavaScript in the PHP or Rust examples (which is not recommended) to sanitize the code, or to create DOM elements programmatically and only set their innerText to avoid potential for XSS attacks.
Not a fair comarison at all. Far from it. PHP is a bare server language. RSC+React is a library on top of "Javascript" which is a client language. Use laravel-breeze+alpinejs as a library ontop of PHP and see the difference. Thats what will be a fair comparison, not this..
@@VincentUchennaOk Question for you, if I put both of these sites side by side and you were not able to bring up the inspector or view source, if you were able to only interact with it as a regular customer would, could you tell which was which? Would you know which was React and which was PHP? Would just a regular customer using the site care if it was created using React or PHP? From the customer perspective the two apps are the same. Thus, it is a fair comparison. Not all sites are huge mega-complex monstrosities. Not all sites need a framework to build them.
@@jherr That's not my point. I get the fact that they both look alike from a customer point of view. But in terms of technical comparison, it's far from fair. And I feel the pain from most PHP devs right now. Thank God for Laravel, etc.. and all those building tools to make the language most accessible like what nextjs is doing with React.
And to look at it more critically, data is every company's business and power, so every Ceo would trust a safe and full featured backend server over a new tech like RSC, than compare frontend technologies. My point is this, every CEO will safely add new frontend tech to their reliable backend, than add new backend tech to their reliable frontend, always...
It's inside out, not outside in..
That's why is think this RSC might struggle to take root for long..
Exactly what I was thinking. Why are we comparing a meta framework with simple PHP and jQuery 😅
Just use laravel + livewire.
The content of the table can be put in a and work with that so the headings dont need to be put each time.
Fantastic video Jack! Thanks a lot for taking your time to do this comparison.
On a side-note, for heavy PHP users these days there is another library that really shines and it's alpinejs, it's lightweight, fast and integrates easily with php.
I will check that out! Thank you!
@@jherr on that note, the TALL stack is being implemented in my team (tailwind, alpine, laravel and livewire) and I'd be curious to hear about how livewire and alpine look/feel to someone so familiar with the React world such as yourself.
@@jherrplease compare laraval vs next js
They got nothing to do with each other lol
@@marcuss.abildskov7175 you are right but at the same time, in this video Jack used NextJS and compared it to raw PHP, it doesn't make sense either to compare an SSR framework to a full language, but here we are anyway.
NextJS offers so little to the development experience in comparison to everything laravel has to offer, it would indeed not be fair to compare both.
I think would be cooler to compare nextjs to laravel
Yup, Laravel adds quite the overhead. And maybe use php-fpm with e.g. nginx, since PHPs built-in Webserver is only meant for debugging etc. It's rather slow.
I would love to see this too
I agree
@Shadow how about using fetch
@Shadow use livewire component
The RSC patterns completely break down when you start to scale up an application. It becomes very difficult to remain consistent in how you use them. We ran into issues where we were just declaring "use client" on most components and only using the RSC as a data fetching layer. This led to issues with prop drilling from the top data component down to child client components. At that point, we just ditched the re-write project for 3 of our big Next apps. People hate getServerSideProps, and I get it, but I'd rather have that implementation over RSCs, as it sets a boundary, and the component receiving those props is just a client component. It just makes way more sense to me. I would look to something like Remix with its action/loader paradigm if I wanted to move away from NextJs, should they sunset pages and gSSP().
Yeah the loader paradigm is sweet.
Great content, easy to listen to, and highly informative. One thing possibly worth emphasizing further -- Response times or throughput for hello world style cases shouldn't carry too much weight. In many (most?) apps, most of the heavily lifting will be dominated by things outside app code, the database being the most common. So unless maximum performance at pretty much any cost is your goal, something that emphasizes developer productivity for web apps often hits the sweet spot. (i.e., something like PHP for a web app vs. Rust, C, C++). Even from a perspective of placing a high value on performance (see judyrecords for example) it wouldn't be a good choice to write/re-write it in a lower level language to eek out 10ms.
I'm just a junior developer, but I also agree with the "we still don't know the best practices for the relationships between RSC and RCC". I believe, without clear instructions on how to handle these two, it might get messy really quick.
React in a nutshell. Garbage library m
@@marcuss.abildskov7175 BS
Some other framework will figure it out eventually and react will clone it within 1year
yay I'm just glad people are talking about Php again. I love it and I think it's one of the easiest languages to pick up if you want to start wrapping your mind around server-side!
I love that the investigation gets wayyyyyyy more in depth as the video progresses 😂 good stuff!
At the end Jack simply brought the absolute boss Rust lmao
Although it was a really nice comparison and a wonderful job at it as always from you Jack. I find it hard to really trust any of the data we got simply because a more complex app is needed to accurately measure many of the benchmarks performed in this video. If a base case App is all we care about, then framework builders should make their framework as simplistic as possible, since their out of the box "create--app" will probably be the most performant in that scenario. But then, in a large project, that will no longer be true because of all the extra stuff needed to make a good App. All in all, what I'm trying to say is that this video is likely a "micro-benchmark" scenario that should be taken with a grain of salt.
Either way, great job! The video still highlights many ways of accomplishing the task and is a valuable source of information like always from you Jack, keep up the good work!
Hey Jack thanks for all the vids. Super cool to see. One kind of weird comparison is using php dev server. Do you think it would be a much fairer comparison for all to use a proxy server like nginx and runtime/process manager more typical to how node and php are deployed in production services?
NGINX -> PHP FPM -> some php stuffs
NGINX -> node upstream server via PM2-> some node stuffs
You could try an Open Swoole for PHPs server and probably got nearly the same speed of the Rust server form testing I've seen with it.
THanks for the vids!
Hmmm, good to know! I'll check that out.
Great video! It is cool to see PHP again as it's what I cut my teeth on back in '08. At work I'm still just using plain old client side react with Vite for the dev server. Since all our features are behind a login, SEO doesn't really matter to us. Also, as cool as all the SSR stuff is, I struggle to see the advantage of switching. We have a lot of complex UI stuff and I wonder how RSC will change it.
Thank you for this. I will refer our PM and techlead to this video once I propose rewriting everything in Rust!
I think people were saying it's similar to modern php with Laravel and htmx/livewire. Not similar to old school php with jQuery.
Not sure about php, but it is very similar to asp webforms and postback, if you want async components it looks very similar to asp webforms with updatepanel postback, from 2005. The code and approach of react server components and server actions seems very similar.
Really cool video ! I love those stats comparisons !
Rust is really impressive. And I do agree, the more i use the app router, the more i feel frustrated by having small tiny bugs, and I don't always get why is that happening.
1. Thanks for adding my comment in your video. that make my morning
2. at the end of the video, where you show the charts it would be nice that it indicates what result is better (Page Size (Kb)
Lower is better), Response Time(s)
Lower is better, Request Per second
Higher is better)
In that way it is clear what is the optimal value on the chart.
Thanks!
Fair.
Fantastic video Jack! Thanks a lot for taking your time to do this comparison.
I want to ask you if you can can give us an example about how to setup react server component with express or how to integrate react rsc with existing express app
thanks !
Really well made video!
Excellent video Jack..!! I think there needs to be rethought in direction major JS frameworks are going. With cut throat competition in JS frameworks space they are just coming up with features which are not well thought out and more of a patchwork. Just look at syntaxes like "use client" and than there are special folders in NextJS with '(' syntax, all this I consider not very mature design. It works but it's not clean. Putting server functionality in client side frameworks is not adding much of a value. The whole JS full stack thing started with developers able to share models and some common functionality between both client and server so both always remain in sync and JS is the only option which is widely supported in both client and server. However, doesn't matter how much optimized JS runtime engines are at the end of the day JS is a "scripting language" and all variables/functions in JS is merely an "associative array". There is nothing much compiler/interpreter can do to get more performance. Just look at perf numbers...languages like PHP which is not known for performance are easily beating JS by miles. Matured systems like Java or .net core will easily beat JS and PHP by miles. In my opinion rather than overengineering this JS frameworks React should continue to improvise on client side and let server side systems handle their things for the better.
Agreed
Impressive, very nice. Let's see Paul Allen's performance comparison.
So the Microsoft Paul Allen? Or some other guy?
A movie character played by the B-lister Jared Leto.
Love that meme
Lmao 🤣🤣🤣 you're commenting this in every one of Jack's videos.
@@jherr american physco movie starring Christian Bale
Thanks for making this video. It must have taken a lot of time.
I still thinks React is going the wrong way. What NextJS is achieving now can be done with simpler code like you showed here.
This can still be much better by using AlpineJS or Tubro
Tom uses PHP
What would be the bundle size if instead of using a client component with a server action you just used a server component and filtered the json response using query params?
I think I did a bundle size check pre-client component and the numbers were really close to with the client component. Not using client components does not mean a zero sized bundle. Not even close. It still includes React, and still does hydration. It just hydrates from the JSON payload instead of re-running the client components.
The component model and state management of React is hard to beat. I'm still sticking w/ React, but for now I will have to use the pages dir because the app router is still too slow.
Thank you for including Rust (again)!
Great illustration of why "view as a product of state" is such an attractive offering. Important lesson for new learners about where we came from and why Nextjs/React w server actions is a huge plus in terms of DX.
Yep, I still use pages for any project and will continue to use. It just makes sense
Nice Jack, i love your channel :)
What Pokémon is your favorite though? 🧐🧐🧐
Paras. Hahahaha.
thank you! great video as always
Great vid! I was expecting to see "components" being listed as a huge advangtage to PHP, for me that is the killer feature of React. Also I wonder how would affect the results if you used a PHP framework like Laravel or Symfony.
Yeah, that's true. You are correct. That would be the first and primary benefit. I guess I skipped over that to isomorphic rendering of said components.
Thanks a lot for an interesting comparison!
Hey Jack,
Great content, you are among the only few content creators who make videos about intermediate to advance topics. Kudos for that.
Can I request a video regarding usage of React query in NextJs App directory?
Clean breakdown thanks! I agree with on not adopting App router coding pattern yet.
2 things you left out, general hosting cost and hard disk space needed... there is a massive difference right there spoiler PHP wins both!
The idea is to compare performance, not costs.
is this like server/api in nuxt 3?
Laravel with Livewire would have been a nice comparison for the PHP side. Nice video though
Livewire is always send request for every states action.
love your honesty!
In long term, the state management would exist on rust too no ? A fullstack framework as nextjs is but with rust instead of node ?
I'm doing a DevShare presentation at work this week on React Server Components. We have a lot of PHP code at my work. This video is great. We should just sit and watch this instead!
5:46 TIL you can await and receive data from a server action.
Sad but true, the decision for all is based purely on job market. Not tech. Unless PHP starts to get more views on youtube.
what year is this?
That was a great video Jack, although as an avid PHP fan I was screaming at you for using jQuery so I'm glad you mentioned Vanilla JS towards the end.
Very interesting to see that Rust server at the end too. I wonder if there's some future where we use Rust to deliver the SSR'd part of a page and React (or some other framework) on the front to handle the CSR?
Hmmm, that would be tricky because you'd have to get the hydration setup exactly right. Basically the Rust templating code (or whatever) would have to exactly produce the same HTML to match what the JS code is going to do. So you have an even more drastic version of the two languages problem that we have with PHP and we "solved" with isomorphic rendering.
@@jherr That's a very good point, maintaining 2 sets of code producing the same outputs is not a simple endeavour!
I like Rust but we don't have the DX of Javascript and React, I try using Yew and Leptos for SSR and reloading during development is too slow because we need to compile each time.
Thanks Jack!😊
I actually plan to refactor my apps to HTMX and alphine, django and just make overkill todo app list with authentication in each front end framework with nextJS, Nuxt, Sveltekit, Etc Etc. incase future job applications wants a sample of those lol. the only constant in JS eco is the changes monthly. instead of correcting some lapses from previous push I ended up updating new version and breaking changes in frontend I'm so tired 😢
I worked with PHP once for a project in December, figured out how to use it within a day or two just basic crud didn't know it was this performant.
So should we move back to PHP and use vanilla js for smaller projects?
When no node js server is possible, do you recommend using react like WordPress does in their block editor?
Finally, if you are building a php and vanilla js app, do you actually recommend fetching php served pages? Doesn't that take forever every time you make a change?
Do you need to serve thousands of requests per second for your smaller projects? If no, it doesn't matter.
WP block editor serializes to html which is then directly rendered by the front-end. There's no relation between the block editor's use of React and what is displayed by the WP template.
I would never. If you need an SPA, build a front-end client and REST API. If you just want static pages (e.g. blog), serve them rendered directly with PHP. Put Varnish cache in front if you need to handle russian bots.
The issue is the entire point of react and these types of libs was (at the time) to cut down on server costs, aka moving the work/rendering to the client.
Literally the only reason why you would use nextjs or any of the "kit" solutions is if you absolutely *need* good SEO, which entails SSR for search engine discovery and indexing.
For small or personal projects, that's not a concern and even past that, searches are starting to adapt to single page apps.
In other words, use your favorite framework to make SPAs and a barebones backend to serve the files and return basic blobs of json.
I can elaborate on my stack if you want, but if you do roughly as I mentioned you can run a 15$ a month vps that can handle roughly 1000x the traffic nextjs does.
WP "Gutenberg" is probably the worst experience of using React I have ever had-and I am not even talking about the outdated tooling, which I have replaced myself with a custom Vite plugin.
This is a great video but as a side tangent, does it bother anyone else that he doesn't use a semantic Table element instead of Divs?
Am I wrong in saying that you are comparing a full frontend framework with jquery which has no data binding? Like mentioned by others use alpine, htmx or at least some jquery plugin for data binding. But yes hard to beat RSC in react
I think the ending of this video is a perfect segue into the video Theo did over on his channel: ua-cam.com/video/2Z4fZtSKlcE/v-deo.html
looking forward to the interview with ryan!
there are lots of ways of do somenthing in web development or in software in general, I guess you have to put in a weighing what you need, what you want, ex: performance, friendliness development, eco system, all that dependent on you and your team, and it can change overtime, I'm sure there is a good reason of why multiple companies started its projects with ruby on rails regardless it wasn't super popular, like everything in the life it depends.
Why isn't qwik used anywhere in the comparisons???
It has similar performance numbers to pages in terms of raw throughput. Better TTI though than React. Not as good as the vanilla JS version, since even with its aggressive lazy loading it's not going to be lower than 0.4Kb.
@@jherr Nice work Jack. Appreciate your contents. 🤝
Should we use edge in next js real world projects can you make a video on it
Hi Mr. Herrington, few things to say by being honest and transparent;
1. When devs are comparing Nextjs and RSCs to PHP is in terms of DX, which means you are mixing business server logic ( sql queries, etc) in same file with view / presentation client layer (with interactivity + jsx). Since react release state in functional components was already bad, because you are also are mix business logic (interactivity logic) with presentation layer (jsx) in client side. In PHP you can and should do that separation where in NextJS at the moment you can not, similar like SvelteKit and NuxtJS do, by create a separated only for server logic.
2.Make no sense comparing server only language (Vannila PHP) with js runtime nodeJS framework like NextJS (Which include a client side framework / lib like react), And what you made with PHP is not secure because of XSS and the same on jquery and vanilla js. Where NerxtJS since is a framework and using jsx, is safe.
3.Why using php built in server when in real world you use server like Apache http or ngnix with PHP interpreter ? Also make no sense. And you should mention the version of PHP.
4. Why not comparing Vanilla PHP ( like said in point 2 make not sense) with React client side instead of jquery or vanilla js?
5. From start this comparison make no sense, however a transparent comparison would be using a php framework like Laravel or Symfony with and without react, which would be save to XSS in this case also. Beside when you bring rust to this, you dint with vanilla rust, you use frameworks too. So ya just another foot gun.
So in this simple example, what is the point of using nextjs, when you can use vanilla PHP with Vanilla js which are pretty fast, slim and easy to use and even can save some money with hosting and in human resources. JS ecosystem are AWESOME . LOL.
Outside of #3 I disagree, from the customer perspective all three of these web experiences are symmetric and therefor comparisons can be made fairly. Your argument seems to boil down to PHP isn't comparable to NodeJS because it's not JS.
@@jherr I think you didnt understand the point #1. And you are not comparing PHP vs NodeJS. Which itself, at least for, also make no sense comparing a language with a run time, Even worse you are comparing Vanilla PHP with a nodeJS framework, nextjs which include reactjs. like i mention in #2. Sorry but i am not the only one mention this, just read other comments. And read my #5 if you want to be fair.
@@jediampm I hear you, but you aren't addressing my point that, within the confines of this simple app, from the customers perspective they are symmetric and therefor comparable.
As for the security and XSS, what is the actual exploitable vector for an attack outside of a man in the middle attack.
@@jherr Why you mention customers, like people that use the app ? I am talking in devs perspective with DX in mind. comparing and making an app with vanilla way, only with pure PHP to a nodeJS framework make no sense , period. It like comparing nodeJS to NextJS, make no sense too.
When i mention #5, i mean in terms of comparison, compare nextjs to Laravel + livewire, for example, so between frameworks. And when you use a frameworks also are avoiding XSS in this kind of examples. And you didnt mention why not PHP with React LOL.
@@jediampm So a comparison is only fair when you have a similarly heafty framework to weigh down the client? The fact that the application still works and runs as expected to the customer means nothing?
Perhaps filtering is not the best use case to illustrate server actions. I believe filtering, at least at low-medium scale, should be done fully on client. If we send all initial data on first request and keep it on client, there is no need to make additional requests and make server do extra work. And, depending on scale of our data, multiple searches could result in much bigger data transferred than full data set on initial load.
For performance I can suggest looking into bun runtime. It can be used to make fast api server, but it is still in development, so it cannot run entire frameworks in its own runtime yet.
Can you do a vid on incrementally changing components from using the pages dir to the app dir?
Sadly I don't think anyone has really good best practices for that. Those are evolving day-to-day. And the App Router is still evolving.
RSC and RQ next video?
YOU DID IT, YOU TOOK MY RECOMMENDATION TO DO SOME RUST!!!!!!!!!!! wooooooooooooooooooo
Great video. Why does your PHP script fetches a json file over HTTP for every request? For much better performance, this json file could be fetched directly from a file without calling another webserver. The performance would then be much faster.
The request of a JSON payload is meant to imitate a backend microservice.
@@jherr Ok, thanks for your feedback.
React actually did always look like PHP but it was client side. The re-render of the page when you POST new data is what the virtual dom emulates but in a better and more efficient way. PHP isn't bad because of how you could render templates, it was bad because of PHP the language and finicky environment it ran on.
However in case of PHP as language, the fault is on Developer for not separating business logic from presentation layer. Where in case of React is a choice of the creator since the release of functional components with state you have that look of mix .
It easy to point out the fault to the language instead of the dev choices. LOL
@@jediampm I'm thinking more about how PHP was a language that had no real design direction and was just a haphazard pile of awkwardly implemented functions around C code. It's better now though but hard to get away from legacy code.
You there's a `` tag for tables, right? 😛
You can still get all of the React (or anyother SPA) library benefits if you create your APIs in PHP and use an SPA library on the front-end.
Another fair point. You are on a roll!
@@jherr I appreciate the distinctions you tried to make in this video, but I think often a times people promote this notion that "JavaScript apps are fast and php is slow" without really making an accurate comparison between the two.
I've done a bit of work in both ecosystems. From my point of view the Laravel way offers a lot more than the full JS ecosystems.
Also I don't think that the JS ecosystems are just naturally more performant. What is more important is just how you build your app.
@@mgs_4k198 I think the video shows in all cases PHP being faster.
While the PHP example is fine, I feel like we would need an actual real-world example using a framework to make it apples to apples. As for Rust, rocket is great, although if your really want performance then actix is something mindblowing :)
A viewer added an axum version and it's apparently 3X faster than rocket.
Axum ❤
anyone else having Vietnam flashbacks from seeing jQuery?
Jack it's a request if possible can u make a video about making our own server component setup..and also explaining how RSC is working....🙏🙏🙏🙏
In general the PHP approach is pretty slick and simple. The problem I have with it is DX and docs. They are highly inferior to JS frameworks. Furthermore the frontend feels "decoupled" in a bad way, since you have your code spread across many places. Template file, js, CSS, PHP controller, ...
And then there's the highly discussed scaling issue. On every request, everything is bootstrapped and run. Sounds like a ton of overhead to me. In the plus side your server is basically idle when there is no request.
I can confirm the large Drupal apps slow. That's why these projects tend to have a lot of caching.
Laravel Livewire might be a solution to this. I didn't try it, but I doubt that it handles reactive rendering as well as a js framework
Wow! I guess it's about time i migrate my NextJs app to PHP :)
I’ll still use app router since that’s the only thing I know 😅, would be amazing to learn that rust tho. Any tips for a good video on it ? ❤🎉
Well, as it turns out this video is getting some Rust love. Someone has already given another implementation of the Rust example, this time using Axum, and it's up in the repo now.
Nowadays it is no longer necessary to use jQuery, javascript has been greatly improved, I always prefer to write vanilla javascript than to include a lot of code that is not fully used.
If you watched all the way to the end I use vanilla JS instead of jQuery. And I updated the code on the github repository to do it without using innerHTML and it's still really small.
i would LOVE to see same metrics with solidjs too with signals😢
IMHO, probably going to end up somewhere between NextJS pages and PHP. There is an upward bound on the amount of speed you can get out of a Node server.
9:23 Thank you so much for this! I was hoping for SQL injection in the PHP version, but XSS voluntarily is good choice as well 🎉
How is that XSS?
@@cristianbilu thank you for this reply as well, brings so much joy to my little heart
But who builds with vanilla php anyway? Symfony supremacy! :'D
Who cares? Data source is a json file distributed with the app. If you can rewrite that, setting html is the least of your worries. Also good luck finding a SQL injection in a static file ro DB lol.
ya. this why you should always use a framework, to avoid XSS and SQL injection
what theme you using for vscode? i think for smaller and simpler project php is simpler and good but for bigger projects you need react,vue. using php so nice to see on yt. nice video :)
Can you make a video on your vs code setup
What drives me nut is the cost of hosting a nextjs application. But with php you can host your application on a shared hosting- just copy your files and paste.
php save people life. so hate if you want to hate php. but i will use php no matter what.
Rust and Vanilla JS seems like a killer combo, of course, if you know Rust
FWIW, I really don't know Rust, I used a combination of ChatGPT, Stack overflow, API documentation and... engineering skill. To just kinda wing it. Turns out it wasn't entirely terrible. On the plus side that experience gave me a lot of confidence that AI is still just a tool and not a replacement. There is no way I could have done that without being an engineer with previous experience in C/C++, Go, Rust (a little), Java, etc.
add solid to the comparison
a comparison with sveltekit would also be interesting
The question is..why app dir lose everything against pages dir?😢
Thats actually quite an easy question to answer if you think about what the app directory is doing. Something that hasn't really been discussed in the comparison is that app directory removes all bundled javascript so the page is significantly smaller than the pages version. if you have real data heavy pages then sure the initial page load my be slightly slower but the overall performance of the page will be much much quicker. All that logic to work out the dependency tree on server vs client components must have an overhead.
"app directory removes all bundled javascript", that's actually not the case. Even when the app was RSC only at the start it was still a ~80Kb release bundle which is run on startup to hydrate the client. The difference is that with the App Router the hydration uses the VDOM serialized as JSON at the bottom of the page. And with the pages model the application is re-run on the client with the serialized data from getServerSideProps in order to do the hydration.
Could you make a video about Rusts Sledgehammer framework?
laravel with inertia gives isomorphic rendering by doing everything in vue/react/svelte
Please compare to server rendering in Marko and Qwik :)
PHP is honestly better than RSC/Nextjs for the mental model they are going for. I feel like React/Nextjs strengths are still for creating a minimally hydrated SPA with fast interactions. If we were to compare interaction speeds with a json api call, it should be better than PHP or RSC. RSC are currently the worst of both worlds. If I want fast interactions I would go for a SPA. If I want fast page loads I would go for static/PHP/Rust
If you want highly dynamic site? Then you have to go with RSC, even if SSR is slower right now, you have more things like Streaming, Static etc
It was legit & had a great discussion ❤
well you're not comparing the same thing if you're comparing php to nextjs one is a language the other is a framework.
I think when people say "it's just like php" they are really trying to say: the stuff is too tightly coupled and has no clear separation of concerns.
Yeah. I probably took it a bit more literally than that. :P But because this is such a React channel I did want to show some kind of drastically different alternatives. I see React being misused a reasonable amount. I don't mean bugs, I just mean "I wouldn't have used React for this site." And the alternatives aren't bad. And things like Laravel's Hotwire are, in their own right, very cool and potentially a better fit for a lot of applications.
@@jherr haha you showed well! Love it! Undercover PHP developer. 😁
@@ravenbergdev I'm just a fullstack web developer. Some days that means I'm a React developer, sometimes Solid, sometimes... whatever.
Really wish you used Alpine instead of jQuery. The comparison would've been a lot more analagous. Also... maybe even Laravel Livewire?
Yeah, livewire is hella cool.
I love the examples but is this comparison fair? PHP's built-in server is way slower than using nginx or even apache. I think the metrics will be a 🤏 different if used with nginx. Of couse, rust is still going to dominate.
JSX is just unrivaled tech for HTML construction: (1) XSS-safe by default and ensures proper construction of (2) attributes and (3) tags. A huge part of what makes PHP annoying is needing a template language for 1 and you can still mess up 2 and 3.
What about Bun.Js ?
Last I looked to get the speedups from Bun the server needed to use specific extension points in Bun, and nothing yet had done that. Could be wrong though.
@@jherr maybe Bun will be ready next year
I would still prefer NextJS. Though, Rust looks fine, I am not a big fan of blowers.
Blowers?
Using JQuery created a bit of an unfair comparison. AlpineJS would've made more sense here.
I did go with vanilla JS later on and that's 0.4Kb. But ok, I'll redo with Alpine and post a short with an update.
PHP is nice until you need to return UI from some function. Either you return a string mess, or you opt into output buffering which has its own footguns or end up with some templating abstraction with indirections. There's a reason why XHP and later JSX was invented :)
Livewireee would help with this
Coupled with alpine
@@yungifez Yes, but then you're using a framework just like using React/NextJS.
My point was that the comparison with RSC and PHP doesn't make much sense, even just for templating. RSC definitely has the upper-hand there.
React, i choose you! :D
PHP is great