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?
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].
[0] https://github.com/reactjs/react-php-v8js [1] https://github.com/angular/universal/issues/281
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...
I left for good.
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.
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.
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'm working on a project now that uses airbnb's hypernova service[0] with a php client[1].
Edit: not suggesting this was used in this case, just that it's a viable option for react ssr + php.
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 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"
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.
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.
Every language can be abused - the degree to which it can be abused is an indicator of its power.