> The project is called "mrmanager" and is currently not open-sourced, but if there's interest we can make it happen.

If the performance profile is as asserted "From a hot cache, mrmanager is capable of executing React (with ReactDOM) in 9ms instead of SystemJS' 150ms.", I and many others would likely benefit from making the loader open source

Yes, please open source this. Also, it wasn't clear from the article exactly which part needs to run on the server. Does anyone understand that part?

This was a great read, and a pleasure to follow your path to the end result. I think it would be great if you would Open Source it.

I've been working some time on a web playground ( https://flems.io ). It is based on an open source single file module (https://github.com/porsager/flems) that anyone can use to make a live showcase for their documentation / examples and what not. Flems.io simply uses unpkg.com directly. Unpkg.com does it's own resolution by first looking for an `unpkg` field, then `browser` and last `main` in package.json. This works great since most browser packages also comes with a browser distribution. If the package doesn't point to a browser compatible bundle you can always go directly to a working one, like in the case of react, which would be used like this: https://goo.gl/b4546q

Mithriliites assemble! (Flems is built with Mithril, and Per Harald Borgen from Scrimba digs the framework as well)

JavaScript modules are supported by default in Chrome 61

https://www.chromestatus.com/feature/5365692190687232

Am I the only one who thinks running scripts on a site directly from npm is a bad idea? What happens when an incompatible change in any of the dependencies is pushed. What if a package owner had transferred his ownership und the new owner pushes whatever he wants.

Using unpkg.com as an example they redirect from the root URL of a package to the latest version. For instance https://unpkg.com/mithril will redirect to https://unpkg.com/mithril@1.1.4/mithril.js

For example if adding a URL on https://flems.io it will store the xhr.responseURL to take advantage of this to pin the version. I would guess guess Scrimba does something similar?

Wow, so you auto-pin, that's great!

For one off examples it is just convenient. For long-lasting demo, it would be wise to pin the versions.

Hopefully all this madness will be over soon when people start publishing JavaScript modules to npm so we don't need WebPack for development anymore.

Can you explain? Webpack actually uses modules from npm. Distribution is a separate matter to bundling. Not sure what you’re getting at.

I think spankalee meant NPM packages being distributed as ES6 modules rather than ES5 source files that use require() or are pre-bundled with something like Webpack or Rollup (as is the case for many frontend packages). Node.js has support for ES6 modules since version 8.5.0 [1], so this will slowly become feasible.

[1]: http://2ality.com/2017/09/native-esm-node.html

That doesn’t change the need for bundlers like webpack, at least not until we have http2 everywhere.

I will believe http2 can efficiently replace a module bundling step when I see it ... unless esm also magically replaces the small module mentality of the npm ecosystem there will remain a ridiculously large number of small packages in the module graph of apps using npm packages ... turning module import into an async operation without a bundler is going to require a ridiculous number of round trips ... somehow dynamically building the bundling mechanism into n*m server layers sounds like even more of a nightmare to me than webpack ...

Also — even if you make every module import async — why would you want to get rid of the ahead of time bundler? Walking the module graph ahead of time is enormously useful for static analysis ... it seems to me like asynchronously loading a module is a special case file size optimization not the normal usage of a module in a program ...

Do people really see mjs and http2 as removing the need for module bundlers? I ask because I’m honestly extremely concerned — I thought that javascript modules were eventually going to grow a new syntax for async module loading not turn every import into an async operation. I don’t understand the vision being pursued here ...

It means we don't need them at development time. Just use modules (and an http/2 dev server for better multiplexing), then do bundling and other optimizations only for production.

It also means that project like in the article can mostly just go away - you don't need a custom loader.

This looks amazing, but trying the Playground there seems to be an issue when trying to rerun programs, giving: "TransactionInactiveError: A request was placed against a transaction which is currently not active, or which is finished."

I posted an issue about it here: https://github.com/scrimba/community/issues/110. We'll look into it :)

Just thinking out loud here. What about a stdlib framework that emulates node.js (eg. using BrowserFS) in the browser along with an optional stdlib minifier/zapper based on package.json. It seems like that approach would eliminate quite a bit of complexity.

An increasingly relevant followup: how to run NPM packages in a React Native app?

Why not use a bunlder? Webpack, Rollup, Browserify...

You'd want to load it dynamically over the network? That sounds like a very bad plan (tying your app uptime to the one of the NPM servers).

It's not as simple as using a bundler because the React Native runtime is unlike Node.js or common browsers regarding available APIs.