React on the server is not PHP

I don't think this article is well written, it doesn't really articulate a point other than it's not PHP because

> we've developed solid principles for building UIs

There's not really any substance to this statement or the paragraph it's in. I would skip this article entirely, and I think a much more profound view of this concept is "Mind the Gap" talk by Ryan Florence about dissolving the concept of the network and explicit code needed to manage that: https://www.youtube.com/watch?v=zqhE-CepH2g

I am also miffed that the criticizers of React = PHP are often Rails developers who completely overlook that Rails is PHP on cocaine, it is implicit, untraceable database calls sprinkled across templates, and the more use the worse it gets and it quickly becomes un-optimizable. At least with React API calls are explicit, not magic!

I measured the speed of this blog and it's finished in 5 to 8 seconds after a soft-reload. Even more telling is the use of http 1.1 on partials of this blog when all remote includes do h2 or h3...

This is a blog btw, so a static should do! I do domain management, animations and implement stats from logs on the fly. And i even have a markdown blog! ;)

My page loads in under 1 second with a hard refresh.

Backend for a combined full page controller or partials does 1ms rendering with logged in user. ofc stuff is cached, but the user should never notice. All system related calls are fast as f... and intended this way. DB with PDO takes most of this millisecond.

I do vanilla TS with fetch on the frontend which is responsive as a GUI and that's great, i can modify the DOM and do frontend stuff - and not more. Why would i? One call to the ldap-client in nodejs, even with bun, is already slower than my whole page.

One tool for one job!

If you can beat this wake me up for js on the backend.

> Discover why this isn't a step backward but a leap forward in building powerful, efficient web applications.

There are certainly reasons to use JS on the server but efficiency is definitely not a big one. Even less when using React which is probably the slowest of the modern framework/libs doing SSR.

https://blog.platformatic.dev/ssr-performance-showdown

JavaScript on the server is better than JavaScript in my browser because at least it doesn’t waste my battery.

Actually it would sort of be nice if these frameworks could be coded such that if I have JavaScript shut off, it just runs the code elsewhere and sends me the site.

Or better yet, just write HTML and CSS and be done with it. But that’s too hopeful.

It's actually the other way around.

React was originally designed as the PHP on the browser side. Facebook was a php powerhouse, Jordan Walke invented React based on XHP, HHVM, etc.

https://github.com/jordwalke/FaxJs

In some ways, React on the server is worse than PHP. Server-side rendering of client-side code adds a ton of complexity, and can even introduce performance issues that must be worked around before the app can be launched (e.g. needing to pre-warm caches).

I'm sure there are valid uses for server-side React, but at the end of the day, using server-side languages such as PHP or Rails (or even rendering pages in Node.JS if you like JavaScript) can be much faster and simpler.

I say this having been involved in an app rewrite that used Remix. The project has taken 2 years (and still isn't quite out), and the engineering leaders who made the decision have agreed that we probably could have rendered most of the pages in Rails and used JavaScript for a limited number of things. With that said. I am hopeful that the project will work well when all is said and done, but there were a lot of tradeoffs associated with going to a server-side rendering framework.

It's frustrating that when people discuss React on the server or frameworks like Next.js, the conversation rarely acknowledges the performance cost that comes with Server-Side Rendering (SSR). The excitement tends to focus on the benefits like SEO and initial page load performance, but the limitations and potential drawbacks of running JavaScript server-side are often overlooked.

As traffic increases, the server's ability to handle requests diminishes, especially under high loads with complex rendering. This is exacerbated by the fact that each request often requires repeatedly rendering the same React components from scratch, rather than reusing client-side resources.

We live in exciting times! But also very confusing times.

I spent the last year transitioning from data science to learning full stack web dev and it was pretty wild. There isn't exactly an obvious entry point into learning all of this stuff and there are so many layers of abstraction now.

As hilarious as it sounds, I actually first tried to learn web development by building my first website with Next js on Vercel without even knowing basic html, css, js or what a webserver was. Needless to say, I hit a hard wall and decided to learn web dev from the ground up with html, css, js and flask.

I can only imagine how frustrating it is for the average user when they click on an "unhydrated" button that does nothing. JS frameworks embracing SSR is definitely a step in the right direction compared to the fully client-side apps of the previous hype cycle, and yet in many cases can still present worse UX than PHP sites of yore.

Well, that's too bad. PHP got it right and every "new" technology has been quickly replaced with something "newer" (that makes all the same mistakes). Spring -> Ruby on Rails -> Django -> Angular -> Ember -> React -> Next/Nuxt/Noxt/Nixt/Nyxt/Nzxt/Corsair

Are you tired yet?

> React on the server is not PHP

I took this headline to be a dig against React on the server, but I guess the author intended the opposite.

I think a lot of people make the mistake of conflating Wordpress development with PHP development.

If you prefer your full-stack development in Java, definitely check out Flavour. It gives you the benefits this article claims to want but without the weakly-typed languages and all of their attendant footguns:

Flavour book: https://frequal.com/Flavour/book.html

I like PHP and javascript.

Jquery wasn't pretty but it did smooth over browser differences (as someone who had to target a blackberry browser, I still respect it.)

Vue/ React and company are pretty amazing. But sometimes I wonder if they're too much for a lot of the use cases they're used with. I find a fair number of sites that don't quite work.. that could have used a simple form. The "javascript form check" before submission seems to be quite frequent. Webpack is a pain frankly.

modern php is pretty amazing. Though the trend of getting on the upgrade hamster wheel and frameworks use of the latest/greatest makes it harder to like. When I run into a perl script at work, there is some relief that it will probably work, as perl just isn't changing (warts and all).

https://www.php.net/supported-versions.php

I used PHP to write a back end for a mobile app 14 years ago. It got the job done mostly fine.

Now I'm doing the same thing, and decided to go with Deno because I wanted to learn JavaScript.

Does something like Next replace something like Deno, or does it work with it?

All this Next.js SSR is just reinventing the wheel again with spaghetti code, only to be fancy and trendy. The next big invention will be template isolation, something that was done many years ago.

a nice write-up, I happened to start learning next.js this weekend and in a few hours I actually like what I saw, will continue the learning definitely.

If you need to clarify that something isn’t something else, because it isn’t obviously different, maybe the two are more alike than you’d like to admit.

On that note, I’m a happy PHP developer, PHP doesn’t suck anymore (https://youtube.com/watch?v=ZRV3pBuPxEQ), and there is no way to say JavaScript doesn’t have at least as many footguns now. (Personally, I think JavaScript’s footguns - like the ludicrous dependency trees and framework churn - are actually worse.)

It’s still HTML, CSS and something. It’s different but not that different except now you use JS frontend and backend. It’s also not 2002 anymore.

Which framework does he suggest? Next, remix or svelte kit? I’m sure there are more. Which one will become dominant?

> Now, here's where it gets exciting! We're not going back to PHP

We're moving to PHP++!

Mostly because the people still clinging to php are grifters and idiots, in my experience. I guarantee you can't save the php quagmire I was asked to fix.