Live data from Hacker News

What's New in Webpack 2

gist.github.com

51–60 of 71 posts

Re: What's New in Webpack 2

#51

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 en…

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 Webpac…

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

Re: What's New in Webpack 2

#52
post #41

What's needed for Webpack 2: better documentation.

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 :(

Re: What's New in Webpack 2

#53
post #26

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?

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

Something like that in your entry file.

Re: What's New in Webpack 2

#54
post #41

What's needed for Webpack 2: better documentation.

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 loo…

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.

Re: What's New in Webpack 2

#55
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.

Re: What's New in Webpack 2

#56

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 en…

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 Webpac…

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)

Re: What's New in Webpack 2

#57
post #51

Earlier quoted context omitted.

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 Webpac…

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 so…

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.

Re: What's New in Webpack 2

#58
post #41

What's needed for Webpack 2: better documentation.

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 loo…

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.

Re: What's New in Webpack 2

#59

Earlier quoted context omitted.

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…

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.

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.

Re: What's New in Webpack 2

#60

Earlier quoted context omitted.

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…

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.

Post reply on HN