Live data from Hacker News

Etsy Moves from React to Preact

github.com

21–30 of 71 posts

Re: Etsy Moves from React to Preact

#21

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.

Yeh, I read most of the article looking for more advantages of Preact other than just reduced bundle size but that seems to be basically it, or at least all that the write up covers. Did I miss something?

Re: Etsy Moves from React to Preact

#22

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

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.

Re: Etsy Moves from React to Preact

#23

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.

The way people bundle React with the rest of the user code on its own domain, 0% of the users would have React on their browsers already. It was already not true for the vast majority of jquery and this is a myth that should die/a reality that never happened (I cannot seem to find the article with the study now to prove it though...).

Re: Etsy Moves from React to Preact

#24
post #18

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.

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 int…

> 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.

If this were true, wouldn't it apply in equal measure to other resources?

And if that's true, then why do we still see multiple MB large pages that are full of images or even videos? Personally, the arguments expressed in "The Website Obesity Crisis" back in 2015 still hold up today in my eyes: https://idlewords.com/talks/website_obesity.htm

In short, for me to agree with your argument, i'd have to see websites in general take the path of using less images when not necessary, or optimize them better and use slightly lower resolutions etc.

Opening the first random news site that came to mind, BBC, yields over 5 MB of data and almost 100 network requests: https://www.bbc.com/

Opening Reddit means almost 15 MB of data and has around 235 network requests: https://www.reddit.com/

Opening YouTube means almost 12 MB of data and has around 90 network requests: https://www.youtube.com/

Sure, there are techniques to minimize this impact and compression that everyone should be using for their content, but if the big companies are doing something like this, then clearly the majority of people don't really care. To me, it feels like the thing that we should be doing is just putting less content in pages, less functionality, less widgets etc.

Case in point: https://old.reddit.com/

It needs less than 3 MB of data to load and while around 90 network requests is still bad, as a consequence of the smaller size, it loads more quickly!

(note: the imporance of compression cannot be overstated, but at the end of the day even if your 15 MB compresses down to 5 MB, your browser still needs to handle all of that stuff locally, process the JS, CSS and HTML and display all of your media anyways, as well as keep it in memory, so i'd say that both the full size and the compressed size matters, decreasing the former obviously being good for the latter as well)

On a similar note, there is a really interesting site called "What Does My Site Cost", which allows to further illustrate the bloat, for example: https://whatdoesmysitecost.com/index.php?testID=220205_BiDc8...

Back on topic, i think that Preact, Svelte and even Vue are all pretty cool lightweight options for front end development!

Re: Etsy Moves from React to Preact

#25
post #7
post #6

Does anyone know how to get off Angular?

Do you mind to share why?

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-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.

Re: Etsy Moves from React to Preact

#26

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.

The likelihood of anyone having React in their browser cache is lower than it ever was with jQuery.

(and it was low with jQuery)

Re: Etsy Moves from React to Preact

#27

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.

The other comments hit some spots (although today with the use of bundling, I'm not sure caching matters as much as people make it out to), but something that is currently missing from the conversation: parsing performance. Not the speed that the browser fetches the .js file (which depends on network quality) but rather the speed the browser parses the actual code, which can sometimes become the bottleneck. Larger projects adds more code for the browser to parse, and that will make the initial page-load performance worse. Smaller scripts === faster page-load, which improves user-experience and all metrics related to that.

Re: Etsy Moves from React to Preact

#28

> 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…

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.

Re: Etsy Moves from React to Preact

#29
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?

Re: Etsy Moves from React to Preact

#30
post #18

Earlier quoted context omitted.

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 int…

> 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. If this were true, wouldn't it apply in equal measure to other resources? And if that's true, then why do we still see multiple MB large pages that are full of images or even videos? Personally, the arguments expressed in "The Website Obesity Crisis" back in 20…

> If this were true, wouldn't it apply in equal measure to other resources?

No. On sites that buy in to react/preact, there are parts of the site that won't work until react/preact has loaded.

In contrast, the site will work perfectly fine without having loaded those large beautiful images. If done correctly, images won't even affect the layout of the page.

Likewise, it doesn't matter if google analytics and the 10 thousand myriad tracking pixels take a minute to load: users shouldn't notice any difference here.

> but if the big companies are doing something like this, then clearly the majority of people don't really care.

Companies are complicated beasts. Using react or preact is entirely a predicament of the technical team. Nobody from marketing, sales, business could care less about it.

However, marketing _needs_ (that's how they put it) those myriad tracking pixels because otherwise they can't track the effectiveness of their campaigns.

Corporate wants those custom fonts and beautiful, large images because real people have said the site looks much better with them in usability tests (done using enterprise-level network connectivity of course).

Sales people will go to war over having analytics, as otherwise they don't know how effective their campaigns are, and business loves the nice dashboards there so they back them up.

The tech team decides that given the pace at which complicated interactive features are coming in going the plain html + sprinkle of vanilla javascript is untenable (partly due to whats-cool-today syndrome).

In the end you get these big, "bloated" sites as a result. What users actually want is just a small factor in all this.

Post reply on HN