Posted on

Snowpack

Snowpack. Love that name. This is the new thing from the Pika people, who are on to something. It's a bundler alternative, in a sense. It runs over packages you pull from npm to make sure that they are ES module-compatible (native imports).

This is how I digest it. When you write a line of code like:

import React from "react";

That's actually invalid JavaScript. It looks like a native import, but it isn't. (It would start with a filepath character like ./ and end in .js to be valid.) It's just an agreement from Big Bundler like, "Oh, I know what you mean. You mean I should go look in node_modules for this thing." Then it goes and does it.

A lot of stuff on npm isn't ready for ES modules. It's in some other module format (e.g. CommonJS) and assumes you'll be using a bundler with it. An assumption served them just fine for a while, but it's an assumption that is starting to be a bit of a thorn for front-end developers.

UNPKG has had a feature where you could add ?module to the end of their URLs to get it to serve up an ES module-friendly version of the package, but it's been in an experimental stage for a long time because, presumably, it's a hard problem to solve. Which packages are ready for ES modules? Can they be processed to be ready on the fly?

Even the Pika CDN doesn't solve the issues of packages that aren't written to be used via ES modules. For example, since React isn't written to be used with ES modules directly, so you just can't (but you can still use it via <script> tag).

Snowpack has apparently dealt with this. It runs its magic over the packages that you install (locally) and prepares them for ES module usage. So, after Snowpack has ran, now you can do this (which you haven't been able to do before):

import React from '/web_modules/react.js';

Which is valid code for ES modules. Plus, if you run Babel anyway, you don't even have to change that original line.

Hence their marketing/explanation:

1) Instead of bundling on every change, just run Snowpack once right after npm install.
2) Snowpack re-installs your dependencies as single JS files to a new web_modules/ directory.
3) Write code, import those dependencies via an ESM import, and then run it all in the browser.
4) Skip the bundle step and see your changes reflected in the browser immediately after hitting save.
5) Keep using your favorite web frameworks and build tools! Babel & TypeScript supported.

It's kinda like you get native code splitting for free, and you're just crossing your fingers that ES modules will be just as fast as bundling with that benefit. I'm optimistic. I think it's early days and would be nervous on Big Production Stuff, but I also think native ES modules are probably the future.

The post Snowpack appeared first on CSS-Tricks.

Posted on

Animated Position of Focus Ring

Maurice Mahan created FocusOverlay, a "library for creating overlays on focused elements." That description is a little confusing at you don't need a library to create focus styles. What the library actually does is animate the focus rings as focus moves from one element to another. It's based on the same idea as Flying Focus.

I'm not strong enough in my accessibility knowledge to give a definitive answer if this is a great idea or not, but my mind goes like this:

  • It's a neat effect.
  • I can imagine it being an accessibility win since, while the page will scroll to make sure the next focused element is visible, it doesn't otherwise help you see where that focus has gone. Movement that directs attention toward the next focused element may help make it more clear.
  • I can imagine it being harmful to accessibility in that it is motion that isn't usually there and could be surprising.

On that last point, you could conditionally load it depending on a user's motion preference.

The library is on npm, but is also available as direct linkage thanks to UNPKG. Let's look at using the URLs to the resources directly to illustrate the concept of conditional loading:

<link 
  rel="stylesheet" 
  href="//unpkg.com/focus-overlay@latest/dist/focusoverlay.css" 
  media="prefers-reduced-motion: no-preference"
/>

<script>
const mq = window.matchMedia("(prefers-reduced-motion: no-preference)");

if (mq.matches) {
  let script = document.createElement("script");
  script.src = "//unpkg.com/focus-overlay@latest/dist/focusoverlay.js";
  document.head.appendChild(script);
}
</script>

The JavaScript is also 11.5 KB / 4.2 KB compressed and the CSS is 453 B / 290 B compressed, so you've always got to factor that into as performance and accessibility are related concepts.

Performance isn't just script size either. Looking through the code, it looks like the focus ring is created by appending a <div> to the <body> that has a super high z-index value in which to be seen and pointer-events: none as to not interfere. Then it is absolutely positioned with top and left values and sized with width and height. It looks like new positional information is calculated and then applied to this div, and CSS handles the movement. Last I understood, those aren't particularly performant CSS properties to animate, so I would think a future feature here would be to use animation FLIP to take advantage of only animating transforms.

The post Animated Position of Focus Ring appeared first on CSS-Tricks.

Posted on

Next Genpm

So many web projects use npm to pull in their dependencies, for both the front end and back. npm install and away it goes, pulling thousands of files into a node_modules folder in our projects to import/require anything. It's an important cog in the great machine of web development.

While I don't believe the npm registry has ever been meaningfully challenged, the technology around it regularly faces competition. Yarn certainly took off for a while there. Yarn had lockfiles which helped us ensure our fellow developers and environments had the exact same versions of things, which was tremendously beneficial. It also did some behind-the-scenes magic that made it very fast. Since then, npm now also has lockfiles and word on the street is it's just as fast, if not faster.

I don't know enough to advise you one way or the other, but I do find it fascinating that there is another next generation of npm puller-downer-thingies that is coming to a simmer.

  • pnpm is focused on speed and efficiency when running multiple projects: "One version of a package is saved only ever once on a disk."
  • Turbo is designed for running directly in the browser.
  • Pika's aim is that, once you've downloaded all the dependencies, you shouldn't be forced to use a bundler, and should be able to use ES6 imports if you want. UNPKG is sometimes used in this way as well, in how it gives you URLs to packages directly pulled from npm, and has an experimental ?module feature for using ES6 imports directly.
  • Even npm is in on it! tink is their take on this, eliminating even Node.js from the equation and being able to both import and require dependencies without even having a node_modules directory.

The post Next Genpm appeared first on CSS-Tricks.