专栏名称: 蚂蚁金服ProtoTeam
数据前端团队
目录
相关文章推荐
宝山消防支队  ·  以案为例 |《油锅起火怎么办?》 ·  昨天  
前端早读课  ·  【第3459期】两款 AI 编程助手 ... ·  昨天  
前端之巅  ·  Dagger:我们用 GO 和 ... ·  2 天前  
前端早读课  ·  【第3458期】React ... ·  2 天前  
51好读  ›  专栏  ›  蚂蚁金服ProtoTeam

Turbo: 5x faster than Yarn & NPM, and runs natively in-browser

蚂蚁金服ProtoTeam  · 掘金  · 前端  · 2017-12-08 03:00

正文

Introducing Turbo: 5x faster than Yarn & NPM, and runs natively in-browser 🔥

Note: This is part of a talk I’m giving at Google’s Mountain View campus on Wednesday, December 6th — come join !

After four months of hard work, I’m excited to finally announce Turbo ! 🎉

Turbo is a blazing fast NPM client originally built for StackBlitz that:

  • Installs packages ≥5x faster than Yarn & NPM 🔥
  • Reduces the size of node_modules up to two orders of magnitude 😮
  • Has multiple layers of redundancy for production grade reliability 💪
  • Works entirely within your web browser, enabling lightning fast dev environments ⚡️
Actual installation speed of NPM packages using Turbo on StackBlitz.com

Why?

When we first started working on StackBlitz , our goal was to create an online IDE that gave you the same feeling as being behind the wheel of a supercar: that giggly delight of receiving instantaneous responses to your every command.

This contrasts with the experience NPM & Yarn can provide locally. Since they’re designed to handle massive dependencies backend codebases require for native binaries & other assets, their install process requires something more akin to a semi-truck than a supercar. But frontend code rarely relies on such massive dependencies, so what’s the problem? Well, those dependencies still slip into the install process as dev & sub-dependencies and are downloaded & extracted all the same, resulting in the infamous black hole known as node_modules :

This is the crux of what prevents NPM from working natively in-browser. Resolving, downloading, and extracting the hundreds of megabytes (or gigabytes) typical frontend projects contain in their node_modules folder is a challenge browsers just aren’t well suited for. Additionally, this is also why existing server side solutions to this problem have proven to be slow, unreliable, and cost prohibitive to scale .

So, if NPM itself can’t work in the browser, what if we built a brand new NPM client from the ground up that could?

The solution: A smarter, faster package manager built specifically for the web 📦

Turbo’s speed & efficiency is largely achieved by utilizing the same techniques modern frontend applications use for snappy performance—tree-shaking, lazy-loading, and plain ol’ XHR/fetch with gzip.

Retrieves only the files you need, on-demand 🚀

Instead of downloading entire tarballs, Turbo is smart and only retrieves the files that are directly required from the main, typings and other relevant fields. This eliminates a surprising amount of dead weight in individual packages and even more so in larger projects:

Comparison of total compressed payload size for RxJS and RealWorld Angular

So what happens if you import a file that’s not required by the main field, like a Sass file for example? No problem—Turbo simply lazy-loads it on-demand and persists it for future use, similar to how Microsoft’s new GVFS Git protocol works.

Robust caching with multiple failover strategies 🏋️

We recently rolled out a Turbo-specific CDN that hydrates any NPM package in one gzipped JSON request, providing massive speed boosts to package installations. This concept is similar to NPM’s tarballs which concats all files in a package and gzips them, whereas Turbo’s cache intelligently concats only the files your application needs and gzips them.

Every Turbo client runs standalone in-browser and automatically downloads the appropriate files on-demand directly from jsDelivr’s production grade CDN if a package fails to be retrieved from our cache. But what if jsDelivr goes down too? No sweat—it then switches over to using Unpkg’s CDN instead, giving you three separate layers of redundancy for ultra reliable package installations 👌

Lightning fast dependency resolution ⚡️

To ensure minimal payload sizes, Turbo uses a custom resolution algorithm to aggressively resolve common package versions whenever possible. It’s also insanely fast & redundant: the serverless version of the resolver has access to NPM’s entire dataset in-memory and resolves any package.json in <85ms . Should Turbo have any problems connecting to the serverless resolver, it gracefully fails over to running completely in-browser and retrieves all required metadata for resolution.

Doing dependency resolution on the client also opens up some new & exciting possibilities, like the ability to install missing peer dependencies in just one click 😮:

Because no one reads those warnings that npm pipes into the console 😜

Proven to work at scale 📈

Turbo is now reliably handling tens of millions of requests every month with negligible overhead cost, and we’re also excited to announce that Google’s Angular team recently chose StackBlitz to power all the live examples that millions of developers use in their docs!

Now in technology preview 🙌

Turbo is live on StackBlitz.com and during the technology preview phase we’ll be running a ton of tests & releasing speed, efficiency, and reliability improvements, all of which your feedback is critical on — so please don’t hesitate to file any issues you run into or to chat with us in our Discord community ! 🍻







请到「今天看啥」查看全文