Skip to content
loading...
Discussion
markdown guide
 

ES Module versions of everything. With ESM there is so much untapped potential for optimization.

I have done a bunch of work in the VanillaES org but that's just the start.

github.com/vanillaes

 

Interesting, do you mean converting existing packages to use ES syntax? Might start taking a look at that. In your organization, do you convert existing projects? I'd definitely love to help out!

 

Simple answer: Ideally yes, converting existing packages would save a LOT of time an effort


Complex answer: Converting existing packages -- in most cases -- is a lost cause

ESM is strict by default, meaning most very old libs can't be converted without significant rewrites.

Likewise, packages that ship ESM for Webpack (ie not spec ESM) or CommonJS use a lot of old/bad patterns: conditional imports, synchronous import behavior, globals, node-specific imports, etc.


A good quality ESM package...

  • shouldn't depend on runtime-specific behavior
  • should use relative imports
  • should use named exports
  • should tree-shake dead code

So far, most of the projects have been built by scratch. Of course, now that ESM is officially supported in Node 14.x more existing libs may be open to switching. I'm always open to migrating an existing project over if the project's Maintainer is on board.

If you want to help, the computer-science repo is a good place to get a feel for working w/ ESM. You can post ideas and discuss org-wide stuff in this repo github.com/vanillaes/vanillaes.

Classic DEV Post from Jul 26 '19

🎩 JavaScript Enhanced Scss mixins! 🎩 concepts explained

In the next post we are going to explore CSS @apply to supercharge what we talk about here....

caelinsutch profile image
UC Berkeley Freshmen, Cofounder of Bytes Robotics, Enthusiastic Web and Mobile Developer.