[zimmerx]

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

[KronisLV]

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

[kilburn]

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

[KronisLV]

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

So much for me being able to open 100-200 tabs across all windows on my browser without needing more RAM.

Or even using a browser on my older phone without it feeling slow/sluggish or the browser killing the battery life of the device.

To clarify for the downvoters: my point is that it might not matter for the average user for whom the site is optimized, they might be able to tolerate ads, autoplaying videos, popups, incredible waste of resources just to get visually attractive UI etc. and be none the wiser about any of it (possibly not even knowing that things could be different), but it definitely matters for people who want more out of web in regards to usability.

In my eyes, there's little difference between the current state of web and using Electron for desktop applications instead of native solutions, both seem to be driven by financial initiatives and result in a degraded experience, playing directly into Wirth's law and thus making interfacing with computers worse as a whole (though admittedly the state of the web feels more malicious than a team wanting one Electron codebase for multiple platforms).

[kilburn]

Hey, I said "users", not "evil hackers doing weird things" ;)

The sad thing is that this isn't entirely a joke. I've brought up those kind of issues in executive meetings in the past (trying to exterminate battery-draining animations being a particular crusade of mine).

The response is a mix of blank stares, mild interest... and a quick dismissal from the top dog in the room, along the lines of: "That's certainly something to consider, but I think we have more pressing matters in our hands. Let's keep these on the back burner."

I don't even try anymore :(

[KronisLV]

I've definitely run into this in my own past as well. On one hand, you can understand the business incentives - ship something relatively quickly, have it look good enough to attract attention or at least not scare anyone away.

For example, compare the front pages of SourceHut (a lovely and lightweight project) https://sourcehut.org/ and GitLab (a really good self-hostable solution with plenty of features) https://about.gitlab.com/

One of those would capture the attention of most people better, so that's what the market will optimize for at large, unfortunately also sometimes pushing focusing on other things with less visibility (to the average user) to the back.

For the simpler things, not asking for permission can be a good idea (depending on the environment and circumstances) - a line that i heard in a software development conference once was: "You don't ask your manager for permission to write tests for your code, so why should you for making other similar decisions that are essentially just doing your job well?"

Of course, then you also become responsible for the potential impact of those changes and things going wrong, so it works better on simpler cases/optimizations and only as long as the things you're changing are simple enough to have almost no impactful bugs or you have enough tests in place to catch any.

Other times you can succeed by adopting a data driven approach and a healthy helping of taking initiative: "Hey, our automated performance tests indicate a regression in page load times of X% after version Y, which, according to these random but serious looking studies and posts might result in lost potential conversions and could cost us Z$ the following year. I've described these problems and what to do in Jira issue #W and have escalated the priority to 2, so that's what i plan on doing this week. Any questions?"

[zelphirkalt]

The "if done right" portions of the comment are huge ifs though and almost no one does it right.

[zimmerx]

Maybe I should have been clearer with me follow on paragraph where I talk about parsing of JavaScript and downloading of that - rather than all other assets. I agree with you that the web is broken and that we send way too much to the client in the first place.

However, there are many ways of mitigating additional assets getting in the way of both being able to interact the site and see it within a reasonable amount of time. We look at this through the lense of performance, where downloading some assets in the background might not necessarily harming your experience.

That's not to say we shouldn't be optimising for the smallest amount of network requests a site should make and think carefully about when to load images in. Your examples are what bad looks like and it's a shame, but there are now more and more sites that do a stellar job (or starting to) of giving you a great experience with less downloaded.

However if you were to download a 5mb image asynchronously that isn't part of your initial above the fold, Vs a 5mb payload of react that's needed to run the site... I know which one is going to make your browser a very unhappy bunny.