This content originally appeared on web.dev and was authored by Houssein Djirdeh
Chrome is an active contributor to the web framework ecosystem and our talk at Chrome Dev Summit 2019 covers what we've worked on in the past year.
Read on for an extended recap of the talk with additional details and resources.
How do we make the web better?
The goal of everyone on the Chrome team is to make the web better. We work on improving browser APIs and V8--the core JavaScript and WebAssembly engine that powers Chrome--so that developers are equipped with features that help them build great web pages. We also try to improve websites that are already in production today by contributing to open-source tooling in many ways.
Most web developers rely on open source tools whenever possible and they prefer not to build entirely custom infrastructure. Client-side JavaScript frameworks and UI libraries make up a growing portion of open-source usage. Data on the three most popular client-side frameworks and libraries, React, Angular, and Vue, shows that:
- 72% of participants in the MDN's First Annual Web Developer & Designer Survey use at least one of these frameworks and libraries.
- Over 320,000 sites in the top 5 million URLs analyzed by HTTP Archive use at least one of these frameworks and libraries.
- When grouped by time spent, 30 of the top 100 URLs use at least one of these frameworks and libraries. (Research was done on internal data.)
This means that better open-source tooling can directly result in a better web and that's why Chrome engineers have started working directly with external framework and library authors.
Contributions to web frameworks
Frameworks commonly used to build and structure web pages fall into two categories:
- UI frameworks (or libraries), such as Preact, React, or Vue, which provide control over an application's view layer (through a component model for example).
- Web frameworks, such as Next.js, Nuxt.js, and Gatsby, which provide an end-to-end system with opinionated features built-in, such as server-side rendering. These frameworks usually leverage a UI framework or library for the view layer.
Developers can choose not to use frameworks but by piecing together a view layer library, router, styling system, server renderer and so forth, they often end up creating their own type of a framework. Although opinionated, web frameworks take care of many of these concerns by default.
The rest of this post highlights many improvements that have recently landed in different frameworks and tools, including contributions from the Chrome team.
Angular
The Angular team has shipped a number of improvements to version 8 of the framework:
- Differential loading by default to minimize unneeded polyfills for newer browsers.
- Support for standard dynamic import syntax for lazy-loading routes.
- Web worker support to run operations in a background thread separate from the main thread.
- Ivy, Angular's new rendering engine which provides better re-compilation performance and a reduction in bundle sizes, is available in preview mode for existing projects.
You can learn more about these improvements in "Version 8 of Angular" and the Chrome team looks forward to working with them closely in the next year as more features land.
Next.js
Next.js is a web framework that uses React as a view layer. In addition to a UI component model that many developers expect from a client-side framework, Next.js provides a number of built-in default features:
- Routing with default code-splitting
- Compilation and bundling (using Babel and webpack)
- Server-side rendering
- Mechanisms to fetch data at a per-page level
- Encapsulated styling (with styled-jsx)
Next.js optimizes for reduced bundle sizes, and the Chrome team helped identify areas where we could help further improve performance. You can learn more about each of them by viewing their requests for comments (RFCs) and pull requests (PRs):
- An improved webpack chunking strategy that emits more granular bundles, reducing the amount of duplicate code fetched through multiple routes (RFC, PR).
- Differential loading with the module/nomodule pattern which can reduce the total amount of JavaScript in Next.js apps by up to 20% with no code changes (RFC, PR).
- Improved performance metric tracking which utilizes the User Timing API (PR).
We are also exploring other features to improve both the user and developer experience of using Next.js, such as:
- Enabling concurrent mode to unlock progressive or partial hydration of components.
- A webpack based conformance system that analyzes all source files and generated assets to surface better errors and warnings (RFC).
Nuxt.js
Nuxt.js is a web framework that combines Vue.js with different libraries to provide an opinionated setup. Similar to Next.js, it includes many features out-of-the-box:
- Routing with default code-splitting
- Compilation and bundling (using Babel and webpack)
- Server-side rendering
- Asynchronous data fetching for every page
- Default data store (Vuex)
Along with working directly on improving the performance of different tools, we've expanded the framework fund to provide monetary support to more open-source frameworks and libraries. With our recent support to Nuxt.js, a few features are slated to land in the near future including smarter server-rendering and image optimizations.
The framework fund accelerates the efforts of different frameworks and libraries with the goal to improve their performance. If you are working on an open-source tool and need support, please apply!
Babel
We've also made progress on improving the performance of an important underlying tool in almost all of the mentioned frameworks--Babel.
Babel compiles code that contains newer syntax into code that different browsers can understand.
It's become common to use @babel/preset-env to target
modern browsers where different browser targets can be specified to provide enough polyfilling
required for all the chosen environments. One way to specify the targets is to use <script type="module"> to target all browsers that support ES
Modules.
To learn more about how to leverage ES modules to minimize polyfill code shipped to browsers that do not need them, check out Serve modern code to modern browsers for faster page loads.
To optimize for this case, we launched a brand new preset;
@babel/preset-modules. Instead of converting modern syntax
to older syntax to avoid browser bugs, preset-modules fixes each specific bug by transforming to the
closest possible non-broken modern syntax. This results in modern code that can be delivered nearly
unmodified to most browsers.
Developers who already use preset-env will also benefit from these optimizations without having to
do anything, as they'll soon be incorporated into preset-env too.
What's next?
Working closely with open-source frameworks and libraries to provide better experiences helps the Chrome team realize what is fundamentally important to users and developers alike.
If you work on a web framework, UI library, or any form of web tooling (bundler, compiler, linter), apply for the framework fund!
This content originally appeared on web.dev and was authored by Houssein Djirdeh
Houssein Djirdeh | Sciencx (2020-01-08T00:00:00+00:00) Advancing the web framework ecosystem. Retrieved from https://www.scien.cx/2020/01/08/advancing-the-web-framework-ecosystem/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.