DEV Community: Dan Onoshko

Masonry Grid Goes CSS-Only: An Experimental Approach

Dan Onoshko — Wed, 12 Nov 2025 20:14:25 +0000

I recently published an article about Masonry Grid, and here I am again with another post. What happened?

Well, something interesting popped up in the Reddit comments.

A CSS Trick from the Comments

After sharing the initial release, Zardoz84 in the comments linked to a clever CSS-only masonry example. The example used a neat trick with grid-row: span X to create a masonry effect without any JavaScript.

The original example was hand-tuned for specific content, but the technique itself caught my attention. Could this approach work with dynamic content?

Adapting the Span Trick

The core idea is simple:

.grid {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
}

.item {
  aspect-ratio: var(--width) / var(--height);
  grid-row: span calc(var(--height) / var(--width) * var(--precision));
}

The trick is elegant: each item maintains its aspect ratio with CSS aspect-ratio, then spans multiple grid rows based on that ratio. The precision parameter acts as a multiplier - the higher the value, the more accurately the aspect ratio is maintained.

I adapted this technique to work with dynamic content and aspect ratios, and that's how SpannedMasonryGrid was born:

import { SpannedMasonryGrid as MasonryGrid, SpannedFrame as Frame } from '@masonry-grid/react'

<MasonryGrid
  frameWidth={200}
  gap={10}
  precision={10} // Controls aspect-ratio accuracy
>
  <Frame width={16} height={9}>
    <img src="photo1.jpg" />
  </Frame>
  <Frame width={3} height={2}>
    <img src="photo2.jpg" />
  </Frame>
  {/* More frames... */}
</MasonryGrid>

The Obvious Advantages

No JavaScript Required

The layout is pure CSS. Once the HTML is rendered, the browser handles everything. No observers, no reflow calculations, no JavaScript at all.

Perfect SSR Compatibility

Since the layout is determined entirely by CSS, there's no client-side recalculation after hydration. What the server renders is what the user sees - no layout shifts, no flicker.

The Trade-offs

But it's not all perfect. There are some notable limitations:

Aspect Ratio Imprecision

Due to how grid-row: span works with fractional values, frames can't maintain their aspect ratios with 100% accuracy.

The precision parameter (default: 10) lets you control this:

Lower precision (~10): Less accurate aspect ratios, but very stable
Higher precision (>=100): More accurate sizes, but potential for visual bugs in some browsers with many items

Gap Workaround Required

CSS Grid's native gap property can't be used with this technique - it would break the span calculations. Instead, we use negative margins and padding:

.grid {
  margin: calc(-1 * var(--gap) / 2);
}

.frame > div {
  inset: calc(var(--gap) / 2);
}

It works, but it's a workaround, not a clean solution.

Conclusion

This is an experimental approach - it has trade-offs, and the classic BalancedMasonryGrid and RegularMasonryGrid remain the safer options for most cases. But if the CSS-only nature fits your needs, give it a try!

Check out the interactive examples:

Play with the precision slider and see how it affects the layout. You'll quickly get a feel for the trade-offs.

The library is open source and available on GitHub. Contributions, feedback, and bug reports are always welcome!

Masonry Grid: A 1.4 kB Library That Actually Works

Dan Onoshko — Mon, 10 Nov 2025 07:59:06 +0000

You know that satisfying Pinterest-style grid where images of different sizes fit together like a perfect puzzle? It's a common UI pattern, but implementing it properly has always been surprisingly tricky.

Meet Masonry Grid - a modern, lightweight solution that takes a different approach to this classic problem.

How Can You Build Masonry Layout Today?

Let's look at what options we actually have in 2025:

Option 1: Native CSS Masonry

"Just use CSS Grid's masonry layout!" - sounds great, right? Well...

.grid {
  display: grid;
  grid-template-rows: masonry; /* Sounds perfect! */
}

The problem? It's still experimental. We don't know when it'll land, let alone when it'll be widely available enough to actually use in production.

Option 2: The Classic - Masonry.js

Google "masonry layout javascript" and the first result is Masonry by David DeSandro.

But... The last commit was in 2017 and it weighs something around ~24 kB. In 2025, that feels... outdated.

Option 3: Pure CSS Solutions

"Can't we just do it with CSS?" - technically yes! There are clever CSS-only solutions using CSS columns:

.masonry {
  column-width: 200px;
  gap: 1em;
}

The browser fits as many columns as possible. Looks great! But there are issues:

Items flow vertically (column 1 fills top to bottom, then column 2...) which breaks logical order
Browser compatibility is spotty for edge cases
Only works with static content - good luck adding dynamic data
Not so responsive as you'd like

Option 4: HTML Columns with JavaScript

There's also a composable approach where you create actual column elements in HTML and distribute items between them with JavaScript:

<div class="masonry">
  <div class="column"><!-- items 0, 3, 6... --></div>
  <div class="column"><!-- items 1, 4, 7... --></div>
  <div class="column"><!-- items 2, 5, 8... --></div>
</div>

This gives you proper horizontal order! But here's the catch:

Responsive design becomes tricky. If you want the column count to change based on screen size, you need to recalculate and redistribute items on resize. And that creates another problem...

Server-side rendering. The server doesn't know the screen width, so it can't calculate how many columns to create or how to distribute items.

Enter Masonry Grid

So I decided to build my own solution and share it with you.

Meet Masonry Grid - a 1.4 kB library that works with any framework, compatible with SSR, and is built using modern web technologies to be as fast as possible.

The core algorithm is written in vanilla JavaScript, but there are wrappers for most popular frameworks (React, Preact, Svelte, SolidJS) that feel native to each ecosystem.

The interesting part isn't just the size - it's the approach.

The Key Insight: Let CSS Do the Heavy Lifting

Most masonry libraries calculate positions in pixels and set absolute positioning. This means recalculating everything on every resize. Ugh.

Instead, Masonry Grid does something clever:

Use CSS Grid as the base - let the browser handle column layout naturally
Define aspect ratios with CSS variables - each item knows its own proportions
Use percentage-based transforms - pull items up to fill gaps without pixel calculations
Watch for changes with ResizeObserver and MutationObserver - only recalculate when necessary

import { BalancedMasonryGrid, Frame } from '@masonry-grid/react'

<BalancedMasonryGrid className="masonry">
  <Frame width={3} height={2}>
    <img src="photo1.jpg" />
  </Frame>
  <Frame width={1} height={1}>
    <img src="photo2.jpg" />
  </Frame>
  <Frame width={3} height={2}>
    <img src="photo3.jpg" />
  </Frame>
  {/* More photos... */}
</BalancedMasonryGrid>

That's it. No absolute positioning. Just tell each item its aspect ratio, and the library handles the rest.

The Secret Sauce

Under the hood, this library leverages CSS variables and transforms in a clever way.

<div class="masonry" style="height: 589.651px;">
  <div style="--width: 3; --height: 2;"><!-- Your image --></div>
  <div style="--width: 1; --height: 1;"><!-- Your image --></div>
  <div style="--width: 3; --height: 2;"><!-- Your image --></div>
  <div style="--width: 1; --height: 1; transform: translateY(-33.3333%);"><!-- Your image --></div>
  <div style="--width: 3; --height: 2;"><!-- Your image --></div>
  <div style="--width: 2; --height: 3; transform: translateY(-22.2222%);"><!-- Your image --></div>
  <!-- ending div is added for internal calculations: -->
  <div></div>
</div>

See that transform: translateY(-33.3333%)? That's pulling the item up by a percentage of its own height. Because we know the aspect ratio from CSS variables, we can calculate everything in percentages.

This means when you resize the window, the layout stays perfect without recalculating - the browser handles it natively! Recalculation only happens when the number of columns changes, not on every resize event.

And here's the bonus: since we're building on top of CSS Grid, you get all the flexibility that comes with it. Want fluid columns that adapt to available space? Just use repeat(auto-fit, minmax(200px, 1fr)) or similar techniques. The masonry algorithm works perfectly with whatever column setup Grid gives you - whether it's fixed widths, percentage-based, or fully responsive with auto-fit. The layout remains fluid and adapts naturally to any screen size.

Two Flavors: Regular and Balanced

The library comes with two layout algorithms:

The regular version - items flow naturally into columns, gaps get filled by pulling items up. Classic masonry.

The balanced algorithm takes it further - it reorders items within each row to minimize wasted space. The clever part? It uses the CSS order property, so the DOM order stays intact, but visually everything is optimized.

Both are included, both are tiny, use whichever fits your needs.

Want to see them in action? Check out the examples.

SSR Compatibility

One major advantage of the CSS-based approach: the library is compatible with SSR!

Since the layout is built purely through CSS (transforms and CSS variables), the DOM tree isn't actively restructured. This means hydration passes without issues - no hydration mismatches.

Of course, the server can't pre-calculate the layout since it doesn't know the screen size. But that's okay - the layout will be calculated on the client side after hydration, and because it's CSS-based, there won't be massive DOM manipulations that break hydration.

Tip: To avoid layout shifts and flickers, use the opacity trick - render with opacity: 0 from the server, then set opacity: 1 with a transition after mount on the client. Looks clean and smooth.

.masonry {
  opacity: 0;
  transition: opacity 0.3s ease-in-out;
}

import { useRef, useEffect } from 'react';
import { BalancedMasonryGrid, Frame } from '@masonry-grid/react'

export function MyMasonry() {
  const containerRef = useRef(null);

  useEffect(() => {
    if (containerRef.current) {
      containerRef.current.style.opacity = '1';
    }
  }, []);

  return (
    <BalancedMasonryGrid className="masonry" ref={containerRef}>
      {/* Your frames here */}
    </BalancedMasonryGrid>
  );
}

Conclusion

Masonry Grid offers a fresh take on the classic masonry layout problem. By leveraging modern CSS techniques and a lightweight JavaScript core, it provides a solution that's fast, flexible, and compatible with today's web development needs.

Give it a try! Check out the Getting Started guide to integrate it into your project, or explore interactive examples to see it in action.

The library is open source and available on GitHub. Contributions, feedback, and bug reports are always welcome!

How to setup Conventional Commits in JavaScript project

Dan Onoshko — Mon, 14 Jul 2025 14:23:19 +0000

Conventional Commits is a specification for adding human and machine readable meaning to commit messages. It provides an easy set of rules for creating an explicit commit history, which makes it easier to write automated tools on top of.

Basic Structure

The commit message should be structured as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Examples:

# Feature addition
feat: add user authentication

# Bug fix
fix: resolve login redirect issue

# Breaking change
feat!: migrate to new API endpoint

# Also breaking change
feat: add new payment method

BREAKING CHANGE: migrate to new payment gateway

# With scope
feat(auth): add password reset functionality

# With body and footer
fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Closes #123

Common Types

feat: A new feature
fix: A bug fix
docs: Documentation changes
style: Code style changes (formatting, missing semicolons, etc.)
refactor: Code refactoring without changing functionality
test: Adding or updating tests
chore: Maintenance tasks, dependency updates

Benefits of Conventional Commits

1. Automatic Version Determination

Conventional commits enable automatic semantic versioning:

feat: triggers a minor version bump (1.0.0 → 1.1.0)
fix: triggers a patch version bump (1.0.0 → 1.0.1)
BREAKING CHANGE: triggers a major version bump (1.0.0 → 2.0.0)

2. Automatic Changelog Generation

Tools can automatically generate changelogs by parsing commit messages, grouping them by type, and extracting relevant information.

3. Better Project History

Conventional commits create a more readable and searchable project history, making it easier to understand what changes were made and why.

Setting Up Full Automation

To achieve complete automation of versioning and releases, you'll need several tools working together. Let's set them up step by step.

1. Commitlint

While not mandatory, Commitlint helps enforce conventional commit standards by linting commit messages.

First, install Commitlint and the Conventional Commits plugin:

npm install --save-dev @commitlint/cli @commitlint/config-conventional

Then you need to set up a configuration.

Simple Project Configuration

For a basic project, create .commitlintrc.json:

{
  "extends": ["@commitlint/config-conventional"]
}

Git Hook

Now you can set up commit validation during git commit, for example using simple-git-hooks, though there are other similar tools available (husky, pre-commit, etc.).

Install simple-git-hooks:

npm install --save-dev simple-git-hooks

Create .simple-git-hooks.json:

{
  "commit-msg": "npx commitlint --edit \"$1\""
}

Now run npx simple-git-hooks to activate the hooks and you're ready to go!

GitHub Action

You can also set up commit linting via GitHub Actions when commits are pushed to the repository.

Create .github/workflows/commit.yml:

name: Commit Validation

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  commitlint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Validate commit messages
        run: npx commitlint --from=HEAD~1

Monorepo Project Configuration

In monorepos, it's common practice to use scopes in Conventional Commits that correspond to workspace names in the monorepo. This helps identify which workspace(s) are affected by each commit. For example:

feat(store): add user authentication state
fix(ui): resolve button styling issue
docs(router): update routing configuration guide

You can use specialized packages to automatically get project scopes:

@commitlint/config-workspace-scopes - for generic workspaces
@commitlint/config-pnpm-scopes - for pnpm workspaces
@commitlint/config-lerna-scopes - for Lerna projects

Let's look at an example for pnpm workspaces:

Install the packages:

pnpm add -D @commitlint/cli @commitlint/config-conventional @commitlint/config-pnpm-scopes

Create .commitlintrc.js:

import scopes from '@commitlint/config-pnpm-scopes'

export default {
  extends: ['@commitlint/config-conventional', '@commitlint/config-pnpm-scopes'],
  rules: {
    'scope-enum': async (ctx) => {
      const scopeEnum = await scopes.rules['scope-enum'](ctx)
      return [
        scopeEnum[0],
        scopeEnum[1],
        [
          ...scopeEnum[2],
          'deps',     // for Dependabot or Renovate - dependency updates
          'dev-deps', // for Dependabot or Renovate - dev dependency updates
          'release'   // for release commits
        ]
      ]
    }
  },
  prompt: {
    settings: {
      enableMultipleScopes: true
    }
  }
}

2. Commitizen

Commitizen is an optional but very convenient tool that provides an interactive CLI for creating Conventional Commits.

First, install Commitizen and the Commitlint adapter:

npm install --save-dev commitizen @commitlint/cz-commitlint

Then create .czrc:

{
  "path": "@commitlint/cz-commitlint"
}

Add a script to package.json:

{
  "scripts": {
    "commit": "cz"
  }
}

Now you can use npm run commit instead of git commit for interactive commit creation.

3. Simple Release Action

The simple-release-action is a comprehensive GitHub Action that automates version updates, changelog generation, and releases. The project is based on simple-release and conventional-changelog.

If you are not using GitHub, you can write your own custom CI script using the @simple-release/core package.

Key Features:

First-class monorepo support - A major differentiator from alternatives
Automatic version bumping based on Conventional Commits
Changelog generation with proper categorization
Git tagging and GitHub releases
Configuration through adapters for different project types

Currently npm and pnpm projects with workspaces are supported (npm adapter, pnpm adapter).

Let's look at an example of configuring the action for a project with pnpm workspaces using @simple-release/pnpm addon:

Create .simple-release.json config file in repository root:

{
  "project": ["@simple-release/pnpm#PnpmWorkspacesProject", {
    "mode": "fixed"
  }],
  "bump": {
    "extraScopes": ["deps"]
  }
}

extraScopes is used to trigger version bump by commits like fix(deps): ... from Dependabot or Renovate.

Create .github/workflows/release.yml:

name: Release

on:
  issue_comment:
    types: [created, deleted]
  push:
    branches:
      - main

jobs:
  check:
    runs-on: ubuntu-latest
    name: Context check
    outputs:
      continue: ${{ steps.check.outputs.continue }}
      workflow: ${{ steps.check.outputs.workflow }}
    steps:
      - name: Checkout the repository
        uses: actions/checkout@v4
      - name: Context check
        id: check
        uses: TrigenSoftware/simple-release-action@v1
        with:
          workflow: check
          github-token: ${{ secrets.GITHUB_TOKEN }}

  pull-request:
    runs-on: ubuntu-latest
    name: Pull request
    needs: check
    if: needs.check.outputs.workflow == 'pull-request'
    steps:
      - name: Checkout the repository
        uses: actions/checkout@v4
      - name: Create or update pull request
        uses: TrigenSoftware/simple-release-action@v1
        with:
          workflow: pull-request
          github-token: ${{ secrets.GITHUB_TOKEN }}

  release:
    runs-on: ubuntu-latest
    name: Release
    needs: check
    if: needs.check.outputs.workflow == 'release'
    steps:
      - name: Checkout the repository
        uses: actions/checkout@v4
      - name: Install pnpm
        uses: pnpm/action-setup@v2
        with:
          version: 10
      - name: Install Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 18
          cache: 'pnpm'
          registry-url: 'https://registry.npmjs.org'
      - name: Install dependencies
        run: pnpm install
      - name: Release
        uses: TrigenSoftware/simple-release-action@v1
        with:
          workflow: release
          github-token: ${{ secrets.GITHUB_TOKEN }}
          npm-token: ${{ secrets.NPM_TOKEN }}

This workflow consists of three jobs:

check - performs context check to determine if release changes are needed and which workflow to run
pull-request - creates or updates a pull request with release changes
release - performs the actual release when the PR is merged

Every time you push to the main branch, the action will create or update a pull request with a version bump and updated changelog if necessary.

When the pull request is merged, it will automatically release the project.

Conclusion

There is also a recommendation to use squash merge for pull requests to keep the commit history in the main branch clean and well-structured. This ensures that each merge commit follows conventional commit standards and makes the project history more readable.

By implementing Conventional Commits with this toolchain, you'll have a fully automated release pipeline that maintains consistency, improves project history readability, and reduces manual overhead in version management.

If you want to see real projects using Conventional Commits and their configurations, here are a few examples:

How to build tree-shakeable JavaScript libraries

Dan Onoshko — Wed, 14 Sep 2022 17:09:02 +0000

If you’re a web developer, I’m sure that you’ve heard about tree-shaking. It’s often understood as the removal of unused code from JavaScript bundles. However, do you know that not all code that looks unused is tree-shakeable?

In this blog post, we’ll learn more about tree-shaking and tree-shakable design. You’ll know to write JavaScript code in a tree-shakeable way and produce smaller bundles. If you’re building a JavaScript library, is a must.

This is a part of the series of posts on best practices where I’m sharing bits of my experience contributing to open source. It’s both my hobby and job at Cube where we create and maintain open source tools for building data applications.

What is tree-shaking?

Wait! If tree-shaking is the removal of unused code from bundles, then how is it different from “dead code elimination” that has been a feature of JavaScript minifiers for quite a while? It’s a fair question, and the answer is that tree-shaking is a later term that is only relevant if JavaScript bundlers and ES6 imports/exports are used.

Bundlers analyze ES6 imports/exports at build time to find unused code. Since ES6 imports/exports are a part of JavaScript syntax, it’s quite easy to perform a static analysis of used and unused exports.

On the other hand, CommonJS exports are resolved at run time and can be dynamic. That’s why static analysis of used and unused exports is impossible for CommonJS modules.

Let’s compare how Webpack bundles CommonJS and ES6 modules. In this example, we export two functions (sum and div) from a CommonJS module but only one of them (sum) is imported and used. (Note that here the code in bundle.js is shown before minification.)

// CommonJS
// module.js

exports.sum = function sum(a, b) {
  return a + b;
};

exports.div = function div(a, b) {
  return a / b;
};

// index.js

const { sum } = require('./module');

console.log(sum);

// bundle.js

(() => {
  var __webpack_modules__ = ({
    739:
      ((__unused_webpack_module, exports) => {
        exports.sum = function sum(a, b) {
          return a + b;
        };

        exports.div = function div(a, b) {
          return a / b;
        };
      })
  });

  function __webpack_require__(moduleId) {
    /* ... */
  }

  (() => {
    const { sum } = __webpack_require__(739);

    console.log(sum);
  })();
})();

You can see that Webpack added the __webpack_require__ function to the bundle to support CommonJS module loading. Also, the div function is present in the bundle and won’t be removed after minification because it’s assigned to an object property (exports.div) and will be considered “used”. Compare to an ES6 module:

// ESM
// module.js

export function sum(a, b) {
  return a + b;
}

export function div(a, b) {
  return a / b;
}

// index.js

import { sum } from './module.js';

console.log(sum);

// bundle.js

(() => {
  "use strict";

  function sum(a, b) {
    return a + b;
  }

  function div(a, b) {
    return a / b;
  }

  console.log(sum)
})();

You can see that the div function was copied “as is” and is not used in any way. When you run Webpack in production mode, it will remove this function. (Internally, Webpack relies on Terser for minification; Rollup performs tree-shaking and dead code elimination on its own.)

What is tree-shakable code?

In the example above, two functions were exported from the module and only the “used” one made it to the bundle. What if not only functions are exported? (Note that here the code in bundle.js is shown after minification.)

// module.js

export const foo = 'bar'.toUpperCase();

export const PI_2 = Math.PI * 2;

export function sum(a, b) {
  return a + b;
}

// index.js

import { sum } from './module.js'

console.log(sum);

// bundle.js

(() => {
  "use strict";
  "bar".toUpperCase(), Math.PI;
  console.log((function(a, b) {
    return a + b;
  }));
})();

You might be surprised that all exported entities are present in the bundle, although only the sum function was imported. Let’s explore why.

Pure code

Removing unused functions is quite straightforward. If a function is never called, its declaration should be considered “dead code” and removed from the bundle. It works because function declarations have no side effects: they don’t update global variables, don’t work with DOM, etc. (Please don’t confuse function declarations with function calls; the latter may have side effects.)

Consider the first exported entity: 'bar'.toUpperCase(). This is a function call and it may have side effects. Well, we know that toUpperCase is a pure function, meaning calling it has no side effects. However, minifiers know nothing about the standard library. That’s why the function call wasn't removed from the bundle so the code doesn’t break.

Now consider the second exported entity: Math.PI * 2. This is an arithmetic operation (a constant is multiplied by two) and should not have any side effects. Now take a closer look: what does Math.PI do? It denotes access to a property of an object and it may have side effects. Access to a variable is always pure, but access to a property may invoke a getter method that can do anything. Minifiers don’t know how pure that code is so they leave it intact. (Obviously, this logic applied to setters as well.)

How to make pure code tree-shakable?

If you know that some code is pure, there’s a way to tell minifiers about that. By convention, placing the /* #__PURE__ */ comment before a function call or a constructor call (new) marks them as pure. If you need to mark access to a property as pure, you can wrap it with a pure function:

// module.js

export const foo = /* #__PURE__ */ 'bar'.toUpperCase();

function getPi2() {
  return Math.PI * 2;
}

export const PI_2 = /* #__PURE__ */ getPi2();

export function sum(a, b) {
  return a + b;
}

// index.js

import { sum } from './module.js'

console.log(sum);

// bundle.js

(() => {
  "use strict";
  console.log((function(a, b) {
    return a + b;
  }));
})();

Now it looks better, right?

Here are a few real-world examples of code purification from my contributions to open source:

In Chart.js, tree-shaking didn’t work as expected because of assignments to class properties (replaced with static properties).
In react-chartjs-2, some exported entities are constructed by calling a factory method (marked as pure).

You can experiment with dead code detection yourself in Terser REPL.

`sideEffects: false`

If you’re building a library, you should know about the sideEffects property in the package.json file. It's similar to /* #__PURE__ */ but on a module level instead of a statement level. By setting it to false, you can mark the entire code of your library as pure:

{
  "sideEffects": false
}

You can also set it to an array of files that contain side effects:

{
  "sideEffects": ["./dist/polyfill.js"]
}

You can learn more about the sideEffects property in the Webpack documentation. Please pay attention to this behavior: a package, marked as pure with sideEffects: false, will be skipped entirely if imported as a whole.

// module.js

export const foo = 'bar'.toUpperCase();

export const PI_2 = Math.PI * 2;

export function sum(a, b) {
  return a + b;
}

// index.js

import './module.js'

console.log('noop');

// bundle.js

(() => {
  "use strict";
  console.log('noop');
})();

However, if individual entities are imported, everything works as described in the previous section and you still need to use /* #__PURE__ */:

// module.js

export const foo = 'bar'.toUpperCase();

export const PI_2 = Math.PI * 2;

export function sum(a, b) {
  return a + b;
}

// index.js

import { sum } from './module.js'

console.log(sum);

// bundle.js

(() => {
  "use strict";
  "bar".toUpperCase(), Math.PI;
  console.log((function(a, b) {
    return a + b;
  }));
})();

Things to consider when using sideEffects: false:

If your library code is already covered with /* #__PURE__ */, using sideEffects: false will have no effect.
If your library provides global style sheets (not CSS modules), they should also be added to the array of files that contain side effects:

{
  "sideEffects": ["./dist/index.css"]
}

It’s required because such style sheets are usually imported directly:

import 'mylib/dist/index.css'

Beware when developing a library: bundlers will look for sideEffects: false not only in the dependencies of your library but in its package.json as well.

Tree-shakable design

Now we know how tree-shaking works in principle. However, we should also design a library in a tree-shakeable way. For instance, if the entire library is packed in a single class, tree-shaking wouldn’t be able to remove any code.

Here are the rules of tree-shakable design:

All entities, including class methods, that might not be used should be exported separately (so they can potentially be removed from the bundle).
Classes and objects should be exported cautiously (because their contents can’t be removed from the bundle).
All code should be free of side effects by default. Minimal, if any, instances of non-pure code should be permitted.

Consider the following examples.

Example A

Imagine we’re writing an internationalization library:

// non-tree-shakable

import I18n from 'my-i18n-lib';

const i18n = new I18n(config);

console.log(i18n.__('foo'));
// console.log(i18n.__n('bar', 5));

// tree-shakable

import { I18n, translate, translatePlural } from 'my-i18n-lib';

const i18n = new I18n(config);
const __ = i18n.bind(translate);

console.log(__('foo'));

🙅 In the non-tree-shakable variant, a single giant class is exported. The bundle will include all class methods, including unused ones.

🙆 In the tree-shakable variant, potentially unused class methods are exported separately as functions. The bundle will include only used functions.

Example B

Imagine we’re writing a data visualization library:

// non-tree-shakable

import { BarChart } from 'my-charting-lib';

new BarChart('#chart', data, {
  axisX: {
    type: 'auto'
  },
  axisY: {
    type: 'fixed' // 'step'
  }
});

// tree-shakable

import {
  BarChart,
  AutoScaleAxis,
  FixedScaleAxis,
  StepAxis
} from 'my-charting-lib';

new BarChart('#chart', data, {
  axisX: {
    type: AutoScaleAxis
  },
  axisY: {
    type: FixedScaleAxis
  }
});

🙅 In the non-tree-shakable variant, all axis types should be imported inside BarChart so it can use some of them according to the options provided. The bundle will include all classes for all axis types.

🙆 In the tree-shakable variant, only necessary axis types are imported and provided to BarChart. The bundle will include classes only for used axis types.

(Full disclosure: this is a real-world design decision from Chartist, an open-source data visualization library I maintain and contribute to.)

Example C

Imagine we’re writing a more complex data visualization library like Chart.js. In that case, you may choose to implement dependency injection:

import {
  Chart,
  CategoryScale,
  LinearScale,
  PointElement,
  LineElement,
  Title,
  Legend
} from 'chart.js';

Chart.register(
  CategoryScale,
  LinearScale,
  PointElement,
  LineElement,
  Title,
  Legend
);

new Chart(ctx, {
  type: 'line',
  data: data,
  options: {
    plugins: {
      legend: {
        position: 'top',
      },
      title: {
        display: true,
        text: 'Chart.js Line Chart',
      },
    }
  }
});

🙆 In this tree-shakable implementation, dependency injection via Chart.register is used. Library code is very well split into individual parts that are exported separately. The bundle will include classes only for used entities.

Keeping code tree-shakable

A one-time effort to write or rewrite a JavaScript library in a tree-shakable way is not enough. One day, due to lousy code or code review, tree-shaking might brake.

However, you can use the Size Limit library to control the size of a bundle or individual exports. Here’s an example configuration:

// .size-limit.json

[
  {
    "path": "dist/chart.esm.js",
    "limit": "19 KB",
    "import": "{ BarController, BubbleController, DoughnutController, LineController, PolarAreaController, PieController, RadarController, ScatterController }"
  },
  {
    "path": "dist/chart.esm.js",
    "limit": "14 KB",
    "import": "{ ArcElement, LineElement, PointElement, BarElement }"
  },
  {
    "path": "dist/chart.esm.js",
    "limit": "27 KB",
    "import": "{ Decimation, Filler, Legend, SubTitle, Title, Tooltip }"
  },
  {
    "path": "dist/chart.esm.js",
    "limit": "22 KB",
    "import": "{ CategoryScale, LinearScale, LogarithmicScale, RadialLinearScale, TimeScale, TimeSeriesScale }"
  }
]

Size Limit integrates with CI such as GitHub Actions and will alert you if any pull request drastically increases the bundle size, possibly due to broken tree-shaking.

What’s next?

Please use tree-shaking in your code at all times. If you’d like to learn how tree-shaking works by example, check out this sandbox I’ve built.

If you have an existing application or library:

make sure it complies with the three rules of tree-shakable design;
make sure pure functions are marked as such with /* #__PURE__ */;
make sure Size Limit is used to notify if tree-shaking brakes.

Good luck!

Почему и как нужно транспилировать зависимости

Dan Onoshko — Tue, 22 Feb 2022 08:05:27 +0000

Если вы разработчик сайта, то наверняка пользуетесь каким-либо сборщиком (например, Webpack, Rollup или Parcel), который к тому же транспилирует ваш JavaScript-код с помощью Babel. Ну и, конечно же, вы наверняка используете разнообразные зависимости, чтобы сократить время разработки.

Обычно транспилировать код зависимостей не принято, ведь вроде как и без этого все прекрасно работает. Но времена меняются…

(В этой статье я делюсь своим опытом работы над open source проектами. Это и мое хобби, и работа в Cube, где мы создаем open source инструменты для создания приложений для работы с данными.)

Распространение ESM

До появления нативной поддержки ES-модулей в браузерах и в Node.js, npm-пакет мог содержать несколько вариантов кода:

CommonJS-вариант без использования новых фишек JavaScript, таких как стрелочные функции. Такой код совместим с большинством версий Node.js и браузеров. Файл этого варианта указывают в поле main в package.json.
module-вариант, использующий ES6-импорты и экспорты, но так же без использования новых фишек. Модули позволяют делать tree-shaking, то есть не включать в бандл неиспользуемый код. Файл этого варианта указывают в поле module в package.json.

Конечно, не все npm-пакеты сделаны по такому принципу — все зависит от разработчика. Однако браузерные и универсальные библиотеки часто распространяются именно так.

Сейчас ES-модули нативно поддерживаются браузерами уже больше трёх лет, а в Node.js их поддержка появилась в версии 12.20, выпущенной в ноябре 2020 года. Разработчики библиотек стали включать в npm-пакеты еще один вариант кода — для сред, нативно поддерживающих ES-модули, или вовсе перешли на поддержку только ES-модулей.

Особенности ESM

Важно понимать, что нативные ES-модули — это не то же самое, что модули, использующие ES6-синтаксис импорта и экспорта:

То, как мы привыкли использовать import / export, не будет нигде работать нативно — такой код предназначен для дальнейшей обработки бандлером или транспайлером.
Нативные ESM не умеют резолвить расширения и index-файлы, поэтому их нужно явно указывать в пути:
```
// Неправильно:
import _ from './utils'

// Правильно:
import _ from './utils/index.js'
```
Если пакет содержит ESM-код, то в package.json нужно явно указать тип пакета с помощью "type": "module".
Для указания файла с ESM в package.json нужно использовать поле exports.

Более подробно про особенности ESM можно прочитать в этой статье.

Поддержка JavaScript

Еще одна особенность ESM это то, что мы точно знаем, с каких версий браузеры и Node.js поддерживают ES-модули. Соответственно, мы точно знаем, какие фишки JavaScript мы можем использовать в коде.

Например, все браузеры с нативной поддержкой ES-модулей имеют поддержку стрелочных функций, а значит нам больше не нужно избегать их использования или настраивать Babel для их транспиляции в обычные функции. Разработчики библиотек пользуются этой особенностью и используют в ESM-коде все новые фишки JavaScript.

Транспиляция зависимостей

Но что делать, если ваш сайт должен работать в более старых браузерах? Или если какая-нибудь из зависимостей использует новые фишки JavaScript, не поддерживаемые актуальными браузерами?

Правильно! В обоих случаях нужно делать транспиляцию зависимостей.

Транспилируем вручную

Разберем на примере конфигурации webpack в паре с babel-loader. Типичный пример выглядит примерно так:

module: {
  rules: [
    {
      test: /\.jsx?$/,
      exclude: /node_modules/,
      use: {
        loader: 'babel-loader',
        options: {
          presets: [
            ['@babel/preset-env', { targets: 'defaults' }]
          ]
        }
      }
    }
  ]
}

В документации и примерах использования Babel и babel-loader рекомендуют исключать node_modules из файлов для транспиляции (exclude: /node_modules/), чтобы сборка выполнялась быстрее. Удалив эту строчку, мы включим транспиляцию зависимостей, но пожертвуем скоростью сборки. Есть компромиссный вариант: если мы знаем, какие именно зависимости нужно транспилировать, то можем указать только их:

exclude: _ => /node_modules/.test(_) && !/node_modules\/(nanostores|p-limit)/.test(_)

Или можем выбрать только файлы с определённым расширением:

exclude: _ => /node_modules/.test(_) && !/(\.babel\.js|\.mjs|\.es)$/.test(_)

Как будет различаться размер бандла и время сборки с разными настройками? Рассмотрим на примере бандла с тремя очень разными зависимостями:

p-limit (использует самые последние фишки JavaScript, включая приватные поля класса, которые поддерживаются не везде)
axios (ES5-код)
и svelte (использует актуальные фишки JavaScript, такие как стрелочные функции)

Конфигурация	Транспиляция	Совместимость	Размер бандла	Время сборки
Базовая	Не выполняется	Невозможно предсказать, с какими браузерами совместим бандл	21 КБ	1,8 с
target: defaults and supports es6-module	До ES6. Приватные поля классов будут даунгрейднуты, стрелочные функции и классы останутся	Новые браузеры	22 КБ	2,6 с
target: defaults с полифилами	До ES5	Все браузеры	123 КБ	6,1 с

Общее время сборки двух бандлов с помощью babel-loader составило 8,7 с. (Надеюсь, понятно, что в нашем примере, без транспиляции, получившийся бандл не будет совместим со старыми браузерами из-за p-limit.)

(Кстати, про сборку нескольких бандлов под разные браузеры подробно написано в другой моей статье.)

Но что делать, если вам не хочется вручную указывать нужные файлы и пакеты в конфигурации? Есть готовый и очень удобный инструмент!

Транспилируем с помощью optimize-plugin

optimize-plugin для webpack от Джейсона Миллера из Google (@_developit) сделает за вас всё, что нужно, и даже чуть больше:

оптимизирует ваш код и код всех зависимостей
если нужно, сгенерирует два бандла (для новых и старых браузеров), используя подход module/nomodule
а ещё может сделать апгрейд ES5-кода до ES6, используя babel-preset-modernize!

Вот какие результаты будут у optimize-plugin для нашего бандла с тремя зависимостям:

Конфигурация	Транспиляция	Совместимость	Размер бандла	Время сборки
Базовая	Одновременно до ES6 и до ES5 с полифилами	Все браузеры	20 КБ для новых браузеров 92 КБ для старых браузеров (из них 67 КБ — полифилы)	7,6 с

Общее время сборки двух бандлов с помощью optimize-plugin составило 7,6 с. Как видно, optimize-plugin не только быстрее babel-loader, но и создаёт бандл меньшего размера. Можете проверить сами.

Почему optimize-plugin выигрывает

Выигрыш в скорости получается за счёт того, что код анализируется и собирается не два раза, а один, после чего optimize-plugin транспилирует получившийся бандл под новые и старые браузеры.

Получить выигрыш в размере позволяет babel-preset-modernize. Если в своём коде вы, скорее всего, используете все фишки ES6+, то в зависимостях может быть всё что угодно. Поскольку optimize-plugin работает с уже собранным бандлом, который содержит код всех зависимостей, их код тоже будет транспилирован.

Вот пример работы babel-preset-modernize. Предположим, мы написали такой код:

const items = [{
  id: 0,
  price: 400
}, {
  id: 1,
  price: 300
}, {
  id: 2,
  price: 550
}];
const sum = items.reduce(function (sum, item) {
  const price = item.price;
  return sum + price;
}, 0);

console.log(sum);

После транспиляции получим:

const items = [{
  id: 0,
  price: 400
}, {
  id: 1,
  price: 300
}, {
  id: 2,
  price: 550
}];
const sum = items.reduce((sum, {
  price
}) => sum + price, 0);

console.log(sum);

Что поменялось:

обычная анонимная функция заменена на стрелочную функцию
доступ к свойству item.price заменён деструктуризацией аргумента функции

Размер кода уменьшился с 221 байта до 180 байт. При этом здесь выполняется всего два типа трансформаций, но babel-preset-modernize умеет делать больше.

Что дальше?

Плагин демонстрирует очень крутые результаты, но ему ещё есть, куда расти. Недавно я сделал несколько улучшений, в том числе добавил поддержку webpack 5.

Если вас заинтересовал optimize-plugin, то призываю попробовать его для сборки своих приложений, а также внести свой вклад в его развитие.

В любом случае, транспилируйте зависимости своего кода, чтобы контролировать его совместимость со старыми и новыми браузерами.

Кроме того, если вы создаете приложение для работы с данными, обратите внимание на Cube. Он поможет вам создать API для метрик, которые вы сможете использовать в своем приложении за считанные минуты.

Why and how to transpile dependencies of your JavaScript application

Dan Onoshko — Thu, 17 Feb 2022 19:33:41 +0000

If you’re a web developer, I’m sure that you use bundlers (e.g., Webpack, Rollup, or Parcel) which transpile the JavaScript code of your application with Babel under the hood. No doubt that you also use various dependencies to cut off the development time.

However, I rarely see developers transpiling the code of their dependencies because everything seems to work fine without it, right? Wrong! Here’s why...

(In this blog post, I’m sharing bits of my experience contributing to open source. It’s both my hobby and job at Cube where we create open source tools for building data applications.)

Adoption of ESM

Before browsers and Node.js got native support for ES modules, an npm package could contain several variants of source code:

CommonJS variant that doesn’t use modern features of JavaScript such as arrow functions. It’s compatible with most versions of Node.js and browsers. The source code location is specified in the main field of package.json.
module variant that has ES6 imports/exports but still doesn’t use modern features of JavaScript. Modules allow for tree-shaking, i.e., excluding unused code from a bundle. The source code location is specified in the module field of package.json (see this discussion for details).

Obviously, not every npm package follows this convention. It’s a choice that every author of a library makes on their own. However, it’s quite common for browser-side and universal libraries to be distributed in two variants.

Web browsers have natively supported ES modules for more than three years already, and Node.js supports them since version 12.20 (released in November 2020). That’s why authors of libraries now include one more variant of source code for execution environments that natively support ES modules, and many packages have completely removed the support for CommonJS.

Perks and features of ESM

It’s important to understand that native ES modules are very much different than modules that have ES6 imports/exports. Here are a few reasons:

The way we are used to using imports/exports will not work natively. Such code is intended for further processing by a bundler or a transpiler.
Native ES modules don’t support index file name and extension resolution, so you have to specify them explicitly in the import path:
```
// Won't work:
import _ from './utils'

// Works:
import _ from './utils/index.js'
```
If an npm package has ES modules, you have to add "type": "module" to package.json and specify the source code location in the exports field (see docs for details).

You can check this blog post by Axel Rauschmayer to learn more about ES modules.

Support for JavaScript features

Look! Since we know which versions of web browsers and Node.js support ES modules, we also know for sure which features of JavaScript we can use in the source code.

For instance, all web browsers that support ES modules natively also support arrow functions, so we don’t need to avoid using them or use Babel to transpile them to regular functions. Authors of libraries know that and ship the source code that leverages all modern features of JavaScript.

Transpilation of dependencies’ code

But wait! What can you do to make sure that your web application works in legacy browsers? Also, what to do if any of your application’s dependencies use modern features of JavaScript that aren’t supported by popular browsers?

In both cases, you need to transpile the code of the dependencies.

Manual transpilation

Let’s assume that we’re using webpack and babel-loader. Often, the config would look like this:

module: {
  rules: [
    {
      test: /\.jsx?$/,
      exclude: /node_modules/,
      use: {
        loader: 'babel-loader',
        options: {
          presets: [
            ['@babel/preset-env', { targets: 'defaults' }]
          ]
        }
      }
    }
  ]
}

It’s suggested in the documentation and usage examples for Babel and babel-loader to exclude node_modules from transpilation (exclude: /node_modules/) to optimize the performance.

By removing the exclude rule, we’ll enable the transpilation of dependencies’ code in exchange for the increased bundling time. By providing a custom function as the exclude rule, we also can transpile just a subset of all dependencies:

exclude: _ => /node_modules/.test(_) && !/node_modules\/(nanostores|p-limit)/.test(_)

We can also select files by their filename extensions:

exclude: _ => /node_modules/.test(_) && !/(\.babel\.js|\.mjs|\.es)$/.test(_)

Manual transpilation — the benchmark

Let’s check how babel-loader configuration affects the bundle size and bundling time. Consider an application with three very different dependencies:

svelte (uses modern features of JavaScript such as arrow functions)
p-limit (uses bleeding-edge features of JavaScript such as private class fields)
axios (regular ES5 code)

Config	Transpilation	Compatibility	Bundle size	Bundling time
Basic	—	No way to predict which web browsers will work with this bundle	21 KB	1.8 s
`target: defaults and supports es6-module`	To ES6 code. Private class fields will be downgraded, arrow functions and classes will remain as is	Modern browsers	22 KB	2.6 s
`target: defaults` with polyfills	To ES5 code	All browsers	123 KB	6.1 s

You can see that the total bundling time for modern browsers and all browsers with babel-loader is 8.7 s. Please also note that the basic, non-transpiled bundle won’t work with legacy browsers because of p-limit.

(By the way, I also have a blog post that explains in detail how to build several bundles for different browsers.)

Okay, but what if you don’t want to tinker with configs and specify files and packages to be transpiled manually? Actually, there’s a readily available tool for that!

Transpilation with optimize-plugin

Meet optimize-plugin for webpack by Jason Miller from Google (@_developit). It will take care of everything and even more:

It will transpile your application’s source code and the code of all dependencies.
If needed, it will generate two bundles (for modern and legacy browsers) using the module/nomodule pattern.
On top of that, it can also upgrade ES5 code to ES6 using babel-preset-modernize!

Let’s see what optimize-plugin will do to our example application with three dependencies:

Config	Transpilation	Compatibility	Bundle size	Bundling time
Basic	To ES6 code. Also, to ES5 code with polyfills	All browsers	20 KB for modern browsers. 92 KB for legacy browsers (including 67 KB of polyfills)	7.6 s

The total bundling time with optimize-plugin is 7.6 s. As you can see, optimize-plugin is not only faster than babel-loader, but it also produces a smaller bundle. You can check my results using the code from my optimize-plugin-demo repository.

Why optimize-plugin wins

The performance boost is possible because the code is analyzed and bundled only once. After that, optimize-plugin transpiles it for modern and legacy browsers.

Smaller bundle size is possible thanks to babel-preset-modernize. Chances are that you use ES6+ features in your application’s code but you never can predict which features are used in the source code of the dependencies. Since optimize-plugin works with the bundle that already has the code of all dependencies, it can transpile it as a whole.

Here’s how babel-preset-modernize works. Consider this code snippet:

const items = [{
  id: 0,
  price: 400
}, {
  id: 1,
  price: 300
}, {
  id: 2,
  price: 550
}];
const sum = items.reduce(function (sum, item) {
  const price = item.price;
  return sum + price;
}, 0);

console.log(sum);

After transpilation to ES6, we’ll get this code:

const items = [{
  id: 0,
  price: 400
}, {
  id: 1,
  price: 300
}, {
  id: 2,
  price: 550
}];
const sum = items.reduce((sum, {
  price
}) => sum + price, 0);

console.log(sum);

Here’s what has changed:

A regular anonymous function was upgraded to an arrow function.
item.price field access was replaced with the function argument destructuring.

Code size shrinked from 221 to 180 bytes. Note that we applied only two transformations here but babel-preset-modernize can do a lot more.

What’s next?

optimize-plugin works really great but it still has some room for improvement. Recently, I’ve contributed a few pull requests, including the support for webpack 5.

If optimize-plugin looks promising to you, I encourage you to give it a try in your projects and maybe contribute some improvements as well.

Anyway, starting today, please always transpile the code of the dependencies, whether with optimize-plugin or not, to make sure that you have full control over your application’s compatibility with modern and legacy browsers. Good luck!

Also, if you are building a data application, check out Cube. It can help you build an API for metrics that you can use in your application within minutes.

Speed up with Browserslist

Dan Onoshko — Thu, 07 May 2020 20:10:04 +0000

Today we have a large number of different browsers and even more versions of each. Not a long time ago features were added infrequently, but now you can see them added in almost every release. As a result, different versions of browsers have different features’ support, not to mention a different level of vendor support.

Developers want to use new features, as they often simplify their lives. Using modern development tools, you can use features before they even get an official vendor support by transpiling and using polyfills. Additionally, these tools guarantee that a website will work in all browsers, regardless of a particular feature support. Examples: Autoprefixer and postcss-preset-env for CSS, Babel for JavaScript. But you need to understand that using these tools can increase the bundle’s size.

As a result, we have a website that works in any browser, but it loads slower. Let me remind you that the loading time and fast transitions directly affects UX and popularity. What can be done with it? In fact, we don’t need to transpile and polyfill absolutely every feature — it’s enough to do this only with those that are not supported by current browsers (or relevant to the audience of your website). For example, promises are supported by every browser, excluding the oldest ones.

Browserslist

Browserslist is a convenient tool for describing target browsers just by using simple queries like the following:

last 2 years
> 1%
not dead

This is an example of .browserslistrc file, that requires: browsers over the past two years, plus browsers with more than 1% of users, and all of these browsers must be «live». You can see specific browsers resolution on browserl.ist. Learn more about queries syntax on project page.

Already mentioned Autoprefixer, postcss-preset-env and babel-preset-env under the hood use Browserslist, and if your project has a Browserslist config, project code will be compiled for these browsers.

At this stage, we can come to the following conclusion: the newer browsers we are targeting, the less bundle size we get. At the same time, we should not forget that in the real world not every single user has the newest browser, and the website should be accessible for all users, or at least for the most of them. What can be done under these considerations?

Browser targeting variants

1. Limited targeting

By default, if there is no config in the project, Browserslist will use default browsers. This query is an alias for > 0.5%, last 2 versions, Firefox ESR, not dead. In general, you can stop on this query, and over the time, the browsers matching this query will start to support most of the current features.

But you can target a considerable number of browsers by following these rules: exclude legacy and unpopular ones, consider more or less relevant versions of browsers. Sounds simple, but actually it’s not. You need to carefully balance the Browserslist config to cover most of the audience.

2. Audience analysis

If your website implies only certain regions’ support, then you can try using a query like > 5% in US, which returns suitable browsers based on the usage statistics by specified country.

Browserslist family is full of various additional tools, one of them is Browserslist-GA (there is also browserslist-adobe-analytics), which allows you to export data from analytics service about your users’ browsers statistics. After that, it becomes possible to use this data in Browserslist config and make queries based on it:

> 0.5% in my stats

For example, if you can update this data on every deploy, then your website will always be built for current browsers used by your audience.

3. Differential resource loading

In March 2019 Matthias Binens from Google proposed to add differential script loading (further DSL) to browsers:

<script type="module"
        srcset="2018.mjs 2018, 2019.mjs 2019"
        src="2017.mjs"></script>
<script nomodule src="legacy.js"></script>

Until now, his proposal stays only a proposal, and it is unknown whether this will be implemented by vendors or not. But the concept is understandable, and Browserslist family has tools that you can use to implement something similar, one of them is browserslist-useragent. This tool allows you to check if the browser’s User-Agent fits your config.

Browserslist-useragent

There are already several articles on this topic, here is an example of one — «Smart Bundling: How To Serve Legacy Code Only To Legacy Browsers». We will briefly go over the implementation. First, you need to to configure your build process to output two versions of the bundles for the modern and legacy browsers, for example. Here, Browserslist will help you with it ability to declare several environments in a configuration file:

[modern]
last 2 versions
last 1 year
not safari 12.1

[legacy]
defaults

Next, you need to configure the server to send the right bundle to the user’s browser:

/* … */
import { matchesUA } from 'browserslist-useragent'
/* … */
app.get('/', (request, response) => {
    const userAgent = request.get('User-Agent')
    const isModernBrowser = matchesUA(userAgent, {
        env: 'modern',
        allowHigherVersions: true
    })
    const page = isModernBrowser
        ? renderModernPage(request)
        : renderLegacyPage(request)

    response.send(page)
})

Thus, the website will send a lightweight bundle to users with modern browsers, resulting in a faster loading time, while saving accessibility for other users. But, as you can see, this method requires your own server with special logic.

Module/nomodule

With browsers’ support of ES-modules, there is a way to implement DSL on client side:

<script type="module" src="index.modern.js"></script>
<script nomodule src="index.legacy.js"></script>

This pattern is called module/nomodule, and it’s based on the fact that legacy browsers without ES-modules’ support will not handle scripts with the type module, since this type is unknown to them. So browsers that support ES-modules will load scripts with the type module and ignore scripts with the nomodule attribute. Browsers with ES-modules’ support can be specified by the following config:

[esm]
edge >= 16
firefox >= 60
chrome >= 61
safari >= 11
opera >= 48

The biggest advantage of the module/nomodule pattern is that you don’t need to own a server — everything works completely on client side. Differential stylesheet loading cannot be done this way, but you can implement resource loading using JavaScript:

if ('noModule' in document.createElement('script')) {
    // Modern browsers
} else {
    // Legacy browsers
}

One of the disadvantages: this pattern has some cross-browser problems. Also, browsers supporting ES-modules already have new features with different levels of support, for example, optional chaining operator. With the addition of new features, this DSL variation will lose its relevance.

You can read more about the module/nomodule pattern in the article «Modern Script Loading». If you are interested in this DSL variant and would like to try it in your project, then you can use Webpack plugin: webpack-module-nomodule-plugin.

Browserslist-useragent-regexp

More recently, another tool was created for Browserslist: browserslist-useragent-regexp. This tool allows you to get a regular expression from config to check browser’s User-Agent. Regular expressions work in any JavaScript runtime, which makes it possible to check the browser’s User-Agent not only on server side, but also on client side. Thus, you can implement a working DSL in a browser:

// last 2 firefox versions
var modernBrowsers = /Firefox\/(73|74)\.0\.\d+/
var script = document.createElement('script')

script.src = modernBrowsers.test(navigator.userAgent)
    ? 'index.modern.js'
    : 'index.legacy.js'

document.all[1].appendChild(script)

Another fact is that generated regexpes are faster than matchesUA function from browserslist-useragent, so it makes sense to use browserslist-useragent-regexp on server side too:

> matchesUA('Mozilla/5.0 (Windows NT 10.0; rv:54.0) Gecko/20100101 Firefox/54.0', { browsers: ['Firefox > 53']})
first time: 21.604ms
> matchesUA('Mozilla/5.0 (Windows NT 10.0; rv:54.0) Gecko/20100101 Firefox/54.0', { browsers: ['Firefox > 53']})
warm: 1.742ms

> /Firefox\/(5[4-9]|6[0-6])\.0\.\d+/.test('Mozilla/5.0 (Windows NT 10.0; rv:54.0) Gecko/20100101 Firefox/54.0')
first time: 0.328ms
> /Firefox\/(5[4-9]|6[0-6])\.0\.\d+/.test('Mozilla/5.0 (Windows NT 10.0; rv:54.0) Gecko/20100101 Firefox/54.0')
warm: 0.011ms

All in all, this looks very cool, but there should be an easy way to integrate it into the project’s building process... And in fact there is!

Browserslist Differential Script Loading

Bdsl-webpack-plugin is a Webpack plugin paired with html-webpack-plugin and using browserslist-useragent-regexp, which helps automate DSL addition to the bundle. Here is an example Webpack config for this plugin usage:

const {
    BdslWebpackPlugin,
    getBrowserslistQueries,
    getBrowserslistEnvList
} = require('bdsl-webpack-plugin')

function createWebpackConfig(env) {
    return {
        name: env,
        /* … */
        module: {
            rules: [{
                test: /\.js$/,
                exclude: /node_modules/,
                loader: 'babel-loader',
                options: {
                    cacheDirectory: true,
                    presets: [
                        ['@babel/preset-env', {
                            /* … */
                            targets: getBrowserslistQueries({ env })
                        }]
                    ],
                    plugins: [/* … */]
                }
            }]
        },
        plugins: [
            new HtmlWebpackPlugin(/* … */),
            new BdslWebpackPlugin({ env })
        ]
    };
}

module.exports = getBrowserslistEnvList().map(createWebpackConfig)

This example exports several configs to output bundles for each environment from Browserslist config. As an output, we get HTML file with built-in DSL script:

<!DOCTYPE html>
<html>
    <head>
        <title>Example</title>
        <script>function dsl(a,s,c,l,i){c=dsld.createElement('script');c.async=a[0];c.src=s;l=a.length;for(i=1;i<l;i++)c.setAttribute(a[i][0],a[i][1]);dslf.appendChild(c)}var dsld=document,dslf=dsld.createDocumentFragment(),dslu=navigator.userAgent,dsla=[[]];if(/Firefox\/(73|74)\.0\.\d+/.test(dslu))dsl(dsla[0],"/index.modern.js")
else dsl(dsla[0],"/index.legacy.js");dsld.all[1].appendChild(dslf)</script>
    </head>
    <body></body>
</html>

In addition to scripts loading, there is support for styles loading. It is also possible to use this plugin on server side.

But, unfortunately, there are some nuances that you should know before starting to use bdsl-webpack-plugin: since scripts and styles loading is initialized by JavaScript, they are loaded asynchronously without render being blocked, and etc. For example, in case of the scripts — this means an inability to use defer attribute, and for the styles — the necessity to hide page content until styles are fully loaded. You can investigate how to get around these nuances, and other features of this plugin yourself, see documentation and usage examples.

Dependencies transpilation

Following the aforesaid part of the article, we’ve learned several ways of using Browserslist to reduce the size of the website’s own code, but the other part of the bundle is its dependencies. In web applications, the size of the dependencies in the final bundle can take up a significant part.

By default, the build process should avoid the transpilation of dependencies, otherwise the build will take a lot of time. Also dependencies, utilizing unsupported syntax, are usually distributed already transpiled. In practice, there are three types of packages:

with transpiled code;
with transpiled code and sources;
with code with current syntax only for modern browsers.

With the first type, obviously, nothing can be done. The second — you need to configure the bundler to work only with the sources from the package. The third type — in order to make it work (even with not very relevant browsers) you still have to transpile it.

Since there is no common way to make packages with several versions of the bundle, I will describe how I suggest to approach this problem: the regular transpiled version has .js extension, the main file is written to the main field of package.json file, while, on the contrary, the version of the bundle without transpilation has .babel.js extension, and the main file is written in the raw field. Here is a real example — Canvg package. But you can do it another way, for example, here is how it’s done in Preact package — the sources are located in the separate folder, and package.json has a source field.

To make Webpack work with such packages, you need to modify resolve config section:

{
    /* … */
    resolve: {
        mainFields: [
            'raw',
            'source',
            'browser',
            'module',
            'main'
        ],
        extensions: [
            '.babel.js',
            '.js',
            '.jsx',
            '.json'
        ]
    }
    /* … */
}

This way, we tell Webpack how to lookup files in packages that are used at build time. Then we just need to configure babel-loader:

{
    /* … */
    test: /\.js$/,
    exclude: _ => /node_modules/.test(_) && !/(node_modules\/some-modern-package)|(\.babel\.js$)/.test(_),
    loader: 'babel-loader'
    /* … */
}

The logic is straightforward: we ask to ignore everything from node_modules, except specific packages and files with specific extensions.

Results

I’ve measured DevFest Siberia 2019 a website’s bundle size and loading time before and after applying differential loading together with dependencies transpilation:

	Regular network	Regular 4G	Good 3G
Without DSL
Average loading time	1,511 ms	4,240 ms	8,696 ms
Fastest loading time	1,266 ms	3,366 ms	8,349 ms
Encoded size	292 kB
Decoded size	1.08 MB
bdsl-webpack-plugin, 3 environments (modern, actual, legacy)
Average loading time	1,594 ms	3,409 ms	8,561 ms
Fastest loading time	1,143 ms	3,142 ms	6,673 ms
Encoded size	218 kB
Decoded size	806 kB

The result is a decreased loading time and bundle size reduction by ≈20%, read more detailed report. You can also make measurements by yourself — you can find the required script in the bdsl-webpack-plugin repository.

Sources

Smart Bundling: How To Serve Legacy Code Only To Legacy Browsers, Shubham Kanodia
Modern Script Loading, Jason Miller

DEV Community: Dan Onoshko

Masonry Grid Goes CSS-Only: An Experimental Approach

A CSS Trick from the Comments

Adapting the Span Trick

The Obvious Advantages

The Trade-offs

Conclusion

Masonry Grid: A 1.4 kB Library That Actually Works

How Can You Build Masonry Layout Today?

Option 1: Native CSS Masonry

Option 2: The Classic - Masonry.js

Option 3: Pure CSS Solutions

Option 4: HTML Columns with JavaScript

Enter Masonry Grid

The Key Insight: Let CSS Do the Heavy Lifting

The Secret Sauce

Two Flavors: Regular and Balanced

SSR Compatibility

Conclusion

How to setup Conventional Commits in JavaScript project

Basic Structure

Common Types

Benefits of Conventional Commits

1. Automatic Version Determination

2. Automatic Changelog Generation

3. Better Project History

Setting Up Full Automation

1. Commitlint

Simple Project Configuration

Git Hook

GitHub Action

Monorepo Project Configuration

2. Commitizen

3. Simple Release Action

Conclusion

How to build tree-shakeable JavaScript libraries

What is tree-shaking?

What is tree-shakable code?

Pure code

How to make pure code tree-shakable?

sideEffects: false

Tree-shakable design

Example A

Example B

Example C

Keeping code tree-shakable

What’s next?

Почему и как нужно транспилировать зависимости

Распространение ESM

Особенности ESM

Поддержка JavaScript

Транспиляция зависимостей

Транспилируем вручную

Транспилируем с помощью optimize-plugin

Почему optimize-plugin выигрывает

Что дальше?

Why and how to transpile dependencies of your JavaScript application

Adoption of ESM

Perks and features of ESM

Support for JavaScript features

Transpilation of dependencies’ code

Manual transpilation

Manual transpilation — the benchmark

Transpilation with optimize-plugin

Why optimize-plugin wins

What’s next?

Speed up with Browserslist

Browserslist

Browser targeting variants

1. Limited targeting

2. Audience analysis

3. Differential resource loading

Browserslist-useragent

Module/nomodule

Browserslist-useragent-regexp

Browserslist Differential Script Loading

Dependencies transpilation

Results

Sources

Editor

`sideEffects: false`