The author of the article seems to have a very antiquated view on how we write and use modern PHP. Maybe you could try it in a video and give your thoughts.
He did, he shat all over PHP. He ended up having to delete the video because it was such an L take from someone who hasnt got a clue how to write PHP. It was just a ragebait.
Switch to an OpenSwoole PHP server and don't look back. Modern PHP is just as clean as any other modern language if you know what you're doing. And people forget it's "single thread per process" in PHP unlike node's "single thread for everything". Server-side internal async behavior is as overhyped as crypto.
no one should use "this" in JS, classes should be use as sturt only, we all know now that OOP cost performances and it make code that is hard to change.
I use both Laravel and Nuxt.js and must say I prefer using Laravel with Blade. If I need interactivity I use Livewire. Currently building a web app using Inertia with Vue which is fantastic. Laravel has done so much for the PHP ecosystem, and I used to hate working with PHP more than jQuery.
Written by someone who hasn't used PHP lately. Nobody writes PHP the "template" way anymore. It's actually one of the fastest languages for web dev now.
speed doesn't matter tbh, but it's really not...by the time you use a framework (Laravel, Symphony) PHP is among the slower ones along with Django. Again, doesn't matter much tho.
When I did my first sollicitations after graduation everyone asked me if I’m a backend or frontend developer and they were shocked when I said I liked fullstack. The way you’re describing everything at the end is exactly how I feel, so thank you for that!
@@aleksd286 react and php is for web environment and this video in that area only, can u tell us how your comment related in any way? Or you just seeking blatant douche approval? Either way u got mine.
I recently had cause to return to PHP and was pleasantly surprised at how straightforward it was. That’s not to say it’s better than React of course. But it made me aware of how black box-y React & Next can seem, particularly to relative newbies. React also encourages/forces devs to use obscure operators that are not easy to read. The older I get the more frustrated I become with the modern obsession for conciseness, like using arrow functions everywhere.
I did PHP for rendering JSON in the backend and catching it in a React SPA. Very performant, very easy to debug and you could completely replace the stack in either side. React Server is eschewing all of that with no advantages in return, except for one single "benefit": getting frontend devs to work in server side. I'd much rather they learn a backend framework, not a frontend framework that's been frankensteined into backend.
HTMX is useless in my opinion. If you know PHP, you also know JS, the difference is small. Pseudo helpers like HTMX have no future and learning it will only take your time that should be spent learning something important. ( JS for example 😀) Best of all, it's a combination of Javascript and PHP, as it always been. Nothing does frontends better than Javascript.
I think people felt “betrayed” because it’s a major departure in the purpose of react. SPA’s have a purpose/place and it’s questionable if React is going to keep pushing the boundaries of what they are capable of. Additionally purely frontend devs aren’t going anywhere. Most Nextjs websites are still purely frontend projects that hit external REST apis. Hopefully this change just gives people more options on how to build a website and doesn’t prescribe how websites are expected to be built.
Well logically thinking i don't understand why in modern age world with more powerful devices and internet connection best solution is to "prerender" everything on server. Just to support SEO and to increase your server cost bill. As much as I try I don't buy those arguments and for me it is a step back.
@@alexp3620 you don't have to. PHP frameworks have their own place and so are front-end js frameworks. The only reason to keep pushing everything into one language like react when it wasn't even made for that is a pathetic refusal to learn PHP, one of the easiest language out there.
@@alexp3620 after using Next.js in two projects I switched back to Vite. Much faster build times and development experience, consistent hot reload, much easier and transparent debugging and clear seperation of concerns. I don't hate the idea of server side rendering but it isn't a clean solution at the moment and Vite is far more development friendly.
@@alexp3620 for me, RSC and even just basic SSR, simplifies a lot of FE state management. This is 90% due to being able to use async/await in component code. If we get async comps on the client in the future, maybe it won't matter as much. The other more niche win is that you don't have to ship some large libraries to the client, like syntax highlighters, or giant localization JSON objects.
I would argue that the vast majority of things we build today aren't more complex that they were 20 years ago. Some websites, even for big companies, are incredibly simple. Unfortunately, they all come with their insane tech stack, including hosting on a weird cloud environment, an unnecessarily custom bundler config, idiotic third-party script that bring 0 value, and more bloat. Companies have become accustomed to complex environment and believe their website deserve it. They don't.
They are more complex because user interactions are more complex, and there are more people who user the internet, which naturally mean in order to scale, you need additional complexity to handle that load. Stacks are not even considered here; just naturally how every company who was created in early 2000's still exist today deal with those complexities. Over the years they have opened an interface to that complexity through a higher level abstraction, and that is what we call "cloud".
What is the alternative? Go + HTMX? An apache server? Our job as engineers is to pick the _right tool for the job._ If your frontend is simple and you pick a complex frontend framework to build it with, then yes, that's bloat. However, if you implement a Rust backend for your in-browser cookie-clicker game, that is _also bloat._
Also 1. A lot of the nicer UI features are now supported directly in html, or with much more minimal javascript. You no longer need to reach for js if you e.g. want an accordion. 2. Much of the unavoidable complexity that does exist comes doesn't really apply to the backend. If a website goes from one user to one billion, it will likely need to radically rethink it's backend to meet the new load, but the frontend can be largely the same.
Modern apps may be better today, but React and JavaScript aren't the only catalysts for this improvement. There have been significant advances across many aspects of web development. I think the real issue isn't that frontend developers are unwilling to cross the full-stack boundary or that they're snobbing the server side. Rather, it's the blinders that were quietly placed on frontend developers, leading them to believe that all progress in the last 15 years stems solely from React and JavaScript-making them view these technologies as the only viable solution to any problem. Recognizing that server-side React is fundamentally similar to modern PHP and other server-side technologies is crucial. This realization could help frontend developers understand that there might be better languages and tools to solve their problems and ship applications more efficiently-whether that's PHP, HTMX with Go/Rust/Swift, or even React itself.
I don't like this "backward is bad" thinking. Electric cars are older than gasoline cars too. As tech progresses, going "back" is actually going forward. Fusion power plants are steam engines. Client side PHP is the future. I would rather use that than JS or TS.
What a weird article. It didn't go into the actual differences between PHP and Server Components, how it streams and hydrates data, any of that. It just made allusions to the ecosystem of web dev and the types of developers it is making? I was expecting something a lot more concrete.
Yes? Trigonometry is definitely easier with a calculator. You still need to know the right formulas to apply, but having a device to do the calculations is pretty handy. I get your point but the chosen example could be better.
@@theReal_WKD the example was totally fine, maybe you arent as great at interpretation. The point is that tools dont remove the burden, they become the new "low bar" and so was math class. It was no longer enough to do 12 x 5, you had to work with sine and cosine now, which is an exact analogy to static websites in the 90s vs dynamic sites in 2015...
I use React inside Laravel. ( with Inertia ) It's much better, trust me. 🙂 You dont need API, you render React components and data directly from controllers. It's like Next.js, but much better, because you can use whole Laravel ecosystem and PHP dependencies as well as javascript dependencies. ( you can use any frontend dependency, that you normally use in React, like tailwind, framer motion, react icons, dnd, ui libs etc...)
@Biglu193 i actually tried using it but I didn't like the approach, it was kinda confusing for me but that's just my opinion, maybe I should give it a second try and actually understand it
@@omarjab You have to approach it as if you were making a multipage application. That's what Inertia is all about. It was created to take advantage of the simplicity of creating Laravel's MPA applications and combine them with the dynamics of SPA applications. In practice, this means that you make an application like a classic MPA, where you render pages together with data directly in the controller, as is done in standard Laravel with Blade or perhaps in Node with EJS. (simply an application rendered by a server with a template engine) Inertia then takes care that they behave like React.
14:35 I'd argue it's because there were not a lot of documentation around React's features wrt to server-side until much later. They have only just relatively recently made the API stable for users (frameworks), but the only framework right now that utilizes it to its fullest is Next.js, which obviously had the man-power and the very people behind it that were already part of the core parts of those features in React.
Why oh why would anyone choose to use JavaScript voluntarily server side? It's bad enough for frontend. If this is your choice, modern PHP is much nicer than server side JavaScript.
This "same primitives for client & server code" paradigm has me pretty hyped for Gleam. Targeting JS on the Client and BEAM on the server means there's potential to benefit from this paradigm, while leveraging both a world-class server runtime and native browser APIs. The Gleam world is still early days, and there's a lot to figure out in terms of DX and patterns, but IMO the potential there is unparalleled.
I still stand by SPAs being the right solution in most situations. When you interviewed Evan You a while back, he even said he felt that using Vue for SPAs is appropriate in most cases and actually preferred it. While there are certainly some benefits to an isomorphic framework across front-end and back-end contexts, for me, they don't outweigh the simplicity of SPAs and having full control over browser APIs, and not having to second-guess where components and logic belong in your application. SPAs are much easier to reason about, and still can deliver a fantastic user experience. We went through a solid decade using SPA libraries for the bulk of the modern web, and easier SEO doesn't seem like a good enough reason to completely overhaul the way we think about building web applications -- especially when search engines don't seem to care whether your app/service can even be found anyway.
Vue and Nuxt its just a variation of React and Next. It's like 1:1 with some small differences, but React is much older than Vue, much more known and popular, let's say global. That's why all references pointing at React. Frameworks like Vue, Angular and Svelte, targets to specific companies and niche.
@Biglu193 vue's reactive system is far different from react. Nuxt is very similar to next however O do feel its a much better experience they have been bringing many innovations to the space. At the end of the day the reason I ask about them not getting any love is because all of these frameworks borrow from each other and its ultimately good for us, however react and next seem to get all the attention.
React on the server is much more like php than it is like react on the client. To me the hydration part, in reality, is quite far from how it was sold. You can't even setup context in a server component. You can use jsx on the server, preload some data, but you can't use that in the state of the client after the initial render. The big innovation in the past year is that we can now do form data? Woooow. But we can't use input validation(other than html5) in that form if we want to render the form on the server. It's just disappointing, honestly.
I think that some of it is Next.js fault with the obscure model of "use server", "use client" where the use client is also preparsed in the server, the bad debugging experience and the slow build and hot reload times (compared to Vite). In general the added complexity is not worth the learning curve effort and development penalty.
Great content, as always! I need some advice: I have a SafePal wallet with USDT, and I have the seed phrase. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). What's the best way to send them to Binance?
Also, PHP is not that bad of a language. I managed to code a full news outlet web-app by hand (without any PHP or JS frameworks, except jQuery) for a side project, and it was a phenomenal experience, and ultimately landed me my first webdev job. That job also drove me away from PHP because the apps we were writing were in Java (and still are for a certain platform), and eventually Node and React. I can't imagine needing to code in PHP today, but I don't think my first reaction would be to turn away if it ever came up in a project.
Livewire is bad. It simulates SPA for people, that dont know javascript, but every dynamic aspect is an AJAX call. This means that you are simulating the behavior of the SPA, but you are putting an incredible load on the server just to have the dynamics provided by javascript as a default. Don't use that, go for Inertia instead. React or Vue is very easy to learn and you need only essentials, because you dont need to learn React Router or Redux, you don't use it with Inertia.
Unobtrusive JavaScript was a good practice, not a concept; it essentially stood writing maintainable and readable code. Today, mixing JavaScript and HTML (and CSS) is what components are, but just because the direction modern frameworks are taking is the seemingly the opposite of what unobtrusive JavaScript stood for, I wouldn't diminish or ridicule it; it stemmed from clean code practices and taught me very early concepts like separation of concerns, naming conventions, etc. even though at the time I didn't know anything about clean code, and all I knew was this style was "unobtrusive" and generally a good practice. It was, for me and I imagine in many others as well, the first step towards writing cleaner code.
I want to know what exactly is the delta between what you can achieve with PHP (or any server side language) + HTMX (or Livewire or Hotwire) and what is possible with React Server Components? Because the argument for RSC vs server side + HTMX is like, the server side + HTMX can get you 70% of the way there! What is the 30% that only RSC can do?
The benefit is using the React compartmentalised Components Model throughout the application and it is a compelling one. Unfortunately the development experience (and added obscurity) is subpar to any classic SPA Vite application with a traditional backend framework.
What Theo is not saying- the backend was huge, and 90% of that was servers, server error hunting, and server security- I hate that stuff, the plesk, the nginx error hunting, the crap cli security programs, ports, iptables, data bases, email systems, smtp, bimi, dnssec, encryption, dns, records, error and server constant monitoring, then running to the front end trying SEO, content generation, making the site, optimizing, designing, video editing, etc. It's like one guy growing the food, being a farmer, knowing crops and production, animal husbandry and then being the waiter, cook, dishwasher, accountant, manager, online seo, content manager, etc. It's too fucking much. And its a great way to go broke, it doesn't matter if you don't have customers or are not closing or prospecting for customers. Every second spent on the back end is wasted time and money. I moved from plesk, WP sites, managing my own server- too much time spent, doing backend shit that costs time and money. Then I moved to a managed WP host, ok great way less mgt. security? who fucking cares already. Now with the WP shitshow plugins always breaking or xss every 2nd day. I learned how to code (more or less) moved to Astro and netlify, I don't want to deal with any backend shit, to pay someone to do the backend? How about try everything to minimize the backend headaches and wasted time. If you are in business for yourself, you need the energy to keep looking and going forward no playing around in the backend- backend doesn't make money.
I've been making websites since 2008. The old JavaScript ecosystem is the exact reason why I refused to become a developer because it seemed utterly impossible and miserable. I've been programming for over 5 years now because the tools are way better now.
I'm 52, I started out with php3 and did that for many years and releases. Don't get me wrong, I am on the client side train, svelte, react, angular, I love it. But to be honest? The web as we know it today will be more or less the same in 300 years. And again to be honest? I think the old php sites will still be there and all the js frameworks will be forgotten because in the future they don't care about niche problems...
Is it bad that I'm choosing Laravel (Php) and Svelte over React / NextJS? I know React / NextJS are a kings of the front end world (especially jobs) but I've rather be spending time learning things like Rust and Go, networking concepts, databases and other stuff than just learning the next new shiny thing in JS that re-inventat the wheel
Only 2:56 in And I can tell that this person is ignoring about 10 years of PHP innovation [That isn't to say that PHP doesn't deserve some of the hate that it gets] 16:24 I don't want a completely seamless flow between the server and the client... I want to write as little JavaScript as possible. *In my opinion* JavaScript still syntactically sucks when compared to PHP (though I *don't* dislike the idea of htmx) I also will admit that I am not writing the next Facebook or something like that So I probably can be a little bit more picky about how I generate my HTML (something about not having to scale infinitely) me,
Geez, I used to write games back in the floppy disk days, by myself, over the course of a couple of months. Must be the tools that separate game dev then and now. 🤭
I'd call myself full stack, but there is one reason why I'd never go full-stack JS: JS is too inefficient, and fragile. I'd wish we had any other options for the frontend (that is supported to the same degree), but the more JS the worse from any point of view. Be it performance, "DX" (whatever that means), or language features. Y would you ever want more jank/spaghetti? Sure, its fast, but build fast and fail fast - isn't that how it goes? TS makes it decent, but is way too easy to completely disable by some junior dev (I count myself in this group) who, at any point in time uses the word "as", and now all safeguards are gone. The less JS the better. If that means I'll have to go full microservice with 7 bundles in some AWS bucket and 3 golang backends, I'll take it. How fast it is to set things up completely depends on your familiarity with the language/library/framework, so why not broaden your horizon? Actually, besides the other points, full stack JS might actually prove detrimental, as people don't have to broaden their horizons at all, and thus loose the ability to reflect, improve and make better decisions in the long term.
They're too dumb to learn PHP and will keep using the obsolete excuse that PHP 8 already fixed. They won't know it though since they never tried PHP 8 in the first place and still think about PHP 5.
The more I read, study, and learn the less I enjoy. I would say that 8 out of 10 web apps could be just a simple web form, it’s the 2 in 10 specific apps that really need the “react” level of interactivity. Sad that everyone jumped on this train to hell without thinking too much of it.
For customers, it's about the user experience. With web forms, would you rather get instant feedback when something's wrong, or wait until you submit the form to have it *finally* tell you that you got several fields invalid? That's the difference between a pleasant webapp and possibly ragequitting, where customers will lose trust and respect because there wasn't enough UI feedback and quality-of-life to the experience they've come to expect.
@@pavel-6700 Of course it is, but libraries like React/Vue etc. are indisputably the most popular and preferred way of providing these UI features with minimal friction. Plain web forms don't offer enough functionality to communicate to the user in a way that meets modern expectations. Ideally any app would be on par with current native apps and popular web apps to help users feel at home with a familiar experience. Even subtle differences can throw people off, and going back 20 years to full page reloads on submit, and ambiguous validation/error handling is not a good idea.
@@ShinSpiegel Indeed, and after 20 years of professional web development using a variety of technologies that existed before SPAs, I think I'd rather get a root canal than do it the old way again.
I'm sorry but "we're not going back to PHP", you are comparing using NextJS to using PHP, aka a framework vs a language? We PHP devs use frameworks too, we use tools like livewire that completely eliminate the need for detached front end states. I could also say using the TALL stack is much better for making web apps than pure Typescript with no framework or libraries. Yea, I never got behind the whole "re-invent navigation" in SPAs, if you're SPA needs to behave like a standard website, then build a standard website. This isn't a failure of the toolkit, this is a failure of devs not picking the right tool for the job. This is why being a framework fanboy is dumb, NextJS won't be the perfect solution in every situation. Any app that grows for a long period of time will be a mix of tech, no tech is one size fits all.
Well logically thinking I don't understand why in modern age world with more powerful devices and internet connection best solution is to "prerender" everything on the server. Just to support SEO and to increase your server cost bill. As much as I try I don't buy those arguments and for me it is a step back. Solution should be Google etc to work natively with SPAs and to optimize client side build size and render performance.
To be fair, tRPC covers less than Convex in terms of features. And where they overlap, tRPC has a pretty good DX, nothing really significant to envy from Convex.
"Server-side JS frameworks" like React are just what old, inexperienced PHP used to be but using a different programming language - mixing logic with templating and rendering. When older back-end and full-stack devs like myself leveled up we didn't move away from mixing HTML and JS code with PHP because it was "slower" or solely in favor of the new hotness PHP frameworks of the time like Laravel or Symfony, we moved away from the practice because mixing code that way more often than not leads to a spaghetti mess of confusion and is more annoying to update and maintain beyond extremely small scales. I'd much rather go with a more explicitly MVC- or MVVM-structured coding style and have, for example, two separate external micro-template files for logged in user nav vs guest user nav controlled by Smarty PHP rather than conditional switching of directly embedded HTML that I'd have to hunt down to change when (not if) the client demands a redesign six months later.
Were you even around back then? The "hotness" trend you were talking about was not a mere fad. Frameworks like laravel and symfony moved into MVC primarily because of the same reason you were talking about. Mixing code into a monolith spaghetti became too hard to manage as webdev complexity went up and worse it became a security risk. Thinking of it as a "hotness" fad that everyone followed is just admitting that you were one of those who never understood the direction the devs had back then and just followed suit as well.
@@hentype I was indeed around back then, professional dev since at least 2006, long enough to see those frameworks and others like them before and after they became bloated messes that peeps try to shoehorn everything and the kitchen sink into for the purpose of copying Java, C#, and Ruby on Rails claiming PHP was inferior. It was very much the "hotness" fad I claim, and PHP deniers (or more accurately, Java and Ruby on Rails evangelists and code snobs back then that certain other language zealots do today) did the same thing with PHP that is done with JavaScript today - try to force other language paradigms and ideologies onto it that it wasn't built for. Don't force it into the language, let devs choose it for themselves on a project-by-project basis. Meanwhile, PHP still powers the programming back-end of more than half the web today (somewhere in the 70-80% if you believe WordPress's stats) and vanilla JavaScript is still the de facto standard programming language for web page front-ends. Not TypeScript, not CoffeeScript, not the React or Angular or JQuery library "subsets" of JS. _Vanilla_ JavaScript.
Server components was promoted by Vercel since they need to sell server services like cache, ram and cpu, etc. and spa web applications that is loaded once on clinet browser wasn't a good deal for Vercel and that's it, then other frameworks just followed them just to make people they are not behind of that feature.
I will hate using JS as long as this shit is possible const myFunc = ( d: Date) : void { if( dt instanceof Date) { console.log("Got a date"); } else { console.log("WRF?!?! NOT A DATE???"); } } ... myFunc( somethingThatShouldBeADate); and then you get a console outout as > WRF?!?! NOT A DATE??? JS/TS is a ridiculous programming language. I use it every day, and it is bad.
The author of the article seems to have a very antiquated view on how we write and use modern PHP. Maybe you could try it in a video and give your thoughts.
No one needs another laravel review lmao
He did, he shat all over PHP. He ended up having to delete the video because it was such an L take from someone who hasnt got a clue how to write PHP. It was just a ragebait.
@@TheGiliwawa Modern php is kinda of semidecent for a developer, still slow tho
Switch to an OpenSwoole PHP server and don't look back. Modern PHP is just as clean as any other modern language if you know what you're doing. And people forget it's "single thread per process" in PHP unlike node's "single thread for everything". Server-side internal async behavior is as overhyped as crypto.
@@alexandermason4229 php is not laravel, don't mix frameworks with languages.
"var self2 = this" gave me Vietnam flashbacks
no one should use "this" in JS, classes should be use as sturt only, we all know now that OOP cost performances and it make code that is hard to change.
@@zeocamo OOP make's code hard to change? ... WHAT? are you guys live in some sort of parallel world? don't touch backend, please...
@@korseg1990 i been working on backend for more then 20 years.
It made me remember why I threw issues asside and let collegues pick them up :P
Just let me do the server, I said.
I forsee Laravel continuing to bridge the gap, but better. Pretty soon React Devs are also going to be PHP/Laravel devs :D
Did i hear livewire ?
unlikely, php and node communities are completely different cultures. they value opposite things.
Node chuds will keep coping while PHP chads will keep making better what already works best for decades.
I use both Laravel and Nuxt.js and must say I prefer using Laravel with Blade. If I need interactivity I use Livewire. Currently building a web app using Inertia with Vue which is fantastic. Laravel has done so much for the PHP ecosystem, and I used to hate working with PHP more than jQuery.
The funniest comment so far!
the gymnastics to avoid the obvious conclusion lol
Written by someone who hasn't used PHP lately. Nobody writes PHP the "template" way anymore. It's actually one of the fastest languages for web dev now.
golang is pretty good too ;p
@@dae2530 nobody said it wasnt
@@dae2530 go sucks lol
speed doesn't matter tbh, but it's really not...by the time you use a framework (Laravel, Symphony) PHP is among the slower ones along with Django. Again, doesn't matter much tho.
@@PraiseYeezushow true is this
When I did my first sollicitations after graduation everyone asked me if I’m a backend or frontend developer and they were shocked when I said I liked fullstack.
The way you’re describing everything at the end is exactly how I feel, so thank you for that!
yeah, PHP is better.
No, Assembly is better.
@@aleksd286 Machine coder are best devs ever
@@aleksd286 react and php is for web environment and this video in that area only, can u tell us how your comment related in any way? Or you just seeking blatant douche approval? Either way u got mine.
@@RuslanMykolaivbeing the machine is best
@@soundrightmusic being deployed on the cloud
Another bad take, comparing PHP from 10 years ago with modern JS. It's like comparing Laravel 11 with jquery scripts.
I recently had cause to return to PHP and was pleasantly surprised at how straightforward it was. That’s not to say it’s better than React of course. But it made me aware of how black box-y React & Next can seem, particularly to relative newbies. React also encourages/forces devs to use obscure operators that are not easy to read. The older I get the more frustrated I become with the modern obsession for conciseness, like using arrow functions everywhere.
Ok, but please don't use arrow functions everywhere.
Just because there is something, it doesn't mean it should be everywhere.
I did PHP for rendering JSON in the backend and catching it in a React SPA. Very performant, very easy to debug and you could completely replace the stack in either side.
React Server is eschewing all of that with no advantages in return, except for one single "benefit": getting frontend devs to work in server side.
I'd much rather they learn a backend framework, not a frontend framework that's been frankensteined into backend.
Ye JS syntax is just terrible. I don't even know who came up with those ideas.
Nothing beats HTMX + PHP
HTMX is useless in my opinion. If you know PHP, you also know JS, the difference is small. Pseudo helpers like HTMX have no future and learning it will only take your time that should be spent learning something important. ( JS for example 😀) Best of all, it's a combination of Javascript and PHP, as it always been. Nothing does frontends better than Javascript.
just learn laravel
Laravel is my jam.
React on server: because PHP was too fast for our standards.
I think people felt “betrayed” because it’s a major departure in the purpose of react. SPA’s have a purpose/place and it’s questionable if React is going to keep pushing the boundaries of what they are capable of.
Additionally purely frontend devs aren’t going anywhere. Most Nextjs websites are still purely frontend projects that hit external REST apis.
Hopefully this change just gives people more options on how to build a website and doesn’t prescribe how websites are expected to be built.
Well logically thinking i don't understand why in modern age world with more powerful devices and internet connection best solution is to "prerender" everything on server. Just to support SEO and to increase your server cost bill. As much as I try I don't buy those arguments and for me it is a step back.
@@alexp3620 you don't have to. PHP frameworks have their own place and so are front-end js frameworks. The only reason to keep pushing everything into one language like react when it wasn't even made for that is a pathetic refusal to learn PHP, one of the easiest language out there.
@@alexp3620 after using Next.js in two projects I switched back to Vite.
Much faster build times and development experience,
consistent hot reload,
much easier and transparent debugging and clear seperation of concerns.
I don't hate the idea of server side rendering but it isn't a clean solution at the moment and Vite is far more development friendly.
@@alexp3620 for me, RSC and even just basic SSR, simplifies a lot of FE state management. This is 90% due to being able to use async/await in component code. If we get async comps on the client in the future, maybe it won't matter as much.
The other more niche win is that you don't have to ship some large libraries to the client, like syntax highlighters, or giant localization JSON objects.
@@hentype I am not talking about PHP right now. I worked with both and react has larger ecosystem and more capabilities for client side logic.
I went from NextJS to Laravel. Tired of these JS frameworks
how is your impression on Larvel so far? do you know php before?
What about reactivity and state management?
Comming from PHP side, I saw the js shit and I've cried. There is still a hope with frameworks like Encore or Adonis, but...
ONLY STRONG GUYS STAY WITH NEXTJS, OTHERS CAN LEAVE NOW..
@@SIGMA_BLYAT you know no one takes you seriously because of your name?
The amount of energy developers put into philosophical yoga is astonishing
I would argue that the vast majority of things we build today aren't more complex that they were 20 years ago. Some websites, even for big companies, are incredibly simple. Unfortunately, they all come with their insane tech stack, including hosting on a weird cloud environment, an unnecessarily custom bundler config, idiotic third-party script that bring 0 value, and more bloat.
Companies have become accustomed to complex environment and believe their website deserve it. They don't.
They are more complex because user interactions are more complex, and there are more people who user the internet, which naturally mean in order to scale, you need additional complexity to handle that load.
Stacks are not even considered here; just naturally how every company who was created in early 2000's still exist today deal with those complexities. Over the years they have opened an interface to that complexity through a higher level abstraction, and that is what we call "cloud".
What is the alternative? Go + HTMX? An apache server? Our job as engineers is to pick the _right tool for the job._ If your frontend is simple and you pick a complex frontend framework to build it with, then yes, that's bloat. However, if you implement a Rust backend for your in-browser cookie-clicker game, that is _also bloat._
@@dealloc They are also complex because of security.
Also
1. A lot of the nicer UI features are now supported directly in html, or with much more minimal javascript. You no longer need to reach for js if you e.g. want an accordion.
2. Much of the unavoidable complexity that does exist comes doesn't really apply to the backend. If a website goes from one user to one billion, it will likely need to radically rethink it's backend to meet the new load, but the frontend can be largely the same.
this take is so bad that I think I'm learning to accept most people who comment on these videos don't actually work in the field
Modern apps may be better today, but React and JavaScript aren't the only catalysts for this improvement. There have been significant advances across many aspects of web development.
I think the real issue isn't that frontend developers are unwilling to cross the full-stack boundary or that they're snobbing the server side. Rather, it's the blinders that were quietly placed on frontend developers, leading them to believe that all progress in the last 15 years stems solely from React and JavaScript-making them view these technologies as the only viable solution to any problem.
Recognizing that server-side React is fundamentally similar to modern PHP and other server-side technologies is crucial. This realization could help frontend developers understand that there might be better languages and tools to solve their problems and ship applications more efficiently-whether that's PHP, HTMX with Go/Rust/Swift, or even React itself.
being born into a cult is not our fault, staying in one is, open your eyes guys
I don't like this "backward is bad" thinking. Electric cars are older than gasoline cars too. As tech progresses, going "back" is actually going forward. Fusion power plants are steam engines.
Client side PHP is the future. I would rather use that than JS or TS.
What a weird article. It didn't go into the actual differences between PHP and Server Components, how it streams and hydrates data, any of that. It just made allusions to the ecosystem of web dev and the types of developers it is making? I was expecting something a lot more concrete.
PHP is extremely hot these days, so your video is nothing more than a clickbait.
I wouldn't say PHP is hot, as much as I'd correct that with: Laravel is hot these days. Theo made that exception pretty clear early in the vid 😁
If somebody gives you that "its easier now with tools lol" treatment just ask them: "did math class get easier once you got a calculator?"
Yes? Trigonometry is definitely easier with a calculator. You still need to know the right formulas to apply, but having a device to do the calculations is pretty handy.
I get your point but the chosen example could be better.
@@theReal_WKD the example was totally fine, maybe you arent as great at interpretation. The point is that tools dont remove the burden, they become the new "low bar" and so was math class. It was no longer enough to do 12 x 5, you had to work with sine and cosine now, which is an exact analogy to static websites in the 90s vs dynamic sites in 2015...
react frontend and php backend in api and it works really well in my opinion
I use React inside Laravel. ( with Inertia ) It's much better, trust me. 🙂 You dont need API, you render React components and data directly from controllers. It's like Next.js, but much better, because you can use whole Laravel ecosystem and PHP dependencies as well as javascript dependencies. ( you can use any frontend dependency, that you normally use in React, like tailwind, framer motion, react icons, dnd, ui libs etc...)
@Biglu193 i actually tried using it but I didn't like the approach, it was kinda confusing for me but that's just my opinion, maybe I should give it a second try and actually understand it
@@omarjab You have to approach it as if you were making a multipage application. That's what Inertia is all about.
It was created to take advantage of the simplicity of creating Laravel's MPA applications and combine them with the dynamics of SPA applications.
In practice, this means that you make an application like a classic MPA, where you render pages together with data directly in the controller, as is done in standard Laravel with Blade or perhaps in Node with EJS. (simply an application rendered by a server with a template engine)
Inertia then takes care that they behave like React.
14:35 I'd argue it's because there were not a lot of documentation around React's features wrt to server-side until much later. They have only just relatively recently made the API stable for users (frameworks), but the only framework right now that utilizes it to its fullest is Next.js, which obviously had the man-power and the very people behind it that were already part of the core parts of those features in React.
Why oh why would anyone choose to use JavaScript voluntarily server side? It's bad enough for frontend. If this is your choice, modern PHP is much nicer than server side JavaScript.
The fact that we're watching this highlights how overly complex the React ecosystem has become....
And that is fine. Use the parts of it that you need.
🎯
This "same primitives for client & server code" paradigm has me pretty hyped for Gleam. Targeting JS on the Client and BEAM on the server means there's potential to benefit from this paradigm, while leveraging both a world-class server runtime and native browser APIs.
The Gleam world is still early days, and there's a lot to figure out in terms of DX and patterns, but IMO the potential there is unparalleled.
It should be Node/Deno vs PHP right?
I think because they are the actual backend.
I have to say that the js backend is horrible to maintain. Mountains of npm dependencies.
I still stand by SPAs being the right solution in most situations. When you interviewed Evan You a while back, he even said he felt that using Vue for SPAs is appropriate in most cases and actually preferred it. While there are certainly some benefits to an isomorphic framework across front-end and back-end contexts, for me, they don't outweigh the simplicity of SPAs and having full control over browser APIs, and not having to second-guess where components and logic belong in your application.
SPAs are much easier to reason about, and still can deliver a fantastic user experience. We went through a solid decade using SPA libraries for the bulk of the modern web, and easier SEO doesn't seem like a good enough reason to completely overhaul the way we think about building web applications -- especially when search engines don't seem to care whether your app/service can even be found anyway.
Cope.
So much effort to conclude something like "php is index.php with php css and html all together in one file" -- Mental Gymnastic at it best
Why doesn't Nuxt get any love? Feels so good and easy to use.
Vue and Nuxt its just a variation of React and Next. It's like 1:1 with some small differences, but React is much older than Vue, much more known and popular, let's say global. That's why all references pointing at React. Frameworks like Vue, Angular and Svelte, targets to specific companies and niche.
@Biglu193 vue's reactive system is far different from react. Nuxt is very similar to next however O do feel its a much better experience they have been bringing many innovations to the space.
At the end of the day the reason I ask about them not getting any love is because all of these frameworks borrow from each other and its ultimately good for us, however react and next seem to get all the attention.
I'm taking over a react project, and spaghetti code still exists even in react.
The TL;DR is "Yes React is exactly now PHP"
React on the server is much more like php than it is like react on the client. To me the hydration part, in reality, is quite far from how it was sold. You can't even setup context in a server component. You can use jsx on the server, preload some data, but you can't use that in the state of the client after the initial render. The big innovation in the past year is that we can now do form data? Woooow. But we can't use input validation(other than html5) in that form if we want to render the form on the server. It's just disappointing, honestly.
I think that some of it is Next.js fault with the obscure model of "use server", "use client" where the use client is also preparsed in the server, the bad debugging experience and the slow build and hot reload times (compared to Vite).
In general the added complexity is not worth the learning curve effort and development penalty.
React on server is literally just old MPA but condensed into a component you can nest and import. Thats literally it. Same meat different flavor.
Do what you wanna do, but I am taking Blazor with type safe c# in frontend all the time.
Blazor? does it have a future? even microsoft doesn't use it for their websites.
@@statuschannel8572 Maybe yes, maybe no. Point is I would rather have C# in frontend then JavaScript in backend, all the time.
@@statuschannel8572 it doesnt, if its own creator isnt using it its doomed to fail tbh.
@@statuschannel8572 😀 They made wrong turn and try to forget it 😀
Great content, as always! I need some advice: I have a SafePal wallet with USDT, and I have the seed phrase. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). What's the best way to send them to Binance?
I'm still using PHP vs react due to it is easy to maintain and deploy as well as easy to optimize in your infra with cheap cost.
Also, PHP is not that bad of a language. I managed to code a full news outlet web-app by hand (without any PHP or JS frameworks, except jQuery) for a side project, and it was a phenomenal experience, and ultimately landed me my first webdev job. That job also drove me away from PHP because the apps we were writing were in Java (and still are for a certain platform), and eventually Node and React.
I can't imagine needing to code in PHP today, but I don't think my first reaction would be to turn away if it ever came up in a project.
Ever used LiveWire?
Livewire is bad. It simulates SPA for people, that dont know javascript, but every dynamic aspect is an AJAX call. This means that you are simulating the behavior of the SPA, but you are putting an incredible load on the server just to have the dynamics provided by javascript as a default. Don't use that, go for Inertia instead. React or Vue is very easy to learn and you need only essentials, because you dont need to learn React Router or Redux, you don't use it with Inertia.
Great opportunity for engineers frustrated by react to complain.
Unobtrusive JavaScript was a good practice, not a concept; it essentially stood writing maintainable and readable code. Today, mixing JavaScript and HTML (and CSS) is what components are, but just because the direction modern frameworks are taking is the seemingly the opposite of what unobtrusive JavaScript stood for, I wouldn't diminish or ridicule it; it stemmed from clean code practices and taught me very early concepts like separation of concerns, naming conventions, etc. even though at the time I didn't know anything about clean code, and all I knew was this style was "unobtrusive" and generally a good practice. It was, for me and I imagine in many others as well, the first step towards writing cleaner code.
I want to know what exactly is the delta between what you can achieve with PHP (or any server side language) + HTMX (or Livewire or Hotwire) and what is possible with React Server Components? Because the argument for RSC vs server side + HTMX is like, the server side + HTMX can get you 70% of the way there! What is the 30% that only RSC can do?
The benefit is using the React compartmentalised Components Model throughout the application and it is a compelling one.
Unfortunately the development experience (and added obscurity) is subpar to any classic SPA Vite application with a traditional backend framework.
But can PHP still get me a lambo?
No, but you can write some whitehorsed airplane app in PHP and retail cryptobarons send you money for that lambo instead. 😉
*takes notes* react... is not... php
thx fam i was getting stuck on that one
What Theo is not saying- the backend was huge, and 90% of that was servers, server error hunting, and server security- I hate that stuff, the plesk, the nginx error hunting, the crap cli security programs, ports, iptables, data bases, email systems, smtp, bimi, dnssec, encryption, dns, records, error and server constant monitoring, then running to the front end trying SEO, content generation, making the site, optimizing, designing, video editing, etc. It's like one guy growing the food, being a farmer, knowing crops and production, animal husbandry and then being the waiter, cook, dishwasher, accountant, manager, online seo, content manager, etc. It's too fucking much. And its a great way to go broke, it doesn't matter if you don't have customers or are not closing or prospecting for customers. Every second spent on the back end is wasted time and money.
I moved from plesk, WP sites, managing my own server- too much time spent, doing backend shit that costs time and money. Then I moved to a managed WP host, ok great way less mgt. security? who fucking cares already. Now with the WP shitshow plugins always breaking or xss every 2nd day. I learned how to code (more or less) moved to Astro and netlify, I don't want to deal with any backend shit, to pay someone to do the backend? How about try everything to minimize the backend headaches and wasted time. If you are in business for yourself, you need the energy to keep looking and going forward no playing around in the backend- backend doesn't make money.
This Convex ad was a little colorless. Convex is awesome.
is there any way to get the resusable component like features from react but in vanilla ? I am developer and I would like that features.
Kotlin>
Goblin
I've been making websites since 2008. The old JavaScript ecosystem is the exact reason why I refused to become a developer because it seemed utterly impossible and miserable. I've been programming for over 5 years now because the tools are way better now.
I'm 52, I started out with php3 and did that for many years and releases. Don't get me wrong, I am on the client side train, svelte, react, angular, I love it. But to be honest? The web as we know it today will be more or less the same in 300 years. And again to be honest? I think the old php sites will still be there and all the js frameworks will be forgotten because in the future they don't care about niche problems...
What if you sponsored by firebase and redux are they going to be cool also ?
Is it bad that I'm choosing Laravel (Php) and Svelte over React / NextJS?
I know React / NextJS are a kings of the front end world (especially jobs) but I've rather be spending time learning things like Rust and Go, networking concepts, databases and other stuff than just learning the next new shiny thing in JS that re-inventat the wheel
Only 2:56 in And I can tell that this person is ignoring about 10 years of PHP innovation [That isn't to say that PHP doesn't deserve some of the hate that it gets]
16:24 I don't want a completely seamless flow between the server and the client... I want to write as little JavaScript as possible.
*In my opinion* JavaScript still syntactically sucks when compared to PHP (though I *don't* dislike the idea of htmx)
I also will admit that I am not writing the next Facebook or something like that So I probably can be a little bit more picky about how I generate my HTML (something about not having to scale infinitely) me,
Geez, I used to write games back in the floppy disk days, by myself, over the course of a couple of months. Must be the tools that separate game dev then and now. 🤭
Convex shoutout lets gooo!
PHP advocates and evangelists, here's a question for you: what about front end reactivity and state management comparison??
Unless it’s ReactPHP witch was out long before React
No shit?
Last site I made was raw php and vanilla javascript, but using components
have 0 dependencies...
I'd call myself full stack, but there is one reason why I'd never go full-stack JS:
JS is too inefficient, and fragile. I'd wish we had any other options for the frontend (that is supported to the same degree), but the more JS the worse from any point of view. Be it performance, "DX" (whatever that means), or language features. Y would you ever want more jank/spaghetti? Sure, its fast, but build fast and fail fast - isn't that how it goes?
TS makes it decent, but is way too easy to completely disable by some junior dev (I count myself in this group) who, at any point in time uses the word "as", and now all safeguards are gone.
The less JS the better. If that means I'll have to go full microservice with 7 bundles in some AWS bucket and 3 golang backends, I'll take it. How fast it is to set things up completely depends on your familiarity with the language/library/framework, so why not broaden your horizon?
Actually, besides the other points, full stack JS might actually prove detrimental, as people don't have to broaden their horizons at all, and thus loose the ability to reflect, improve and make better decisions in the long term.
Yeah, it's even worse.
but......facebook is running PHP
Php since php8 has been great though
Laravel is my back end lambo engine, JS framework on the front end
all i hear from this article is bla bla bla. not old php coz solid and 1 lang. lol
They're too dumb to learn PHP and will keep using the obsolete excuse that PHP 8 already fixed. They won't know it though since they never tried PHP 8 in the first place and still think about PHP 5.
Where are the bots
I used to write “var that = this” 😂
The more I read, study, and learn the less I enjoy. I would say that 8 out of 10 web apps could be just a simple web form, it’s the 2 in 10 specific apps that really need the “react” level of interactivity. Sad that everyone jumped on this train to hell without thinking too much of it.
For customers, it's about the user experience. With web forms, would you rather get instant feedback when something's wrong, or wait until you submit the form to have it *finally* tell you that you got several fields invalid? That's the difference between a pleasant webapp and possibly ragequitting, where customers will lose trust and respect because there wasn't enough UI feedback and quality-of-life to the experience they've come to expect.
@@docmars and you think that it is not possible without react?
@@pavel-6700 Of course it is, but libraries like React/Vue etc. are indisputably the most popular and preferred way of providing these UI features with minimal friction.
Plain web forms don't offer enough functionality to communicate to the user in a way that meets modern expectations. Ideally any app would be on par with current native apps and popular web apps to help users feel at home with a familiar experience. Even subtle differences can throw people off, and going back 20 years to full page reloads on submit, and ambiguous validation/error handling is not a good idea.
@docmars let me tell you something, you don’t need “react” for this, you can use vanilla JS, and very little of it, and sparkling or css…
@@ShinSpiegel Indeed, and after 20 years of professional web development using a variety of technologies that existed before SPAs, I think I'd rather get a root canal than do it the old way again.
Please no white background T.T
Your thumbnails are getting very repetitive. It became hard to distinguish your videos
I'm sorry but "we're not going back to PHP", you are comparing using NextJS to using PHP, aka a framework vs a language? We PHP devs use frameworks too, we use tools like livewire that completely eliminate the need for detached front end states. I could also say using the TALL stack is much better for making web apps than pure Typescript with no framework or libraries.
Yea, I never got behind the whole "re-invent navigation" in SPAs, if you're SPA needs to behave like a standard website, then build a standard website.
This isn't a failure of the toolkit, this is a failure of devs not picking the right tool for the job.
This is why being a framework fanboy is dumb, NextJS won't be the perfect solution in every situation.
Any app that grows for a long period of time will be a mix of tech, no tech is one size fits all.
"completely eliminate the need for detached frontend states" this isn't even close to being the case.
@ it absolutely is true. You can get more complicated if you want. But you can leverage its auto wiring to not have detached front end states
7:58 still doing it🤣🤣🤣 I will think about it when i need a real app
var that = this
my country is so $**t they actually banned this video, I can't watch it without a VPN
which one ?
@@TacticalCheetaGaming-w2k stop replying on bot spams.
hello
Nice.
Is this a React'ion video? 😂
I love your take on 14:28. Actually, your whole take is moving❤🔥🤝and i am a vanilla PHP, vanilla JS guy😂
yes it is
Well logically thinking I don't understand why in modern age world with more powerful devices and internet connection best solution is to "prerender" everything on the server. Just to support SEO and to increase your server cost bill. As much as I try I don't buy those arguments and for me it is a step back.
Solution should be Google etc to work natively with SPAs and to optimize client side build size and render performance.
You need to spend all the VC money. If everything is done on client side, the server is cheap.
"Static Blog from early 2000" you can always count on Theo to make a straw man.
always selling React, always awful.
Is he back on Vercel payroll?
funny that theo havent made the whole video about convex, its literally a tech with better DX compared to his own T3 or TRPC.
To be fair, tRPC covers less than Convex in terms of features. And where they overlap, tRPC has a pretty good DX, nothing really significant to envy from Convex.
"Server-side JS frameworks" like React are just what old, inexperienced PHP used to be but using a different programming language - mixing logic with templating and rendering. When older back-end and full-stack devs like myself leveled up we didn't move away from mixing HTML and JS code with PHP because it was "slower" or solely in favor of the new hotness PHP frameworks of the time like Laravel or Symfony, we moved away from the practice because mixing code that way more often than not leads to a spaghetti mess of confusion and is more annoying to update and maintain beyond extremely small scales. I'd much rather go with a more explicitly MVC- or MVVM-structured coding style and have, for example, two separate external micro-template files for logged in user nav vs guest user nav controlled by Smarty PHP rather than conditional switching of directly embedded HTML that I'd have to hunt down to change when (not if) the client demands a redesign six months later.
Were you even around back then? The "hotness" trend you were talking about was not a mere fad. Frameworks like laravel and symfony moved into MVC primarily because of the same reason you were talking about. Mixing code into a monolith spaghetti became too hard to manage as webdev complexity went up and worse it became a security risk. Thinking of it as a "hotness" fad that everyone followed is just admitting that you were one of those who never understood the direction the devs had back then and just followed suit as well.
@@hentype I was indeed around back then, professional dev since at least 2006, long enough to see those frameworks and others like them before and after they became bloated messes that peeps try to shoehorn everything and the kitchen sink into for the purpose of copying Java, C#, and Ruby on Rails claiming PHP was inferior. It was very much the "hotness" fad I claim, and PHP deniers (or more accurately, Java and Ruby on Rails evangelists and code snobs back then that certain other language zealots do today) did the same thing with PHP that is done with JavaScript today - try to force other language paradigms and ideologies onto it that it wasn't built for. Don't force it into the language, let devs choose it for themselves on a project-by-project basis.
Meanwhile, PHP still powers the programming back-end of more than half the web today (somewhere in the 70-80% if you believe WordPress's stats) and vanilla JavaScript is still the de facto standard programming language for web page front-ends. Not TypeScript, not CoffeeScript, not the React or Angular or JQuery library "subsets" of JS. _Vanilla_ JavaScript.
Server components was promoted by Vercel since they need to sell server services like cache, ram and cpu, etc. and spa web applications that is loaded once on clinet browser wasn't a good deal for Vercel and that's it, then other frameworks just followed them just to make people they are not behind of that feature.
Do a video using jQuery + bootstrap + java on Notepad++ or equivalent to build the same app as with Next, shadcn and cursor!
I . Dare . You .
And you are?
Ayt imma head out. Peace quiche devs ✌️
PHP has one major flaw.... PHP
Cope.
blah blah blah
Php is better if you dont want to read docs and react if your season dev and know reading doc is normal
I will hate using JS as long as this shit is possible
const myFunc = ( d: Date) : void {
if( dt instanceof Date) {
console.log("Got a date");
}
else {
console.log("WRF?!?! NOT A DATE???");
}
}
...
myFunc( somethingThatShouldBeADate);
and then you get a console outout as
> WRF?!?! NOT A DATE???
JS/TS is a ridiculous programming language. I use it every day, and it is bad.