8 ms·

Etsy Moves from React to Preact

64 points by adamsi 5y ago

adamsi 5y ago
News article: https://www.infoq.com/news/2022/01/etst-migration-from-react-preact/ https://www.infoq.com/news/2022/01/etst-migration-from-react...
draw_down 5y ago
> We ran into an error which took us 2 days to track down to a library, and you may find the same. Fun times! Preact is React until it isn't. No reason to assume that won't happen again, by the way. Once upon a time I had some people who wanted to include Preact because it's so small/dependencies/etc. Then they bitched because it wasn't React. Ay yi yi.
jokethrowaway 5y ago
I agree, I don't think there is a compelling reason to use react instead of react. Every time I migrated a client most engineers didn't even notice and you just saved shipping a heavy bundle. Compatibility is really good, most third party components work and the few which don't are covered by alternative implementations.
- radus 5y ago
  I’ve migrated from react to react and it was a breeze
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 ago
  I imagine the client facing pages are very sensitive to seo/crawling so that's why they go for server side rendering
  - elyobo 5y ago
    In theory it shouldn't matter but you can SSR with React if that's important.
    - youngtaff 5y ago
      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
  - capableweb 5y ago
    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.
  - bsaul 5y ago
    server 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 ago
  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".
rvense 5y ago
Does anyone know how to get off Angular?
- alifaziz 5y ago
  Do you mind to share why?
  - KronisLV 5y ago
    Would also like to know why! The old AngularJS was pretty horrible in my experience, but Angular 2+ was leaps and bounds better! As a "batteries included" framework i prefer it to the alternatives that one would typically consider for front end development instead: React, Vue, Svelte etc. (though i would pick Vue/Svelte for more lightweight sites and maybe React because of its ecosystem) That said, it still is pretty heavyweight which can certainly be a drawback, but not too much so unless you get into the reactive programming libraries and such, at least when compared with the alternatives: https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1 https://medium.com/dailyjs/a-realworld-comparison-of-front-e... (this appears to be from 2020 though, someone should do a newer writeup) For the enterprise'y projects that i've seen, Angular seems like a reasonably stable and dependable solution to use. That's in contrast to React, which has needed way more updates in packages that it needs for the typical web project, due to its more fragmented nature. Of course, this might be viewed as a nitpick, but GitHub dependabot seems to page me more for React projects. Also, if you want to use TypeScript (which i might go for, but only in some projects), then in my eyes it integrates with it way better than, say, React or Vue. To me, using TypeScript in React just felt needlessly cumbersome, especially with functional/hook based components. When using React, i'd almost prefer to go for just JavaScript and enjoy the incredible productivity of being able to introduce and compose components very easily, way better than Vue seemed to let me. Of course, i'm probably in the minority here, because i'd go for functional view components and class based parent/container/logic components, but maybe that's just my antiquated way of thinking. Also to conclude my subjective post of sharing my views and experiences, MobX > Redux. It's just wonderfully simple and easy to use for state management.
    - 5y ago
royjacobs 5y ago
One thing I don't understand about the JS ecosystem in general is the focus on minified size. This article does the same thing: preact is 6k or so whereas react is 36k. This comparison seems entirely pointless when the first page load downloads multiple megabytes of assets and, additionally, a lot of users would have React in their browser cache anyway.
- Klonoar 5y ago
  The likelihood of anyone having React in their browser cache is lower than it ever was with jQuery. (and it was low with jQuery)
- Reimersholme 5y ago
- whateveracct 5y ago
  You optimize what you measure
- zimmerx 5y ago
  Speaking from building both react and Preact sites serving millions of customers - the difference is noticeable when you add everything up. Minification or not, starting with a 6x bundle size puts you in a precarious position to have to care more about how it grows over time adding other assets. Downloading, parsing and then executing a larger bundle size will impact performance and we've been able to see time to interactive impact conversion on e-commerce sites. However you are right that there are many other factors at play here that will make the site better and I think the post misses the point about "bundle size". The important differentiation for us with Preact is two things: native support for web components, and a significantly faster library when it comes to transformations and dealing with vdom - see here https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we... On your comment about browser cache, also true but it really depends - if you haven't appropriately split out your bundle then returning users will probably be redownloading react again and again with app updates. Also new users are super important because if you are trying to get new traffic you care about their experience not just returning users.
MoSattler 5y ago
So Etsy wants to replace a core part of their frontend tooling to save 30KB in bundle size?
- jacobmischka 5y ago
  You clearly didn't read the article. It mentions that in addition to the (relatively small) bundle size savings, the version of Preact they were investigating (as of 2020 when it was written) was also more compatible with the current version of React they were using at the time than the newest version of React (15 -> 16 had a lot of breaking changes). I don't believe the bundle size was really a major contributor to the decision honestly.
  - ComradePhil 5y ago
    Doesn't explain why they could not have continued using React 15.
    - jacobmischka 5y ago
      Did you read the article either? > While it would be really hard to describe here in detail all of the new features, the code architecture improvements enabled by the React v16.8 Hooks functionality are so significant that it will eventually become harder and harder to recruit developers interested in working in a pre-Hooks codebase. In order to keep up with the rest of the industry and provide our current developers with the best tooling available, I believe it should be a high priority to enable use of Hooks and other modern React functionality. This definitely isn’t anywhere close to the only new feature worth upgrading for, but it does represent an extremely large shift in how developers will be able to write React code.
      - deleted 5y ago
        [deleted]
  - tracerbulletx 5y ago
    There were almost no significant breaking changes between 15 and 16, the chances of an app even using one of the few APIs that changed was very very small..
codeptualize 5y ago
I wonder what the other differences and considerations are. The article is focused on issues that might arise from switching, but does not really cover the “why” of switching beyond bundle size. A valid reason, but I assume there is something to say for React or is it really that similar that switching is a no brainer?
- tarjei_huse 5y ago
  The way I read the document is that the main reason is that they do not have to upgrade their whole stack including dependencies like React Router. Stepping off the dependency upgrade treadmill is an interesting and valid point that I think many HN readers dream of. It seems to me that Etsy has ended up so far behind current React that going to Preact is a very valid direction to take.
  - codeptualize 5y ago
    I'm not sure I read that in the article. I also don't see why switching to Preact does not require updating, they even mention they will have to do this anyway, including some of their routing dependencies. Preact seems to be keen on keeping compatibility with React, referring to the current and previous versions, so it is very likely updates need to happen regardless. Also, upgrading React is usually not too much effort as for most changes codemods are provided that do most of the work. Not saying it doesn't require effort at scale, but I don't see or read how Preact would make that any easier. Considering you'll use React libraries in Preact I would be worried about upgrading and compatibility later on. I'm honestly interested as the lower bundle size is significant, but I'd like to know the other pros/cons and risks that surely are there.
pictur 5y ago
preact is the most marketing marvel open source project I've ever seen.
deleted 5y ago
[deleted]
hutrdvnj 5y ago
I think the biggest problem with this is that Preact is not a 100% drop-in replacement for React. The devil is in the details. The programmers will casually follow online answers from stackoverflow or blog post regarding React and apply them to the Preact project. This will work more often than not, but from time to time you can run strange bugs, which only happens on Preact and it takes much time to detect and debug them.
- christophilus 5y ago
  I built a product with Preact, and can’t think of any time it’s bitten us like that. I’m sure you’re right, but for us at least, it’s been smooth sailing.
vt85 5y ago

64 points by adamsi 5y ago

News article: https://www.infoq.com/news/2022/01/etst-migration-from-react-preact/ https://www.infoq.com/news/2022/01/etst-migration-from-react...

draw_down 5y ago

> We ran into an error which took us 2 days to track down to a library, and you may find the same. Fun times! Preact is React until it isn't. No reason to assume that won't happen again, by the way. Once upon a time I had some people who wanted to include Preact because it's so small/dependencies/etc. Then they bitched because it wasn't React. Ay yi yi.

jokethrowaway 5y ago

I agree, I don't think there is a compelling reason to use react instead of react. Every time I migrated a client most engineers didn't even notice and you just saved shipping a heavy bundle. Compatibility is really good, most third party components work and the few which don't are covered by alternative implementations.

radus 5y ago
I’ve migrated from react to react and it was a breeze

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 ago
I imagine the client facing pages are very sensitive to seo/crawling so that's why they go for server side rendering
- elyobo 5y ago
  In theory it shouldn't matter but you can SSR with React if that's important.
  - youngtaff 5y ago
    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
- capableweb 5y ago
  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.
- bsaul 5y ago
  server 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 ago
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".

rvense 5y ago

Does anyone know how to get off Angular?

alifaziz 5y ago
Do you mind to share why?
- KronisLV 5y ago
  Would also like to know why! The old AngularJS was pretty horrible in my experience, but Angular 2+ was leaps and bounds better! As a "batteries included" framework i prefer it to the alternatives that one would typically consider for front end development instead: React, Vue, Svelte etc. (though i would pick Vue/Svelte for more lightweight sites and maybe React because of its ecosystem) That said, it still is pretty heavyweight which can certainly be a drawback, but not too much so unless you get into the reactive programming libraries and such, at least when compared with the alternatives: https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1 https://medium.com/dailyjs/a-realworld-comparison-of-front-e... (this appears to be from 2020 though, someone should do a newer writeup) For the enterprise'y projects that i've seen, Angular seems like a reasonably stable and dependable solution to use. That's in contrast to React, which has needed way more updates in packages that it needs for the typical web project, due to its more fragmented nature. Of course, this might be viewed as a nitpick, but GitHub dependabot seems to page me more for React projects. Also, if you want to use TypeScript (which i might go for, but only in some projects), then in my eyes it integrates with it way better than, say, React or Vue. To me, using TypeScript in React just felt needlessly cumbersome, especially with functional/hook based components. When using React, i'd almost prefer to go for just JavaScript and enjoy the incredible productivity of being able to introduce and compose components very easily, way better than Vue seemed to let me. Of course, i'm probably in the minority here, because i'd go for functional view components and class based parent/container/logic components, but maybe that's just my antiquated way of thinking. Also to conclude my subjective post of sharing my views and experiences, MobX > Redux. It's just wonderfully simple and easy to use for state management.
  - 5y ago

royjacobs 5y ago

One thing I don't understand about the JS ecosystem in general is the focus on minified size. This article does the same thing: preact is 6k or so whereas react is 36k. This comparison seems entirely pointless when the first page load downloads multiple megabytes of assets and, additionally, a lot of users would have React in their browser cache anyway.

Klonoar 5y ago
The likelihood of anyone having React in their browser cache is lower than it ever was with jQuery. (and it was low with jQuery)
Reimersholme 5y ago
whateveracct 5y ago
You optimize what you measure
zimmerx 5y ago
Speaking from building both react and Preact sites serving millions of customers - the difference is noticeable when you add everything up. Minification or not, starting with a 6x bundle size puts you in a precarious position to have to care more about how it grows over time adding other assets. Downloading, parsing and then executing a larger bundle size will impact performance and we've been able to see time to interactive impact conversion on e-commerce sites. However you are right that there are many other factors at play here that will make the site better and I think the post misses the point about "bundle size". The important differentiation for us with Preact is two things: native support for web components, and a significantly faster library when it comes to transformations and dealing with vdom - see here https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we... On your comment about browser cache, also true but it really depends - if you haven't appropriately split out your bundle then returning users will probably be redownloading react again and again with app updates. Also new users are super important because if you are trying to get new traffic you care about their experience not just returning users.

MoSattler 5y ago

So Etsy wants to replace a core part of their frontend tooling to save 30KB in bundle size?

jacobmischka 5y ago
You clearly didn't read the article. It mentions that in addition to the (relatively small) bundle size savings, the version of Preact they were investigating (as of 2020 when it was written) was also more compatible with the current version of React they were using at the time than the newest version of React (15 -> 16 had a lot of breaking changes). I don't believe the bundle size was really a major contributor to the decision honestly.
- ComradePhil 5y ago
  Doesn't explain why they could not have continued using React 15.
  - jacobmischka 5y ago
    Did you read the article either? > While it would be really hard to describe here in detail all of the new features, the code architecture improvements enabled by the React v16.8 Hooks functionality are so significant that it will eventually become harder and harder to recruit developers interested in working in a pre-Hooks codebase. In order to keep up with the rest of the industry and provide our current developers with the best tooling available, I believe it should be a high priority to enable use of Hooks and other modern React functionality. This definitely isn’t anywhere close to the only new feature worth upgrading for, but it does represent an extremely large shift in how developers will be able to write React code.
    - deleted 5y ago
      [deleted]
- tracerbulletx 5y ago
  There were almost no significant breaking changes between 15 and 16, the chances of an app even using one of the few APIs that changed was very very small..

codeptualize 5y ago

I wonder what the other differences and considerations are. The article is focused on issues that might arise from switching, but does not really cover the “why” of switching beyond bundle size. A valid reason, but I assume there is something to say for React or is it really that similar that switching is a no brainer?

tarjei_huse 5y ago
The way I read the document is that the main reason is that they do not have to upgrade their whole stack including dependencies like React Router. Stepping off the dependency upgrade treadmill is an interesting and valid point that I think many HN readers dream of. It seems to me that Etsy has ended up so far behind current React that going to Preact is a very valid direction to take.
- codeptualize 5y ago
  I'm not sure I read that in the article. I also don't see why switching to Preact does not require updating, they even mention they will have to do this anyway, including some of their routing dependencies. Preact seems to be keen on keeping compatibility with React, referring to the current and previous versions, so it is very likely updates need to happen regardless. Also, upgrading React is usually not too much effort as for most changes codemods are provided that do most of the work. Not saying it doesn't require effort at scale, but I don't see or read how Preact would make that any easier. Considering you'll use React libraries in Preact I would be worried about upgrading and compatibility later on. I'm honestly interested as the lower bundle size is significant, but I'd like to know the other pros/cons and risks that surely are there.

pictur 5y ago

preact is the most marketing marvel open source project I've ever seen.

deleted 5y ago

[deleted]

hutrdvnj 5y ago

I think the biggest problem with this is that Preact is not a 100% drop-in replacement for React. The devil is in the details. The programmers will casually follow online answers from stackoverflow or blog post regarding React and apply them to the Preact project. This will work more often than not, but from time to time you can run strange bugs, which only happens on Preact and it takes much time to detect and debug them.

christophilus 5y ago
I built a product with Preact, and can’t think of any time it’s bitten us like that. I’m sure you’re right, but for us at least, it’s been smooth sailing.

vt85 5y ago