Member preview

Webpack with JSPM and a spoonful of SystemJS. A walk down build system lane.

Note, the following is meant as a public brain storm. More accurately, a mid summer brain soothing waterfall. I was thinking about what constitutes a good front end build system and how I can possibly contribute to the current state of build systems. Also, I was interested in the possibility of automated configurations, yet allowing them to be changed manually as well. A higher level of what NPM/JSPM currently does. Finally, I am curious if there is a dividing philosophy that has led to the most recent creation of JSPM. If perhaps we can look towards a future where we can see a merge of Webpack and JSPM etc. Also, July 4th weekend, mostly July 4th weekend.

If someone were to stop you in the street and ask, “What constitutes a good front end build system.”, what would you say? For those of you who went through a computer science program, there is no course dedicated to a good front end build architecture. For those of us in the industry, build systems have been something in the making, with new build systems springing up on average of every 8 months.

Build systems are how we can be productive and really enjoy development, but at the same time pushing the cutting edge always requires such a large amount of time. I’ve been through the front end build system ride as of late. I’ve started with Grunt. I remember that Grunt compilation times would take so long(4.8s), that I decided to actually buy a faster laptop(macbook pro retina 15 inch). I then remember when Gulp came around and my compilation and configuration times halved. I also remember seriously regretting my decision, putting down my laptop, and picking it up again. Yup, it was just that devastating!

I also, remember that around that same time, I was introduced to an article mentioning that there truly is no reason for us to use build systems. We can use scripts for everything(make, node etc.). At that time he was completely right[and to a large extent, still is for task running]. I converted all of my Jade and Sass tasks to plain npm scripts. My 30 lines of configuration went to two lines of commands. My live-reload was it’s own task, and that was it.

Around this time though, Angular and React started making their way into mainstream builds. Things such as browsersync, and hot-reloading became buzz words. File loading became more important, especially with React. Configuration with Browserify and Webpack eased up these processes. Even easier than using the native node scripts. (Although, I do agree node scripting should be used whenever it makes sense[an argument in it’d own right], for future proof sake.)

In addition, JSX, Babel, as well as hot reloading, made Webpack just that attractive. All I have to do is add one exclamation point and it solves all of my problems. Terrific! To date webpack is still of ease. I have no problem using eslint, or introducing new standalone technology such as CSSX, or CSS-Modules.

JSPM comes into the equation and it makes a large of this process much easier, as it allows for “frictionless package management”. So what does frictionless package management mean exactly? For starters, it runs off of SystemJS. That means that I can import files without having to include a loader, but what if I want to include something like autoprefixer? What if I want to use eslint? Ok, you will still have to include a loader, but at the very least creating one is quite simple.

Cool, I think, I am able to simply install things without having to do any configuration. That is simply incredible. The secret sauce is System.js which uses a technique they call Zebra striping. It will allow for the right type of handling for the specific module. Configuration for custom plugins is a breeze. (However, I can do without all the extra exclamation points when including files.) In addition, more nuanced features like hot-reloading is of ease due to how system.js emits an event every time a file is handled due to circular dependencies. Tree shaking is also of ease, because it uses rollup.js as part of it’s builder. So one does not have to worry about compilation times being slowed down by unused modules.

In short, JSPM is incredible due to System.js(both created by same individual, *round of applause*, pause, another *round of applause*). That is really the magic sauce behind it all. I should note that I have been using JSPM 0.17beta, and I have found it to be quite quick. I came across one issue with regards to Eslint, but it was still a breeze to setup eslint. That however, is exactly where jspm’s main issue currently arises. Configuration. While yes, configuration can be tamed, accidentally installing the wrong thing using jspm install will set you back. Taming configuration is the last item on my JSPM bucket list.

In addition, hot-reloading, was something that I had to manually configure. Albeit, much help from the creator of JSPM hot-reloading. Nonetheless, it took quite some time to get it up and running. Bundling is also of ease of use as JSPM has it’s own native file mechanism. At the end of the day, JSPM works quite well. For most of the cutting technology that I like using, loaders have already been made for a large percentage of those loaders. So what, maybe I’ll have to make one or two.

The configuration theme/philosophy runs through a large part of the JSPM framework. That is, in my humble opinion, it sacrifices automation for clutter. I also prefer the more intuitive nature of webpack’s loaders. I can already see the philosophy behind JSPM aligning with Angular 2 and Webpack aligning with React for that reason.

It is worth noting that Webpack 2 will be switching over to SystemJS , and that JSPM really is just a cli to hook up to SystemJS(Feel free to correct me if I’m wrong. If I spent ample time researching article would have never been finished). So if all roads are heading towards SystemJS, so then what does the future hold for build systems. Can we perhaps see a Webpack — JSPM merger. Personally, I love the word merger, merger.

It really is a matter of how jspm vs webpack will pan out. I think it’s fair to say that webpacks configuration is more intuitive, but jspm has all the piping and architecture necessary to work with System.js. This leads me to ask what does constitute a build system, what are we looking for in a front end build system, regardless of framework, or modules used. Ok, pause, real quick let’s list some stuff.

Core Features

  1. Run time
  2. Tree shaking
  3. Hot reloading
  4. Minification
  5. Compilation Time
  6. Introduction of new module to core build system
  7. Package management
  8. Ease of configuration
  9. Introduction of new libraries → E.g. lodash, css-modules

Task running

  1. Templating
  2. Linting
  3. Testing
  4. Server

Popular pre-processors/tools

  1. Sass(auto-prefixer, css-modules)
  2. Transcompilation(Babel, Typescript)
  3. Utility Libraries(Lodash, Underscore)
  4. Browsersync

(gist can be found here):

All in all, is there a way that we can mediate in between webpack and jspm/System.js. I really do feel that we are a point where we are arriving at a mature robust front end build ecosystem. On second thought, if the past couple of years in front end have taught me anything… Ahem, if the history of software development has taught me anything, I am completely mistaken.

Nonetheless, suffice to say, the next gen front build system will end up looking similar to this. It will contain Webpack configuration automatically created by the Jspm cli, a large part running off of SystemJS, and npm/node for task running and package management. If not, then we should try to make it look that way.

Once again, just a brain storm(/waterfall/firework etc.), but for creativity sake, and for the future of front end build systems, feel free to leave comments of any sort. Keep being amazing, and thanks for reading, or skimming. Both work!