Tag Archives: JSPM

Aurelia Release for JSPM Beta


via Aurelia Release for JSPM Beta.

The spec for the standard JS module loader has recently been changing. The JSPM and SystemJS teams have been working hard to align with the new specs. And as of this release, Aurelia is now aligned with the new JSPM and SystemJS Beta.

Next-generation ES6 module bundler


via rollup/rollup · GitHub.

This is an early stage project under active development. If you find a bug, please raise an issue!.

  • A next-generation ES6 module bundler

    Right now, you have a few different options if you want to create a bundle out of your ES6 modules:

    • The best option, in terms of performance, size of the resulting bundle, and accurate representation of ES6 module semantics, is to use esperanto. It’s used by ractive.js, moment.js, Facebook’s immutable.js, the jQuery Foundation’s pointer events polyfill, Ember CLI and a bunch of other libraries and apps
    • You could use jspm, which combines a module bundler with a loader and a package manager
    • Or you could use browserify or webpack, transpiling your modules into CommonJS along the way

    e way

Part 2: Backend Apps with Webpack: Driving with Gulp


via Backend Apps with Webpack, Part II: Driving with Gulp.

In Part I of this series, we configured webpack for building backend apps. With a few simple tweaks, like leaving all dependencies from node_modulesalone, we can leverage webpack’s powerful infrastructure for backend modules and reuse the same system for the frontend. It’s a relief to not maintain two separate build systems.

This series is targeted towards people already using webpack for the frontend. You may find babel’s require hook fine for the backend, which is great. You might want to run files through multiple loaders, however, or share code between frontend and backend. Most importantly, you want to use hot module replacement. This is an experiment to reuse webpack for all of that.

In this post we are going to look at more fine-grained control over webpack, and how to manage both frontend and backend code at the same time. We are going to use gulp to drive webpack. This should be a usable setup for a real app.

Some of the responses to Part I criticized webpack as too complicated and not standards-compliant, and we should be moving to jspm and SystemJS. SystemJS is a runtime module loaded based on the ES6 specification. The people behind jspm are doing fantastic work, but all I can say is that they don’t have many features that webpack users love. A simple example is hot module replacement. I’m sure in the years to come something like webpack will emerge based on the loader specification, and I’ll gladly switch to it.

The most important thing is that we start writing ES6 modules. This affects the community a whole lot more than loaders, and luckily it’s very simple to do with webpack. You need to use a compiler like Babel that supports modules, which you really want to do anyway to get all the good ES6 features. These compilers will turn ES6 modules into require statements, which can be processed with webpack.

I converted the backend-with-webpack repo to use the Babel loader and ES6 modules in the part1-es6 branch, and I will continue to use ES6 modules from here on.

How to start writing apps with ES6, Angular 1.x and JSPM


via How to start writing apps with ES6, Angular 1.x and JSPM — Martin Micunda.

Couple weeks ago I have started to work on one of my personal projects (Employee Scheduling) and at that time I didn’t think I will write any of my code in ES6 not because I wouldn’t want to try one of the cool ES6 features but I was more concerned how to automating my development workflow with ES6 and I also want to get my code to production until I watched Guy Bedford video from JSConf2014 where he was talking about ES6 modules workflow using JSPM. As you may guess JSPM solves a lot of my concerns and today I want to share my ES6 development and production workflow using JSPM. The Employee Scheduling application screenshot: