
How we run NPM packages in the browser - judofyr
https://scrimba.com/c/c6azJtG
======
TAForObvReasons
> 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

~~~
glibgil
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?

------
porsager
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](https://flems.io) ). It is based on an open source single
file module
([https://github.com/porsager/flems](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](https://goo.gl/b4546q)

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

------
tarr11
JavaScript modules are supported by default in Chrome 61

[https://www.chromestatus.com/feature/5365692190687232](https://www.chromestatus.com/feature/5365692190687232)

------
js4all
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.

~~~
porsager
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](https://unpkg.com/mithril) will redirect to
[https://unpkg.com/mithril@1.1.4/mithril.js](https://unpkg.com/mithril@1.1.4/mithril.js)

For example if adding a URL on [https://flems.io](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?

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

------
spankalee
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.

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

~~~
denisw
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](http://2ality.com/2017/09/native-esm-node.html)

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

~~~
breatheoften
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 ...

------
xixixao
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."

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

------
grizzles
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.

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

~~~
pygy_
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).

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

