Hacker News Reader

Comment by hardwaresofton | Hacker News Reader

> One important piece of context is that Etsy currently has two major product stacks. For buyer-facing pages, we use PHP server-based rendering with jQuery/vanilla JS on the client to stitch things together. For our seller-facing pages and many of our internal tools, we use React-rendered SPAs with minimal server-based HTML rendering, receiving data from the same PHP server-side stack.

The unreasonable effectiveness of PHP

[EDIT] Just to add content to foster actual on-topic discussion —- is it likely that Etsy will be the only ones taking this off-ramp from React proper? Seems like the v15 -> v16 jump is onerous

View on HN

> The unreasonable effectiveness of PHP

It's feels almost as if... PHP was made for this web stuff. What a lucky coincidence!

I think it is more that they do not go the "everything must be React" route, that gives them an advantage in that part of the frontend. Way less complex than the whole react ecosystem and it's "components".

Early in its life Facebook Engineering marketed React as "you probably don't know what you're doing with the DOM and incurring all sorts of performance issues with your hand-written Backbone View code, let React do that for you". In truth, you only need a vDOM with a component interface once your view code passes a certain threshold of complexity, but it just gets used everywhere, and for the simplest things, as the go-to solution.

One thing that makes me happy to spend more time on backend stuff, is that I get spared this kind of stuff and just keep doing SSR as I have always done, with a little bit of JavaScript when needed.

The irony to see all JavaScript frameworks re-inventing SSR to deal with the performance problems to do everything on the client, specially mobile phones.

AMP was a clear signal of the extent to which mobile web development was seriously flawed that Google had to go to major content publishers and say "look, your frontend is trash and nowhere near concise enough on mobile in either layout or behavior, just use our transformation layer"

I imagine the client facing pages are very sensitive to seo/crawling so that's why they go for server side rendering

I think it's more about the level of interactivity that is "needed". The seller part of the platform would do a lot of customization and changing settings, some of those probably have live previews as well, whereas the seller part of the platform is pretty static, no need for the same level of interactivity, so doing it by manually manipulating the DOM is manageable.

server side rendering also points you toward more cacheable content. Things you put on a CDN are faster and way cheaper.

In theory it shouldn't matter but you can SSR with React if that's important.

Problem is SSR with a JS framework is often slower than the other equivalents, not sure why but I see it time and again

Then the hydrations costs on the client typically start at 500ms, and that's 500ms the main thread could be doing something useful with

Etsy having Rasmus Lerdorf (the author of PHP) on their payroll doesn't hurt.

TIL, that makes a lot of sense

Reply on news.ycombinator.com