Wow, the modern PHP community is on fire! I had no idea. I basically rage-quitted PHP years ago, after repeatedly inheriting a series of Wordpress wrecks.
Just curious, how does a PHP application handle server side rendering? By shelling out to a headless browser? What if the content is so personalized that server side caching isn't helpful, is it still viable to SSR a React client?
>Wow, the modern PHP community is on fire! I had no idea. I basically rage-quitted PHP years ago, after repeatedly inheriting a series of Wordpress wrecks.
There still are Wordpress wrecks, and will be until the end of time. But there's a lot of good PHP code being written now, it's going through somewhat of a renaissance. Lots of good work being done with Symfony.
>Just curious, how does a PHP application handle server side rendering? By shelling out to a headless browser? What if the content is so personalized that server side caching isn't helpful, is it still viable to SSR a React client?
I haven't done SSR for React with PHP, but this react library [0] runs v8js, so it's not as heavy as a headless browser. The Angular2 team is building SSR for PHP now but hasn't released it. From scanning the GitHub issues it looks like they're taking the same approach (v8js) [1].
Same here, I left PHP during the early 5.x releases. Unfortunately, I inherited some Symfony applications recently. Unfortunately, because the whole stack is terribly slow and held together by an insane amount of YAML and XML configuration files. Add "annotations" (that are parsed out of doc blocks and compiled into another bunch of PHP files) to the soup and party like it's 1998. That pile of classes you end up with will serve quite some traffic behind a good caching layer, typically in the shape of a well configured Varnish instance. Needless to say that runnig this on your own machine during development will not exactly give you the excitement of working on a fast, modern platform. Rest assured, "print_r() and die()" is still a thing.
Besides that, memory management is mediocre; just DON'T do long running processes with PHP. You want to enable a module? Good luck finding the right php.ini. Keeping a persistent connection pool to a database or similar is generally hard and intransparent, due to the fact that each instance serves exactly one request, but hey, at least PHP "automatically recovers" from errors...
> Unfortunately, I inherited some Symfony applications recently. Unfortunately, because the whole stack is terribly slow and held together by an insane amount of YAML and XML configuration files. Add "annotations" (that are parsed out of doc blocks and compiled into another bunch of PHP files) to the soup and party like it's 1998.
That sounds like a wrong configuration and/or architecture. Symfony is in my experience fast if you follow the best practices.
Maybe you should find out the bottlenecks before you blame Symfony.
> just DON'T do long running processes with PHP.
We run long-running workers just fine.
> You want to enable a module? Good luck finding the right php.ini.
That depends on your OS. In Debian/Ubuntu you just run phpenmod module and restart the service.
I don't know... Your criticism seems to stem from not looking at the issues closely, or maybe you were stuck in a really old, abandoned system. But that woukd have been ugly regardless of language.
I guess your comment wasn't written to be answered, but please note that the lack of validity of your arguments prove how badly you know PHP.
In the En Marche platform project, we serve million of users per month, with fast response times, deployment without downtime, 4 mail workers and multiple PHP instances in paralell synchronizing cache using Redis. I personally worked on several projects having the same infrastructure and the same high quality standards.
I think that, as many other developers, you have a strong but irrationnal opinion on PHP and will do everything in your power to attack it. I hope this kind of behavior will fade in the future, as it should not represent our community.
At my previous place of work, we used the V8js extension to fire up a V8 VM, send data to it and render react components to strings. Worked really well, especially with some caching in place.
Of course, we also moved to Amp and a PHP-cli-running-async-http-server model, so we can share the in memory extension, and did some cute stuff with Redis to get it running stupidly fast without memory leaks. Good fun really, PHP 7.1 is damned nice in a lot of ways, but annoying in others still.
I don't follow. Server-side rendering did you mean rendering html? It would be the same as non-JS rendering engine framework the server side sends out the html after the template file is rendered on the server side.
Yeah I had the same double-take at the question. Pretty sure he's specifically talking about server-side rendering of React or other SPAs. The article talks about how they used React and handled rendering of components.
React, as it initializes into a server rendered DOM on the client, has a requirement that the server rendered markup is exactly identical to that which it would have rendered itself as an SPA. TL:DR this is required by the shadow DOM, an optimization that is responsible for much of React's efficiency in browser DOM manipulation.
When your client and server are both running the exact same UI code, then keeping the server rendered HTML in sync with the initial state of the client side DOM, is just a matter of keeping the application state in sync. That is done be serializing it into the response and then reading it from the client side app during init.
But, if the server is using an entirely different codebase to render HTML, then it would take heroic automation to keep that in sync with what the client expects. Better to just use a different type of client side framework, in that case, I guess; seeing React clients backed by servers that are written in neither JS nor compile-to-JS languages is another surprise.
- React doesn't require the existing markup to match - it will happily clobber whatever it finds lurking in its container. The first render is probably faster if it matches, but it isn't like your page is going to crash if they are out-of-sync.
- The Shadow DOM is a way to encapsulate styles/state in DOM elements - it's what draws the slider thumb in an <input>, and what allows Web Component styles to use simple selectors like "button" without commandeering the all the buttons on the host page. It has nothing to do with React. I think the phrase you're looking for is "virtual DOM".
I assume given their setup that they were only using React for interactive components and the rendering / routing was done server side in good old PHP by their framework.
server side rendering is the mess people will inherit in a few years.
I can already see the HN posts: "I rage-quit X because of all the mess I inherited where the developers didn't want to learn proper javascript, so they just added so much abstraction they had to use hacks to pre-render it on the server"
> so they just added so much abstraction they had to use hacks to pre-render it on the server"
Actually, you have that exactly backwards. It's only because of React's abstraction of the DOM that it's even possible to render using a simple JavaScript interpreter running on the server side.
You do understand that server-side rendering is not (typically) necessary, right? I mean, React will render just fine initially on the browser, of course. It's only done (wisely) on the server before serving to the client for performance reasons.
PHP is becoming nicer and nicer over time :) . Perhaps would it be worth a new try?
In the project, we didn't use server-side rendering: what I meant in the article was that the basic HTML was a first version then replaced by React, on the client side. The React component has different code than what was rendered initially, but for our usage it's not an issue.
Just curious, how does a PHP application handle server side rendering? By shelling out to a headless browser? What if the content is so personalized that server side caching isn't helpful, is it still viable to SSR a React client?