Huge. Between webpack and Babel, JS is quickly progressing towards becoming a powerful language that is easy to write, read and reason about. I'm currently in the process of moving an inherited "minified by hand" codebase to ES6, and the difference is incredible. Not only are linters catching hundreds of previously unknown edge cases and bugs, but the end result is more performant and smaller in file size. It's very satisfying, makes me not mind coding in JS again.

Have you looked into TypeScript? Type system helps you catch even more errors.

Second this. There is no reason not to use TypeScript now that's easier to work with .jsx and add 3:rd party libraries without dealing with type definitions.

Also, make sure to try out atom-typescript by Basarat. It's genuinely amazing and feels like Swift. :)

Another supporter here. I was very reluctant at the beginning but after seeing how it helped catch bugs earlier, I can't go back. I actually think that TypeScript makes JS more flexible because of the patterns it enables. I enjoy it even more than C#.

Since adopting Redux, I've not seen many advantages of TypeScript. My codebase is just pure functions that describe simple state objects. What sort of advantages do I stand to gain by bringing in TS in this situation?

When implementing overloaded functions, explicitly defining an interface would allow for much easier debugging than testing it afterwards. Running tests (that can take up to seconds sometimes) is far less efficient than seeing the problem nearly immediately

Another vote, catches so many errors and if decide to refactor you can pretty much just follow the compiler errors till it compiles.

I would guess that compatibility with existing JS libs is far easier with Typescript. You can trivially consume an existing JS lib from TS or export/compile your TS lib to pure JS, which other JS then can seamlessly consume.

Although I don't have bigger experience with Elm, Purescript, Scala.js, Ceylon, Websharper & Co I guess its more complicated with them. An advantage here is also that Typescript does not bring along it's own standard library (e.g. new collection types) which could cause problems on interoperability.

Another advantage is getting other people on board. Getting developers from pure JS to typescript is not difficult, especially when they are used to Java/C++/C# (which most developers are). The learning curve for the other languages will be higher for most developers.

Well those 2 are entirely new languages, not just javascript with types added so they are not the same thing.

Not everyone knows or want to learn Haskell

What's the current thinking as of 2016 about Browserify versus Webpack? We've been happy Browserify users for a couple of years now, but I'm drawn to both the code splitting and dynamic expressions parts of Webpack.

On the other hand, I'm not keen on introducing more complexity or changing things just to be "fashionable", and Browserify, Babel, and Gulp do work together reasonably well for us (though I didn't much enjoy getting it all working in the first place, and I'm always nervous about updating any of them).

I think Browserify is an excellent tool. It does the one job I generally need it to, importing dependencies so I can write modular JS code. Running it is a one-liner, and running it with Babel is one extra option. Its behaviour is reasonably transparent, so you can look at the actual output and see what is really going on even if source maps aren’t helping for whatever reason.

Personally, I’m not such a fan of Webpack. It trips my “too complicated” alarm, like RequireJS before it. I’ve never worked on a project that needed the kind of dynamic behaviour these tools support, and you pay a price for that flexibility in the complexity of the tool and the output it produces. Likewise, while you can include almost anything as part of your bundled JS output with Webpack, I’ve seen few real world cases where this is a significant advantage, and again you get locked into Webpack and its complexity as the downside. Perhaps on some types of project the features Webpack offers represent more compelling benefits.

For perspective, I’m also not a fan of tools like Gulp, also on the grounds that their ecosystems tend to be fragile and they add unnecessary complexity to what is usually a pretty simply operation in the first place.

I think when comparing grunt and gulp to webpack, that they solve different issues.

grunt gets complicated easily, by including a bunch of plugins and defining their configuration in a declarative manner. Gulp solves those issues by letting the user determine how to configure it himself, so the user can load in the package.json to load constants.

While webpack also does that, It imo has a more sensible definition. Instead of the grunt/gulp approach, where you would say, do these actions with this folder, and this with that folder; webpack allows you to say, "if it's a jsx file: do this, and it's extension becomes: .js" There's a lot less configuration needed for projects involving webpack, because it just lets you define transforms. Usually everything is turned into js (including images/css). But it also allows you to expose some files in the output to be loaded externally.

So there's no more 'gulp task' to run, now I'm just using npm scripts (npm start, npm run build, enz)

I selfishly want more people like you in the javascript ecosystem. I had a debate with a freind if mine about gulp. My argument is that all of these tools are useless since they can be done without them. If only certian tasks should be run, create a commander script that takes in amount of args and runs each of those tasks.

His argument is that these gulp and grunt files standardize build and test scripts. Now its something you can definitively check off a list and when looking at others code have a form of familiarity.

I personallt agree, complexity and extra wrappers around what is already working makes little sense. But there are reasons these types of frameworks exist

> My argument is that all of these tools are useless since they can be done without them.

My gulpfile.js minifies several application modules and 3rd party libraries into a small set of modular, organized files. A polyfill is included. ES7 is converted to ES5. Bootstrap 2 libraries are upconverted to BS3. BS2 icons and BS3 glyphicons are converted to font awesome. Image URIs are transformed/replaced on disk dynamically and in CSS/JS references to my modular preferences. Public access keys (rollbar, stripe, etc.) are injected into my builds from .env variables. Tiny changes can be injected into libraries until the maintainence cost of a fork becomes less than the cost of a replace. This script can be called with one command, this script's submodules can be called individually. The full command is mulithreaded. Perhaps the issue is not that these actions can technically be done without a build tool, but that you don't use any of the advanced functionality these tools were built to automate?

I guess I just don’t see what benefit is gained by writing a dozen lines of fragile boilerplate to run Browserify via Gulp. If you want to put the build automation in a well-known location, a typical Browserify+Babel build is one line in the scripts section in package.json that says something like

    "js": "browserify src/index.js -o dist/index.js -t [ babelify --presets [ es2015 ] ]"

If you need more complicated configuration, you can use separate sections of package.json to set useful defaults, which is also the common convention for build tools in the Node/NPM ecosystem.

Again, I agree. Picture this: mocha gives testing globals, browser offers the window and dom, node offers process arguments. Coming from a partial teachers perspective (well, I wasnt hired to teach but I did talk to the students alot) gulp seemed to offer comfort and order in a world where "you can do anything" seems to cause imobilization. That problem I believe can be solved through introducing students to a philosophy of "you are in control, machines are dumb, only google can save you" but I can see where seperation makes people much more comfortable

I was in the same boat in 2015, happily using a hacked-together solution of gulp-babel-browserify that took a few days to set up correctly. Than, after hearing about it enough, I decided to give webpack a try.

After a few hours of learning, I've succesfully set up webpack with hot module reloading and some other niceties. It was certainly much more cleaner than my old solution.

I'm a webpack user since than. It's easier to understand and easier to upgrade for me.

I didn't really took time to understand browserify, just enough to get me working, and I was an inexperienced JS developer at that time, which may explain why my first solution was hacky. But I still believe Webpack's architecture allows a cleaner and more understandable solution.

I prefer browserify because of its emphasis on node compatibility, first and foremost. I think this narrower scope is a strength because as a result, browserify is super simple to use, works without config, and has a surprisingly small, readable implementation. Seriously, read the browserify source.

Browserify also has code splitting

https://github.com/substack/factor-bundle

and hot module reloading

https://github.com/AgentME/browserify-hmr

Browserify is so much easier to understand and interact with, I'm sticking with it as well.

I've been a huge fan but the fact that it's very less opinionated enabled me to ruin my build workflow too often. Now a happy webpack user.

What's needed for Webpack 2: better documentation.

I strongly agree. I had to set up a React application not so long ago and the Webpack docs were completely useless. I ended up following a step by step guide made by someone else, which was really easy to follow and reason about: http://survivejs.com/webpack_react/developing_with_webpack/

Indeed! I gave up trying to configure it to load files relative to the root and just lived with all the import '../../../lib/compents/...'.

I just tried the new beta and – surprise – it works!

I still think the structure of, say, Grunt is much nicer to work with – it's just code and easy to understsand & modify. Webpack has what must be the most awkward configuration file format currently in use.

The website also looks like it's from the late 90ies, but I guess that's not too important.

Apparently, it produces better output :(

This was definitely confusing at first for me, too, but with a little work, you can clean up your imports/requires with just a few lines: https://github.com/tobz/scryer/blob/master/webpack.config.js

Note the resolve section. I have mine rooted at either app or node_modules, and I have some basic extensions set up. This lets me require something like 'components/CardBinder', which ends up then mapping to 'app/components/Cardbinder.jsx'.

It ends up working nicely and lets me forget about precisely what type of thing I'm importing, instead focusing on the fact that I'm simply importing some resource, period.

You can use a subfolder node_modules for using simpler paths (such as "components/something" instead of "../../components/something/index.js").

For example, if your entry point is in "/src/application.js", it can require('components/something') from folder "/src/node_modules/components/something". And that works in native Node, Browserify and Webpack, so you're not tied to a specific build tool.

Any module in /src (and subfolders) first searches for modules in "/src/node_modules", but can still also load thirdparty npm-installed modules from the root "/node_modules".

I made my way through it, but in the end I went with JSPM because of the ES6 imports, and the fact that it handles installs from NPM and automatically adds it to the dependency list for you.

It feels much more seamless than webpack.

Hm, I'm not sure about having to pull in a Promise polyfill to support code splitting (`require.ensure()`) in IE11... If I'm already using a promises library from X, would it be possible to somehow instruct webpack use that? Does that make sense? Am I missing something?

You would have to make the Promise object from your choosen promise library global before any calls to require.ensure.

global.Promise = global.Promise || require('promise-pollyfill');

Something like that in your entry file.

For me the big thing in this version is tree shaking. I think it will change usage of JS stuff more than most people think. For example, I will use Cycle more because currently I feel bad importing all of RxJS for my toy projects.

has anyone used systemjs + jspm here ? I inherited a codebase using jspm (due to the override registry system that works great with legacy javascript packages - like Handsontabe) and am wondering about webpack.

I regularly use JSPM (with systemJS) for new projects, and I've liked it a lot.

Back when webpack first came out, I struggled a little bit with figuring out what it actually did. While I understand now, I am not why I would want to (or you) switch from JSPM to webpack. I don't see any features that webpack has that JSPM doesn't (and JSPM offered ES6 support well before of course, with babel on by default).

I like to use JSPM because of how relatively easy everything fits together -- and how straightforward it is to use and configure.

For those not familiar, JSPM is a package manager, module bundler, and module loader all in one for javascript applications.

This means you can:

  jspm install <package>

And JSPM will look in NPM/Github (and it's possible to add registries, like bower) for stuff . That's the package management facet.

  jspm bundle-sfx js/main dist/build.js

Bundle your code all together, and drop it in a file

  <import src="system.js">
  <script>
    // set our baseURL reference path
    System.config({
      baseURL: '/app'
    });

    // loads /app/main.js
    System.import('main.js');
  </script>

Load your modules on the fly like you would with something like RequireJS.

As you may have guessed, JSPM relies on SystemJS (https://github.com/systemjs/systemjs) internally for some of the features above.

This video really opened my eyes to what it could do: https://www.youtube.com/watch?v=iukBMY4apvI

well i like jspm, but as others have mentioned - it is too slow. is there a way to compile all the dependencies and cache-buster-fingerprint them ? I serve my app statically using nginx and cloudfront.

What's your full build/bundle time like? May be faster to just bundle the parts you need and build them (and use the compiled output). Also ensure caching is enabled for the stuff you want to cache (deps, I assume).

Cachebusting is possible with systemjs. Looks like this project is a good start:

https://github.com/stealjs/cache-bust

Here's a quick-n-dirty fix for this same problem when working with Aurelia:

https://github.com/aurelia/framework/issues/94#issuecomment-...

Here's where SystemJS devs are discussing adding cachebusting:

https://github.com/systemjs/systemjs/issues/172

i was looking at the last issue. it seems inconclusive - I like to serve my js from CDN, so this is very very important.

what is your opinion of webpack in general though ?

Ahh unfortunately I don't one worth sharing -- I've only used webpack once, most other projects (big or small) I've worked on have used RequireJS, JSPM, or Ember CLI.

Also, please look at the other responses, bundling deps seems to be the definitive answer to how to speed up JSPM. Though of course your cache busting issue is separate.

so im a little confused. coming from the Rails world I thought cache busting was pretty fundamental.. especially if you want to use CDN.

Is this not baked into every build tool out there ? How does one take care of caching while serving assets .. or is the general philosophy of JS right now around SPA (so dont care to cache) ?

Caching is definitely important for front end tooling, but it depends on which tooling you're having perform the job. It is also generally considered a deployment worry. Cache busting can be implemented in various ways-- by using a templating language (ex. ERB), by using a build tool like grunt/gulp, by using you JS bundler, or by using your module resolver (in the case that the bundler and resolver are not the same entity).

JSPM just doesn't take a built-in stance on it (as of now, as I noted there is a ticket to get it included), but it certainly is configurable enough to allow you to add cache busting (by changing the loader). Not trying to apologize for JSPM -- it would certainly be better if they had some sort of cache busting option that was easily available and obvious.

I think the thought here is that when you're ready to push to production, and you build your actual bundle, you name that file whatever you need to to bust caches.

It is pretty slow, but I'm guessing that's from the Babel compilation.

I ended up compiling the 3rd party dependencies into a single bundle, then letting JSPM run only on my app's code.

Gulp-rev-all (https://github.com/smysnk/gulp-rev-all) works well for me.

are you using this with systemjs ? can you point out how ?

Well, I use SystemJS to build a stream of in memory files and pipe them to gulp-rev-all. My gulpfile is a bit complex but feel free to use it as reference: http://pastebin.com/zgBsx7Zj

We are using jspm on an inherited codebase that was concatenated "by hand" with Rails' asset-pipeline (it has lots of old libraries and the overrides are very good to handle them).

What we hate is jspm is extremely slow in development for us. There are two main causes:

  - The amount of xhr. This is solvable with http2's server push (but
    our dev server is in Ruby, and there's no http2 webserver yet).
  - Apparently jspm doesn't cache the result of Babel's compilation,
    so for each page refresh every file has to be recompiled again.

We will look at Webpack2 when it's released, if it allows us to use these legacy libraries and wins us some development speed we will not look back.

Do you have cache disabled?

Also, how long does your actual bundle time take? For small projects, I actually get away with just triggering the bundle command when appropriate files in the project change. I highly doubt it would work for you, but if you're spending 10 seconds waiting for stuff to come in over the network, and your bundle command runs in 5, you could just do that instead, and actually work with the bundled code (and generated source map)

Looks like I'm not the only one who thinks it's sometimes a good idea: https://60devs.com/optimizing--default-jspm-workflow-with-gu...

I think JSPM should stress the part about bundling. It's the second person that I see who says "JSPM is slow" and the reason behind this slowness is that they didn't bundle the files or bundled them incorrectly.

We do the same in our project: we bundle all the 3rd party libs when they change, so only our own code gets retranspiled on each page load. During deployment, we bundle all the JS in a single bundle (which is good for us, as we don't have too much JS in that project).

Any chance you can go into detail how you bundle your 3rd party dependencies separately? I have tried that, without much luck.

For me it's like this:

> jspm bundle app//* - [app//*] js/tmp/dependency-bundle.js --inject --no-runtime

That tells JSPM to bundle everything except your application if your app lives within the app/ directory.

> jspm bundle babel js/tmp/bundles/babel.js --inject --skip-source-maps --minify

This tells it to bundle the Babel dependencies which aren't considered in the above.

Using bundle arythmetic.

jspm bundle src/app.js - src/[/*]

This will tell jspm to bundle src/app.js with all its dependencies, excluding everything in the src/ directory. This will result in JSPM bundling only your dependencies.

You should check out StealJS which is a fork of JSPM[1]. The biggest difference between StealJS is that it uses NPM so you don't need a separate package manager tool. Aside from that, we have built in hot module swapping so dev can be really fast (less than 200ms per change usually). Also on the roadmap is caching using Service Workers.

[1]http://stealjs.com/

We solved this with https://github.com/jackfranklin/jspm-dev-builder

It's so fast now.

SystemJS is dog slow if you load all your JS upfront. When mostly lazy loading, SystemJS performs reasonably, at least in my case.

I'm using SystemJs + JSPM and it's awesome. I previously made use of bower + requirejs. I love how JSPM automatically populates the config.js file so I can start importing whatever I installed straight away. SystemJS loads pretty much any module format so it was easy to use AMD modules while I was migrating to CommonJS. I recently moved over to ES6 modules without having to touch my SystemJS/JSPM config. I've not really looked into Webpack. It seems to be more popular than SystemJS. When I was considering it, the docs were not that great.

we looked at jspm and switched to webpack. detailed comparison here: http://blog.dripstat.com/why-we-switched-from-jspm-to-webpac...

I left a comment under your post on reddit. For us, JSPM is fast enough and we don't have to run a second server just to serve assets.

And, excuse me for saying that, but I found your post lacking in substance. Writing "It's super slow, we've tried everything" doesn't show us about what you've tried and with a detailed explanation maybe the thousands of eyeballs who saw that post would be able to help you find the problem you had. ;)

https://www.reddit.com/r/javascript/comments/42ozl3/why_we_s...

hey thanks for that!

we are serving our JS files as static assets behind nginx - we dont run nodejs on the server. does webpack allow you to create static assets (htmls,css,js) and serve them ?

the big issue is of course the fact that some libraries (Handsontable) are coming from github and are not on npm. is it possible to use them - with overrides,etc. ?

well in production u can make bundle from both. the article talks about how development is super slow in jspm since files are loaded individually. yes you can add dependency to github projects with jspm

I'm really curious about the decision to support es6 modules here. Seems like Webpack is stepping into Babel's territory, but I'm not sure to what end?

Huh, they've pulled es6 compilation in, away from babel?

It's early in the morning here so my pre-coffee brain might be terrible, but did they say which compilation engine they were using for es6?

ES6 modules support are now baked into Webpack, which makes sense because that's supposed to be it's primary concern. Any other feature you'd still need to use Babel.

Yeah I saw that, I was more curious as to whether they had said anything about using a pre-existing compiler, or if they had built their own.

I wish Node supported ES6 modules without transpilation as well

For people in corporate environments that can't run webpack/browserify are there any standalone tool alternatives?

Is tree shaking still planned for this version?

Yeah, it's in there.

http://www.2ality.com/2015/12/webpack-tree-shaking.html

I tries cycle.js the other day and had to use some webpack.

Seems like npms default webpack Version is some 2.0 beta?!

Somehow requires in scoped modules didn't work with it ans I searched about n hour for an solution till I saw that the webpack devs seem to consider a beta a good 'default' Version....

Going back do 1.12.12 helped.

I love npm D:

It may have been temporary because right now the default version it installs is 1.12.12