4 ms·
> 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/vani
by hardwaresofton 5y ago
> 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
- i_hate_pigeons 5y agoI imagine the client facing pages are very sensitive to seo/crawling so that's why they go for server side rendering
- elyobo 5y agoIn theory it shouldn't matter but you can SSR with React if that's important.
- youngtaff 5y agoProblem 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
- capableweb 5y agoI 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.
- bsaul 5y agoserver side rendering also points you toward more cacheable content. Things you put on a CDN are faster and way cheaper.
- ihateolives 5y ago> The unreasonable effectiveness of PHP It's feels almost as if... PHP was made for this web stuff. What a lucky coincidence!
- zelphirkalt 5y agoI 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".
- imbnwa 5y agoEarly 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.
- pjmlp 5y agoOne 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.
- imbnwa 5y agoAMP 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"
- notpachet 5y agoEtsy having Rasmus Lerdorf (the author of PHP) on their payroll doesn't hurt.
- hardwaresofton 5y agoTIL, that makes a lot of sense