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.
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.
I think this is all super fair commentary and very balanced. As a Compute@Edge user though how do they test CloudFlare when the ToS says otherwise? Test and break the ToS and hope for the best? It's a bit of a shame that it exists.
Rudderstack user here (and ex Segment). Thanks for sharing this stuff, very cool project.
Just to answer some of this:
- rudderstack has deploy ready helm charts, which I'd argue are significantly better than docker compose or docker setups because they set up all the other niggly parts. Would be cool to see that here :)
- rudderstack has gone quite far away from replacing segment. It's true that their core API is compatible and I think your transformation layer is really cool. However it can be used for those use cases because rudderstack doesn't really care about users or user IDs and can be used for any sort of data generally.
There's a piece in the docs talking about the fact that you don't get caught by adblock - whilst this may be true when someone launches it, that's not true of your platform. That's just the fact that a lot of smaller businesses will not get their URLs added to the ad block lists. I think it's a bit misleading to mention that in such a way because technically we're all tracking users and ad block is a way for users to choose not to be tracked, not be tricked into being tracked because someone has masked the tracking script ;) if a huge client (a la Adidas or something) decided to use your scripts I'm sure someone would eventually add it to the ad block lists that get propagated.
One of the things that would be cool would be some sort of opt in configuration. Segment has some awful consent SDK that is really bad, would be cool to see what you do there. GDPR is a big deal and browser fingerprinting is data processing. It's worth looking at your comments on being GDPR compliant btw https://www.eff.org/deeplinks/2018/06/gdpr-and-browser-finge...
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.