
Install NPM dependencies that run in browser without Browserify, Webpack - darrinm
https://github.com/pikapkg/web/blob/master/README.md
======
lewisl9029
HTTP2 solves the loading multiple dependencies in parallel part of the
equation, but as far as I can see, the browser would still have to download
each dependency before they can resolve their transitive dependencies, so
wouldn't this suffer latency issues due to requiring as many sequential
client-server roundtrips as the max depth of your dependency tree?

SystemJS & JSPM has been around for quite a while now, and the goals are
similar to this project (to enable loading of any NPM dependency as native ES
modules in the browser). They solve the roundtrip problem using an import map
that's generated by JSPM to pre-resolve all transitive dependencies, so they
can be loaded by the browser up front with maximum parallelism.

However, this project specifically calls out the lack of a need for an import
map in its description as an advantage, so I'm wondering if they have some
alternative solution to this problem.

Also somewhat related: the project maintainers for SystemJS and JSPM also
provide a CDN at [https://jspm.io/](https://jspm.io/) serving jspm packaged ES
modules for all npm packages, so you can load them as native ES modules with a
module script tag or native dynamic import() call in supported browsers. But
they specifically mention that this CDN is meant for quick
prototyping/experimentation, and not suitable for production use due to
latency issues, and recommend bundling workflows for production.

I've been following the SystemJS and JSPM projects for quite a while now, and
I feel it's a much better solution for module loading than webpack and the
likes that hack together their own non-interoperable proprietary module loader
rather than supporting and advancing the official ES module loading standard.
But unfortunately that's where the community is at, and SystemJS and JSPM has
never been able to reach that critical mass of essential dev tooling that
webpack & others have enjoyed for quite some time (the major road block I ran
into the last time I tried it was the lack of a good hot module replacement
story for development targeting the latest SystemJS 2.0 environment).

~~~
spion
> the browser would still have to download each dependency before they can
> resolve their transitive dependencies.

The endgame of that train of thought is something like
[https://mariusgundersen.net/module-
pusher/](https://mariusgundersen.net/module-pusher/)

~~~
pygy_
Indeed, and it can even be done with HTTP/1: [https://jacquesmattheij.com/the-
several-million-dollar-bug/](https://jacquesmattheij.com/the-several-million-
dollar-bug/)

tl;dr: a smart server can start pushing dependencies as soon as the request
for a module comes in.

Even with HTTP/1, the browser will handle a response that came before the
matching request.

------
_bxg1
This has been the biggest thing holding back wide adoption of native ES
modules: every single one of your dependencies has had to be a proper,
browser-compatible module. Very exciting.

------
rubbingalcohol
I'm very curious how you could possibly avoid code bloat with this. Installing
hundreds of megabytes of dependencies is fine server side, but won't this
approach lead to massive JS downloads?

~~~
est31
Yeah, bundlers have dead code analysis and throw some of the unused code out.

------
kevinsimper
This is what I wished for when I began using Web Components, and it is super
awesome +1

~~~
bsimpson
The author was on the Polymer core team.

[https://github.com/FredKSchott](https://github.com/FredKSchott)

------
Klathmon
Wow, they claim that this is equal to or better than most apps that are
bundled into a single bundle file due to the cache benefits!

I never would have guessed they could manage that and keep it this easy to
use!

How common is the es module entry point in major packages?

~~~
tolmasky
If I understand correctly, they say this is only the case when you have less
than 1000 flies:

    
    
        @pika/web's installation most closely matches the study's moderate, "50 file" bundling strategy. Jung's post found that for HTTP/2, "differences among concatenation levels below 1000 [small files] (50, 6 or 1) were negligible."
    

Our app is certainly over that, and I suspect most apps quickly grow to this
(most of the files _are_ dependencies). I'm not sure where the 50 moderate
number comes from (we have an unfortunate dearth of information when it comes
to "real world test cases" \-- it seems common for bundlers to just check
whether it performs better for the app they were working on at the time), but
I would be surprised if most the 50 file threshold is maintained for very long
for highly dynamic sites (vs., say, a company brand site or a blog where this
may be the case forever? Again, I honestly have no idea).

~~~
tyingq
_" Our app is certainly over that [1000 files]...I suspect most apps quickly
grow to this"_

I've not had a need to do much JavaScript since the days when you just
directly used a few external libraries via <script>, so this just sounds nuts
to me.

I suppose it's probably common, and the various packers make it work fine, but
wow.

~~~
Klathmon
The current JS ecosystem leans heavily on bundlers and packers to enable this
kind of workflow, and IMO it's a good thing that we do.

For example, lodash (a somewhat common set of utility functions and general
helpers) is a single package, but internally it's broken up into hundreds of
individual packages which lean on the dependency module system to resolve
among themselves, deduplicate, and enable the ability to include only a few of
them (and their dependencies) if you only need those in a project.

Many libraries are setup like this, because there's not much of a reason not
to. Adding complicated functionality to an existing package is often worse for
everyone than just creating a new package which implements what you want and
setting it as a dependency.

------
Theodores
This is brilliant for my efforts to just get started with THREE.js. I gave up
due to module dependencies first time around, now I can actually get over that
hurdle and get on to what I had planned to do with THREE.js maybe to do things
the proper, optimised way with Browserify once I have some feasibility study
done on my localhost where I don't care about it being more than a rough
prototype.

~~~
syspec
Easiest way is to just use the pre-built version of THREE, and throw it on
your page via script tag include.

Then it’s available in the window.THREE object, it’s not the “most correct”
way but it’s great for prototyping

~~~
Theodores
Thanks for your tip, I tried that but then I wanted to use some lathe type
thing to make a shape and got into module hell. I am trying to not distract
myself with having fun with that right now as I only want to make an
'undocumented feature' along the lines of embedding a flight simulator in a
spreadsheet program, but it pleases me that I can get on it later to cook
something fun up.

------
nailer
Does this work with commonjs modules or not? There's so few tc39 modules it's
almost not worth considering otherwise.

~~~
fks
It does!

> By default, @pika/web will install all package.json dependencies with an ES
> "module" entrypoint to the web_modules/ directory. @pika/web is able to
> handle any legacy Common.js/Node.js transitive dependencies in your
> dependency tree, however the top-level dependencies (the ones that you
> import directly) must have a "module" entrypoint.

------
ComputerGuru
I was excited but it looks like it'll break Typescript's module resolution.
I'm sure someone will come up with something in time, but this is the same
story over and over with web development this side of 2016. Nothing works
together.

~~~
hliyan
This is why we need a JS standard library...

------
chrisweekly
Way to take advantage of HTTP/2\. Really cool idea, and at a glance it looks
like a reasonable implementation. Stoked to give this a try! :)

~~~
Zardoz84
Sadly, there is people that can't use yet http/2

