Skip to content

Instantly share code, notes, and snippets.

@jhoguet

jhoguet/jspm-thoughts.md

Last active May 22, 2016 16:45
Show Gist options
  • Save jhoguet/cc77f09ad09479bfe7a3704a74fd1321 to your computer and use it in GitHub Desktop.
Save jhoguet/cc77f09ad09479bfe7a3704a74fd1321 to your computer and use it in GitHub Desktop.
Download ZIP
Thoughts on JSPM
Raw
jspm-thoughts.md

JSPM

JSPM is making some terrible choices IMO.

  1. Doesn't use npm the CLI, instead it uses NPM the http registry

    there is a very high chance that developers using JSPM also use NPM. Now their NPM packages might get installed in node_modules or jspm_packages even though they are the same package. They also need to understand how the jspm npm-registry works if anything goes wrong even though they already know how NPM works.

    there are good reasons they are doing this... but I am not convinced those reasons are worth it. In other words, I would rather see more complexity in JSPM to abstract this way, than more complexity on the consumer (as noted above).

  2. Uses both git the CLI and github's http api for the git registry

Here is a good read on jspm vs webpack with an honest lean towards webpack today but jspm tomorrow.

JSPM 0.16 is unbearably slow for development, high single digits seconds per page load!

While HTTP2 is making it possible to load many small http responses in a performant way, browsers are not yet optimized to execute hundreds of tiny JS files. I have not personally proven this, but it sounds plausible given that browsers have never needed to solve that problem, and surely there is overhead in creating a context for the javascript file to execute in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment