Remove JSPM

[gilamran]

The dev speed here is amazing! But, we already have npm and yarn all around, and the jspm repo is not really active that much... Can we remove the dep. on jspm?

[piotrwitek]

Hi @gilamran, Good question, I was thinking about it many times, as I'm not comfortable with jspm_packages thing and would be glad to be using only node_modules directory only. I have found alternative solution already but didn't had time to experiment with it, maybe you could volunteer to investigate and share your findings here or even maybe make some contribution :)

Here is a link to library in question: https://github.com/charto/cbuild

[martaver]

I think this setup has great potential as @gilamran says - the dev speed is amazing and dev speed is king.

I'm going to try out this SystemJS Hot Loader approach in a new project, mostly based on your boilerplate so I'm willing to put a few hours into this topic here and there.

My interests are

• keeping the dev cycle as fast as humanly possible.
• finding the best CSS scoping solution - I tried typestyle. It's nice, but breaks the editor experience a bit. SASS + scoping, like what webpack's sass/css-modules loader chain provides would be optimal IMHO.
• cleaning up the duplication mess between JSPM and node_modules.

If I understand correctly, most of the power of your boilerplate comes from SystemJS 0,17's new features... so where exactly is JSPM needed? E.g. with a brief look at the code, I don't see how JSPM is actually used in the HMR part of https://github.com/piotrwitek/jspm-hmr.

Also if you're using Rollup for production bundling, then shouldn't it be simple, in theory, to remove JSPM from the mix and just rely on SystemJS's features by itself?

[piotrwitek]

Hello @Martaver :)

• typestyle - works great for me, not sure what you mean in breaks editor exp, for me it is opposite, I'm using vscode and ts language server is the best tool you can get in this regard
• JSPM is only used to generate and update jspm.config.js which defines SystemJS modules map, this is why we could use cbuild instead and get rid of it because it is the only weak point of this boilerplate IMO

---

On the side note, I have found a better workflow that in dev speed can even outperform this one, moreover it has a TypeScript as first-class citizen and with plugins power of webpack but with dead simple config.

I have already started experimenting with a simple boilerplate you can check it out, but the repo is really early stage but I think you can test it to know what you are dealing with and it is already fulfilling all the interests that you have mentioned :) It is based on fuse-box bundler, it's on the branch fusebox-rewrite here: https://github.com/piotrwitek/react-currency-converter/tree/fusebox-rewrite

I'm also working on webpack / fuse-box / systemjs comparison project to compare hot reload performance, build time, bundle size etc. :)

[gilamran]

Meanwhile I've created my own FAST starter kit :-) based on webpack. https://github.com/gilamran/fullstack-typescript

[martaver]

not sure what you mean in breaks editor exp

You get the TS intellisense, but none for the actual CSS which you end up writing as strings. In practice, though, the flexibility & reusability of the TS probably wins, though.

This fuse-box thing looks great. So light. So fast. Much Typescript.

Noticed some weirdness when adding/removing new files/references e.g.

• Add a CSS file & reference it from a component/container - do you need to reload to see changes?
• Remove the CSS file/reference - Does the old CSS still persist? do you need to reload to see changes?
• Add/remove the reference only - same issues...
• Create a second CSS file, leaving the old one & just switch the reference to the new one - the old css is still persisted, just overwritten by the new? Try switching back and its broken...

Above can be resolve by a reload, which is fast, but it loses state. Does SystemJS have similar issues?

Fuse-box is really fast, but I feel like the SystemJS no-bundling approach is still more scalable.

With regards to scoped CSS - how can we get feature parity with webpack's css-modules? The Fusebox API looks great - so maybe we can fork its existing CSS loader to do it.

[guillaume86]

@Martaver I also like fuse-box very much. SystemJS get pretty slow when you're getting into the hundreds of files and I really don't like that jspm folder.

Regarding your CSS workflow issues, they're probably fixable inside fuse-box. I had similar issues with SystemJS (old CSS persisting after change etc) and I just fixed the issue myself at the time.

[martaver]

Fusebox does seem to be in winning mode.

I just discovered they're working on version 2.0 (currently in beta) - http://fuse-box.org:3333/ One of the new features include css-modules... http://fuse-box.org:3333/plugins/cssmodules-plugin Combine that with this bad boy and we're laughing: https://github.com/Quramy/typed-css-modules

[piotrwitek]

@Martaver nice idea, thanks for sharing, although I still prefer typestyles, because I don't write raw css because I prefer css as object style with the full power of JS lang to write various mixins and utility functions and then higher order functions and functional composition of styles on my components rather that style classes, leveraging style re-usage as much as possible, you can do it in css as well but it is and not as powerfull, have weird syntax and I don't think you can have type checking in css mixins :)

[martaver]

I am coming around to the idea of typestyles too... and what you said does make a lot of sense. I think another great benefit of typestyles is that it will tree-shake all CSS that isn't used. Who knows maybe I will end up using it.

How do you use it practically, do you actually switch out CSS in real-time for UI styling updates, or more just use it as a once off style builder?

Also, how do you handle assets like background-images in your typestyles with fuse-box?

For the record, I got fuse-box 2.0 working with sass/css-modules. I based much of it on your experimental branch. I'll push a demo soon!