About
How did this Happen?
Given that the entire justification for babel pipelines was their eventual compatibility with the upcoming module system, I've always been expecting to have a functional module environment land where we can get back to write once, run anywhere JS development (again, as promised by modules). But, just as everyone who has used them, I discovered nothing was module compatible, despite their babel import syntax. So while browser support (and crucially import map support) landed, I kind of tuned out... but even when safari finally closed the gap, the situation in library space had not improved. I realized that to deliver my promised testable, module based ascii-art rewrite I would have to both rebuild many of it's dependencies as well as solve the lifecycle and testing problems myself. So I decided to resurrect an old canvas based image editing library as a proxy for that work (and so I could bring a relatively mature system to the rewrite when everything was ready).
First, in order to evaluate how difficult this would be, I wanted a project that was practical and based on a single foundational library that had good support on the client and server for native es modules. I decided on three.js and to use a mocha + chai setup similar to what I've been using for years, but with an additional static html harness for interactive browser running. The project would be a 3d treadmill for loading world chunks in and out of memory in a large, continuous world.
Next I ported an old mootools canvas oriented image editing library I wrote a decade ago to vanillaJS + esmodules. This required I build an abstraction to bridge the canvas available in the browser vs node.js as well as to wrapper some things for testing so we could have a single test file for everything. Additionally I wanted to be able to run the test in the all the supported browsers as well as in node and to have normal test runner output. This required me writing my own mocha test runner which could do the browser parts of this. This was successful.
Once this was done, I decided to rewrite some of my sites and GUI libraries using what I had learned in order to confirm this worked widely across browsers. As I was doing this, I realized there were no support sites to provide a banner or encourage adoption. These were services that were present for the transition to css (CSS zen garden), to html5 (html5.com (no longer active)) and webcomponents (wecomponents.org) (even RDF and OWL got more support than vanilla es modules). At the same time I could provide a concise support matrix, given the complexity of different scenarios and the user expectations. That was why I created this site. Hopefully it will become a community resource which is powered by community contributions, but until then I'm over here... porting all my libraries slowly to esmodules.