There are cases where some companies have the business justification to work on writing their own frameworks, like with Facebook. They can use up human resources to really focus on latency at the cost of other metrics.

Other companies juggle their priorities differently, and would probably not want to focus their efforts on replacing React, which has a small API, constantly-updated documentation, a team that responds to issues, and widespread attention and thus lots of discourse. I also think the React layer abstracts away complexity, trading total lines of code for cognitive easiness. Some teams have the business justification for doing things their way -- but I think most don't.

In reality JavaScript size means very little when a single image might be 500k.

Unfortunately I have to disagree. The JavaScript Engine still have to parse and interpret the code. This can take a bit of time, especially on mobile devices.

Parse time shouldn't be very long at all, especially compared to network latency. How long does it take for large (~100-150kb minified) to be parsed and interpreted? I'd be surprised if it's more than 100ms

100ms is noticeable. It's already slow if you reach that.

It's barely above the threshold for detectable live feedback latency, from a musical instrument or sight/sound correlation. As a user veiwing a page with plenty of other latency, it's inconsequential, particularly since you can execute your js while image assets are still incoming.

Maybe, but in terms of understanding the code and having total control over it, it means a lot.

(And I don't buy the large teams can't adopt a self-grown code in the first place. If they're any good, they can. If they're not, then even their React and Angular skills will be bad).

Besides you know all your business logic code? That will be custom too, anyway,and they'll have to adopt it...

Did you not see that headline about how the average page now is the size of a Doom install?

Mainly because an average page has much higher resolution graphics than Doom.

Six years ago I was regularly mining merchant pages containing 1mb+ of HTML. Nowadays that seems to be par for course.

You shouldn't be serving 500k images to mobile users.

It's not so much the time over the wire to download, but the time to parse and run all that JS. If you open up your web dev tools, I think you'll see the impact from a 50k gzipped JS file is probably greater than a 500k image, for one thing the site can probably function without the image loaded, but your page will not be user responsive until that JS has finished executing.

My total image payload is 30k. Obviously getting there is more challenging for other sites, but at the end of the day if your page is >1mb I'm probably not going to wait for it to load

>but at the end of the day if your page is >1mb I'm probably not going to wait for it to load

Average size for the most popular sites has actually grown to ~ 2.5-3MB.

And since they're the most popular, it shows that people DO wait just fine for them to load.

Switch "most popular" to "your site" and it will probably change user's desire to wait for it.

Yeah, that's true.

Also what I left out in my argument is that while popular already, they still might get increased in traffic if they were lighter.

What's more relevant at Facebook's scale is dollars saved per kilobyte shrinked. Because majority of its users will tolerate almost anything at this point, including apps that crash randomly to measure loyalty.

Then you are doing images wrong.

Can you post a link to your app? Would love to see an example of a frameworkless web app.

I'm not sure how the size of your app can possibly say anything about applicability or quality of jQuery.