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>
jspm bundle-sfx js/main dist/build.js
<import src="system.js">
<script>
// set our baseURL reference path
System.config({
baseURL: '/app'
});
// loads /app/main.js
System.import('main.js');
</script>
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
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.
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...
It's so fast now.
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...
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. ?
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).
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.
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)
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
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.
https://github.com/substack/factor-bundle
and hot module reloading
Also, make sure to try out atom-typescript by Basarat. It's genuinely amazing and feels like Swift. :)
I have the feeling that those Haskell like type-systems are superior to this whole Java/C# stuff.
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 :(
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.
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".
It feels much more seamless than webpack.
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?
Something like that in your entry file.
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: