Using React on CodePen with ES6 and Fetch, Which Began With Some JavaScript Fatigue

Too Long, Didn’t Read: Look at this pretty CodePen example:

See the Pen React Github Example by John Lockwood (@JohnLockwood) on CodePen.

This is a story about a side trip, around a bit of a mess.

The main Journey was a Pluralsight course on ES6, but by the time I ended up learning about ES6 modules, I realized that that specification had moved on between the time the course was written and the occasion of your innocent author’s attendance, leaving said delicate flower fixing code that no longer had a straightforward implementation. So by way of side trip, naturally my search for the one true module loader in JavaScript led me to this nugget of wisdom:

There is no one true module loader in JavaScript. It’s a mess.

W’ll discuss the mess further in a moment, but first, a bit of mess history.

The Part About the JavaScript Fatigue

As near as I can read the history: CommonJS was awesome, but the poor browser folks had this natural reaction: “Hey, what about us poor browser folks — we are after all, the reason the language was invented?” With that, RequireJS was born. So along come the guys working on THE SPEC, and they say: Don’t worry, guys, we’re working on THE SPEC — we got this. So they invent THE SPEC for ES6 modules, which was in one format, then another format (that’s why my Pluralsight course broke). Meantime I think the Browser folks were feeling a certain nausea at this time, which is why THE SPEC, as near as I can tell, exists in implementation form only as this polyfill.

I promised you more about the mess, remember that? Here it comes — the last polyfill I mentioned, the one that implements THE SPEC, is described thus:

Provides low-level hooks for creating ES module loaders, roughly based on the API of the WhatWG loader spec, but with adjustments to match the current proposals for the HTML modules specification, unspecified WhatWG changes, and NodeJS ES module adoption.

Did you get that? You might as well come right out and say: “This is a mess”.

So into the mess, someone has to come along and try to order the mess. So they invent a little kerjigger with the modest goal of being the universal module loader, and they call it systemjs.

One can hardly blame them for trying to be universal. So now we have a universal module loader, that can load every module loader ever invented in this galaxy and beyond because it’s universal. So now we’re done, right?

No, sorry. We’re going to need a “frictionless browser package manager“, for the universal module loader, which fixes the mess of the spec, which grew out of the history of requirejs and CommonJS. And how do you install the “frictionless browser package manager”? With Node, of course, which at the end of the day is going to use CommonJS to load it. I was watching this video, learning how not to have friction by going full circle when I found a neat React sample, which I stripped down into a CodePen React sample.

JavaScript has some great features. JSON is so beautiful a way to represent objects as strings that just thinking about it touches my heart as pure poetry. Having this many ways to do what Java managed to get right between the import statement and the CLASSPATH is not one of JavaScript’s great features. Without disparaging anyone’s attempts to escape from the black hole sized gravity of this mess, at the end of the day it’s just sad.

Leave a Reply