[evmar]

I worked on JS infra for Google. One thing we found in this space is that when your apps get very large in terms of number of source files, there is a developer-impacting load time cost to the unbundled approach.

That is, your browser loads the entry point file, then parses it for imports and loads the files referenced from there, then parses those for imports and so on. This process is not free. In particular, even when modules are cached, the browser still will make some request with If-Modified-Since header for each file, and even to localhost that has time overhead cost. This impact is greater if you are developing against some cloud dev server because each check costs a network round-trip.

However this may only come up when you have apps with many files, which Google apps tended to do for protobuf reasons.

[moritzwarhier]

Google apps always seem to stand out with an especially large amount of requests. Does Google use a proprietary module system for these runtime imports?

I've only seen this from afar when using the Maps JS API.

[inglor]

This is the "don't download code you don't run" and "don't ask for data you don't need yet" with smart prefetching and caching. Mostly facilitated using an internal 3 letter framework in Google.

If you want a de-googled approach for "only code you need" check out qwik by Misko Hevery who worked on a bunch f JS related things and a few others. The concept is "resumability".

(not sure if that's what you entirely meant since your example was the maps api)

[moritzwarhier]

Thanks for the tip, I'll look at quik!

My only experience with the approaches you mention so far has been code splitting and dynamic imports with webpack.

Yes my example was a bit misleading as it's probably not specific to the maps JS API. Just remembered my casual observation of the network requests when embedding Maps using the JS API.

Also saw that there were lots of tiny cacheable requests and overall great performance.

[lern_too_spel]

Lit? https://developers.google.com/marketing/engineering/librarie...

[sitkack]

Is the article targeted at Google use cases? The vast majority of programmers probably write less than 50kloc of code in their entire life and work on projects with a handful of files.

[DoesntMatter22]

50k in their entire life??? That's insanely low/inaccurate

[sitkack]

What do you think it is? 100k, 200k?

GP was humble bragging in a way that focused on them rather than the discussion. Deno's autoloading isn't targeted at a Google3 TS application that takes 8hrs to build.

[DoesntMatter22]

On most weeks I'm doing 2k or better. So, assume 50 weeks a year, 100k per year. Assume most developers do at least 10% of that (which is crazy low, has to be much higher in general), so 10k per year. You have a 30 year career that is 300k in a career.

Even that is extremely low. That is only 37 lines of code per day. Anywhere I worked you are getting fired if you are only doing that (unless you are just bug fixing all day, etc).