What do you mean? I guess as the thread gets deeper it loses some specificity in replies, so assuming you're talking to me...
Do you mean does jQuery's size matter in developing countries? Yes, of course, it matters. But you may not understand the details of what I'm saying if you don't know why it doesn't matter as much in the "progressive enhancement" scenario I'm referring to.
In a "progressive enhancement" scenario jQuery doesn't block anything important before it loads. HTML is server-side rendered (SSR) and jQuery doesn't block either rendering or interaction. While jQuery is loading, the end user can view content and click on links and navigate. If jQuery doesn't load, some functionality and some widgets may not be available, but there will be a worthwhile and usable experience.
If someone adopted jQuery today and used it and dozens of direct and hundreds of transitive dependencies to build a single page application (SPA) that was client-side rendered (CSR) only, it would perform just as poorly as a similarly-architected and similarly-implemented React app. But it wouldn't be because it's 88kb compared to React's 30kb (last I checked it's more than that, these must be gzipped sizes which are only relevant to network transfer time, the parse time correlates more with unzipped size where React + React DOM are >120kb, not to mention the CPU and memory intensiveness of a React app).
It's not usually any single library/framework that makes or breaks performance. It's the architecture and the aggregate. Ironically, React wasn't originally designed, implemented, or used by its authors to build CSR-only SPAs. It was used more like progressively-enhanced jQuery and it's my understanding that is still how it's used on critical Facebook properties. (That may have changed since I last checked in.)
But libraries and frameworks often have architectures that are typically associated with them in their ecosystems. There is plenty of diversity, but still. If you guess that any random React app is a CSR-only SPA, you'll probably be right. If you guess that any random jQuery-using site isn't, you'll probably be right. It was a combination of factors that led to the problems we now see. React + npm + bundlers + CSR-only + SPAs + FAANG cargo-culting SaaS monoculture led us here.
But it's not only "old" Android phones in "developing" countries impacted. It impacts me, a well-paid engineer in a "developed" country, when I'm walking around San Francisco on my current-generation Android phone. In which circumstances a React web app is often painful, if begrudgingly possible, to use (if I am patient). It impacts my users in Idaho with their couple-generations-behind, refurbished iPhones driving country roads with spotty internet. It impacts my uncle, who has an old and occasionally used PC for paying bills. It impacts my mother, who is a technophobe and only uses her Kindle that she has become comfortable with.
On the web, not everyone is like us, and there are far more people not like us than most of the engineers I talk to acknowledge. Not everyone has the wealth, the privilege, the leisure, the connectivity, or the new and powerful machine. The people around us at work aren't the average, typical user. The people at the startup a few streets over who our UX researchers interview are conveniently in proximity, but aren't the average, typical user either.
And no one says when interviewed, "I hope this will work when I'm running late and on the train." But they do wish that when the situation arises. We're capable of delivering it technically, we just don't and that's very sad.
But it's not only "old" Android phones in "developing" countries impacted.
Never said "developing countries". Said "a significant part of the world", that would include all people with old phones.
However, if you want to take that example, some countries have very poor networks, limited bandwidth. The internet is reaaally expensive. Loading external libraries can have a high cost.
I'm not comfortable with the idea of loading all those bytes for nothing, and I remember that web vitals have a significant impact now on SEO.
PS: I like this read. I don't read it at face value, it's just interesting IMHO.
From what I've read its actually even worse than that. In developing countries some phones can have a hard time parsing the libraries. This is why browsers such as UC browser are popular in places like Africa.
Much as I am always ready to be on one about using less JS, sometimes it's not entirely for nothing. PWA app shells are an example of optimizing for first time UX in a scenario where offline support is needed. Building an offline app and/or something like an image editor does have different requirements and trade-offs and a good reason to go heavier on script and care less about startup cost.
I agree with you, and it is something that I've discovered at work. The implementation must sometimes be different, and using CDN for example is not a good solution, especially in countries that do not have the infrastructure for that.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What about developing countries? I think it still matters for certain markets.
What do you mean? I guess as the thread gets deeper it loses some specificity in replies, so assuming you're talking to me...
Do you mean does jQuery's size matter in developing countries? Yes, of course, it matters. But you may not understand the details of what I'm saying if you don't know why it doesn't matter as much in the "progressive enhancement" scenario I'm referring to.
In a "progressive enhancement" scenario jQuery doesn't block anything important before it loads. HTML is server-side rendered (SSR) and jQuery doesn't block either rendering or interaction. While jQuery is loading, the end user can view content and click on links and navigate. If jQuery doesn't load, some functionality and some widgets may not be available, but there will be a worthwhile and usable experience.
If someone adopted jQuery today and used it and dozens of direct and hundreds of transitive dependencies to build a single page application (SPA) that was client-side rendered (CSR) only, it would perform just as poorly as a similarly-architected and similarly-implemented React app. But it wouldn't be because it's 88kb compared to React's 30kb (last I checked it's more than that, these must be gzipped sizes which are only relevant to network transfer time, the parse time correlates more with unzipped size where React + React DOM are >120kb, not to mention the CPU and memory intensiveness of a React app).
It's not usually any single library/framework that makes or breaks performance. It's the architecture and the aggregate. Ironically, React wasn't originally designed, implemented, or used by its authors to build CSR-only SPAs. It was used more like progressively-enhanced jQuery and it's my understanding that is still how it's used on critical Facebook properties. (That may have changed since I last checked in.)
But libraries and frameworks often have architectures that are typically associated with them in their ecosystems. There is plenty of diversity, but still. If you guess that any random React app is a CSR-only SPA, you'll probably be right. If you guess that any random jQuery-using site isn't, you'll probably be right. It was a combination of factors that led to the problems we now see. React + npm + bundlers + CSR-only + SPAs + FAANG cargo-culting SaaS monoculture led us here.
But it's not only "old" Android phones in "developing" countries impacted. It impacts me, a well-paid engineer in a "developed" country, when I'm walking around San Francisco on my current-generation Android phone. In which circumstances a React web app is often painful, if begrudgingly possible, to use (if I am patient). It impacts my users in Idaho with their couple-generations-behind, refurbished iPhones driving country roads with spotty internet. It impacts my uncle, who has an old and occasionally used PC for paying bills. It impacts my mother, who is a technophobe and only uses her Kindle that she has become comfortable with.
On the web, not everyone is like us, and there are far more people not like us than most of the engineers I talk to acknowledge. Not everyone has the wealth, the privilege, the leisure, the connectivity, or the new and powerful machine. The people around us at work aren't the average, typical user. The people at the startup a few streets over who our UX researchers interview are conveniently in proximity, but aren't the average, typical user either.
And no one says when interviewed, "I hope this will work when I'm running late and on the train." But they do wish that when the situation arises. We're capable of delivering it technically, we just don't and that's very sad.
xkcd.com/1367/
Thanks for your detailed comments.
Never said "developing countries". Said "a significant part of the world", that would include all people with old phones.
However, if you want to take that example, some countries have very poor networks, limited bandwidth. The internet is reaaally expensive. Loading external libraries can have a high cost.
I'm not comfortable with the idea of loading all those bytes for nothing, and I remember that web vitals have a significant impact now on SEO.
PS: I like this read. I don't read it at face value, it's just interesting IMHO.
From what I've read its actually even worse than that. In developing countries some phones can have a hard time parsing the libraries. This is why browsers such as UC browser are popular in places like Africa.
That's a great article, yep!
Much as I am always ready to be on one about using less JS, sometimes it's not entirely for nothing. PWA app shells are an example of optimizing for first time UX in a scenario where offline support is needed. Building an offline app and/or something like an image editor does have different requirements and trade-offs and a good reason to go heavier on script and care less about startup cost.
I agree with you, and it is something that I've discovered at work. The implementation must sometimes be different, and using CDN for example is not a good solution, especially in countries that do not have the infrastructure for that.