modules

ECMAScript Modules in Browsers

As Jake Archibald says, they are starting to land! The support landscape is already:

  • Safari 10.1.
  • Chrome Canary 60 – behind the Experimental Web Platform flag in chrome:flags.
  • Firefox 54 – behind the dom.moduleScripts.enabled setting in about:config.
  • Edge 15 – behind the Experimental JavaScript Features setting in about:flags.

There are plenty of weird gotchas to be aware of, like minor syntax things that are intentionally not supported, and the order of script execution.

We covered Stefan Judis's post, who's sure we'll continue to bundle:

Just because we might have support for ES6 modules in browsers soon, it doesn't mean that we can get rid of a build process and a proper "bundle strategy".

But there are folks who wish all this wasn't so complicated, like Pawel Grzybek:

Three things that I wish I could ditch from my everyday front-end workflow: CSS preprocessors, JavaScript transpilers and module bundlers.

ES6 modules support lands in browsers: is it time to rethink bundling?

Modules, as in, this kind of syntax right in JavaScript:

import { myCounter, someOtherThing } from 'utilities';

Which we'd normally use Webpack to bundle, but now is supported in Safari Technology Preview, Firefox Nightly (flag), and Edge.

It's designed to support progressive enhancement, as you can safely link to a bundled version and a non-bundled version without having browsers download both.

Stefan Judis shows:

<!-- in case ES6 modules are supported -->
<script src="app/index.js" type="module"></script>
<!-- in case ES6 modules aren't supported -->
<script src="dist/bundle.js" defer nomodule></script>

Not bundling means simpler build processes, which is great, but forgoing all the other cool stuff a tool like Webpack can do, like "tree shaking". Also, all those imports are individual HTTP requests, which may not be as big of a deal in HTTP/2, but still isn't great:

Khan Academy discovered the same thing a while ago when experimenting with HTTP/2. The idea of shipping smaller files is great to guarantee perfect cache hit ratios, but at the end, it's always a tradeoff and it's depending on several factors. For a large code base splitting the code into several chunks (a vendor and an app bundle) makes sense, but shipping thousands of tiny files that can't be compressed properly is not the right approach.

Preprocessing build steps are likely here to stay. Native tech can learn from them, but we might as well leverage what both are good at.

Learning from Lego: A Step Forward in Modular Web Design

Samantha Zhang:

When web components are modular like Lego bricks down to the elements level, they become more versatile and easier to maintain. We believe it’s the next step to take in modular web design.

It's a clever system: put a half-gutter around all elements and a half-gutter around the containers. That way no matter what touches what, full gutters are naturally there.

icon-anchoricon-closeicon-emailicon-linkicon-logo-staricon-menuicon-nav-guideicon-searchicon-staricon-tag