What's TypeScript compiling? Use a treemap to find out

Yep, typechecking performance will be drastically improved. Using the trace generator [0], I discovered tsc spent more than three seconds [1] to locate and parse all source files googleapis pulls in during type checking. Replacing it with the individual packages almost completely eliminated that overhead.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;TypeScript&#x2F;wiki&#x2F;Performance#performance-tracing" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;TypeScript&#x2F;wiki&#x2F;Performance#per...</a> [1] <a href="https:&#x2F;&#x2F;user-images.githubusercontent.com&#x2F;2109932&#x2F;176479729-501d68c3-0c26-4d16-98df-c8ef3f23a290.png" rel="nofollow">https:&#x2F;&#x2F;user-images.githubusercontent.com&#x2F;2109932&#x2F;176479729-...</a>

This is a neat summary of how they shaved some source and developer time!<p>A trick I&#x27;ve used to shave <i>bundle sizes</i>: re-mapping `babel-runtime&#x2F;*` to `@babe&#x2F;runtime` and proper core-js imports and `core-js` imports from V2 to V3 latest imports ones. This shaved tons off of my bundles (unfortunately have some libraries we rely on that are both substantial but old)<p>Another one is library deduping. I&#x27;ve re-mapped all of the `lodash.*` to be direct default imports, e.g. `lodash.merge` to `lodash&#x2F;merge`. Also shaved a ton off my bundle sizes.

AWS used to have this problem, which is why their JS framework now recommends only installing and importing parts of the API you need: <a href="https:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;sdk-for-javascript&#x2F;v3&#x2F;developer-guide&#x2F;migrating-to-v3.html" rel="nofollow">https:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;sdk-for-javascript&#x2F;v3&#x2F;developer-...</a>

Surely this is not shaving from the <i>build</i>? It&#x27;s shaving from the source. The build would never have 80MB of TypeScript types included.

The googleapis package is absolutely ridiculously large (and the design is such that you can&#x27;t import only part of it which is how it should work). I was able to remove it by depending on `google-auth-library` (an official package that googleapis uses under the hood) instead, but YMMV.

After years of testing different JS frameworks and build systems, I became convinced that heavy Javascript frontends are <i>generally</i> a bad model for the web.<p>One thing is to generate a build and ship it once over the wire in the form of an Installer or bytecode executable. Another thing is to ship the entire package and&#x2F;or parts of it with every launch event, plus the complexity of shipping transpiled code to different interpreters (different browser in this case) which adds more complexity to the model until it finally explodes.<p>The server side with HTML generated at the backend is a more predictable, faster and simpler approach. Bandwidth is not the issue anymore, but latency. Heavy API consumption from the client, leaves data exposed and increases the latter.<p>Hotwire&#x2F;Turboframes&#x2F;StimulusJS removed the need of generating HTML code at the client, leaving a single source of truth while still having a dynamic&#x2F;friendly frontend. I consider it to be a better model for the web.<p>Plus, new Page Transition API and Navigation API are possibly game changers for a lot of use cases out here.

That treemap looks neat. Knowing which dependencies pull in a lot of code is very useful.<p>What confuses me though is how much space these libraries take.<p>321kb for a router? 3.4mb for material ui? 1mb for jquery?

oh wow, I&#x27;m definitely trying ! Thanks for sharing.<p>edit: It removed 85mb and saves 8 seconds of build time (about 17%). Less impact in build time than I thought but still the easiest win I got lately.

In projects where the node_modules folder starts to get out of hand, I set `&quot;skipLibCheck&quot;: true,` in the compilerOptions of my tsconfig file (at least for dev builds).<p>In my understanding, it skips type-checking any d.ts files (which most packages include by now) which dramatically lowers compile time. In the authors case it looks like their project is about 400kb of their own code and then 30mb of node_modules libraries.<p>I think it also skips your own d.ts files (it isn&#x27;t limited to node_modules), so this might just be a way to dramatically speed up your footgun. I have literally never written my own d.ts file though so it works for my purposes

Incidentally, I also ran into this exact problem with the same package. I briefly thought, &quot;they should let us download individual packages&quot;, but since I was already about to bundle everything with esbuild, I didn&#x27;t look into it.<p>So that&#x27;s what I ended up doing: using esbuild. It should only be including what is in use, and the result was fine, even though this service was the largest of the services. But I&#x27;m still going to install the separate package and see how much that brings the bundle size down.

PHP has native way via composer to clean up unneeded google APIs: <a href="https:&#x2F;&#x2F;github.com&#x2F;googleapis&#x2F;google-api-php-client#cleaning-up-unused-services" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;googleapis&#x2F;google-api-php-client#cleaning...</a>

Oh so it’s not just the google ads grpc Python library that is brutal to live with

So we are building a hub for task specific scripts for the needs of Windmill and hitting exactly this. We ended up not being able to use googleapis because it was too hard to import reliably with Deno. So in the end, we are ending up reimplementing a collection of per-task importable collection of googleapis. Example: <a href="https:&#x2F;&#x2F;hub.windmill.dev&#x2F;scripts&#x2F;gdrive&#x2F;1279&#x2F;delete-shared-drive-gdrive" rel="nofollow">https:&#x2F;&#x2F;hub.windmill.dev&#x2F;scripts&#x2F;gdrive&#x2F;1279&#x2F;delete-shared-d...</a> that have permalink so you can use them in your own scripts: <a href="https:&#x2F;&#x2F;hub.windmill.dev&#x2F;raw&#x2F;101&#x2F;delete_shared_drive_gdrive.ts" rel="nofollow">https:&#x2F;&#x2F;hub.windmill.dev&#x2F;raw&#x2F;101&#x2F;delete_shared_drive_gdrive....</a>

In general you should remove things you don’t need.

The types of aws-sdk is also non trivial. So I always suggest to remove typescript during build phrase (only deploy in js)

I wonder if it would be consistently faster if we replace a few hot paths with WASM in tsc.

yup. i had a project consisting of 3 node&#x2F;ts services where each tsc instance would balloon to 4gb+ memory usage due to googleapis, ooming my 12gb thinkpad

Eighty. Million. Bytes.

<p><pre><code> Not only that, but you will substantially improve your lighthouse&#x2F;pagerank score by removing GoogleTag&#x2F;API&#x2F;AdSense&#x2F;etc.. scripts.</code></pre>

Getting hammered to reduce page load time during development only to have people slather a bunch of 3rd party APIs on at deployment time may not take the gold medal for soul crushing experiences, but it ranks at least an honorable mention, possibly a bronze.<p>You just undid 3 months worth of work that will take 6 to replicate. Congratulations. We&#x27;re all really impressed down here.