Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Webpack 2, RC 7

github.com

Post reply on HN
Print view View original

11–20 of 28 posts

Re: Webpack 2, RC 7

#11

Post by sametmax »

hughes wrote: post #4
ZenoArrow wrote: post #2

What features does Webpack 2 offer over Webpack 1?

My favorite change is how configuration has been clarified. For example, see how loaders are configured now - instead of using a giant string delimited by special characters like this: 'css-loader?modules-true!postcss-loader!sass-loader' Loaders are configured with an ordered list: [ { loader: 'css-loader', options: { modules: true } }, { loader: 'postcss-loader' }, { loader: 'sass-loader' } ] It takes up way more sp…

I still wonder how come the first syntax was considered a good idea in the first place ?

Figuring how to configure webpack 1 (haven't tried 2) is crazy, and I don't understand how people able to construct such a complex tool that is currently unique on the market, and works so well, managed to design a conf settings that badly.

Re: Webpack 2, RC 7

#12

Post by boubiyeah »

Vevolut wrote: post #6
jagger27 wrote: post #5

Earlier quoted context omitted.

Seems like the headline feature is tree-shaking to remove unused files.

Except in my experience (and others as well) the tree shaking hasn't been working.

Strange, I have it working with rc3. I have an ES6 module exporting tons of Array utils. I definitely see the build size fluctuate depending on whether I import 1, 2, etc of these util functions, whether with webpack 1 (or most bundling tool apart from rollup) I would pay the entire file's price upfront.

Re: Webpack 2, RC 7

#13

Post by k__ »

lommaj wrote: post #9
ZenoArrow wrote: post #2

What features does Webpack 2 offer over Webpack 1?

System.import split-points for code splitting, generates bundles with dependencies for lazy loading by route (automatically code split react router routes). Should make progressive web apps and optimization easier.

yes, best feature.

before you had to use systemjs and jspm or something.

Re: Webpack 2, RC 7

#14

Post by dictum »

sametmax wrote: post #11
hughes wrote: post #4

Earlier quoted context omitted.

My favorite change is how configuration has been clarified. For example, see how loaders are configured now - instead of using a giant string delimited by special characters like this: 'css-loader?modules-true!postcss-loader!sass-loader' Loaders are configured with an ordered list: [ { loader: 'css-loader', options: { modules: true } }, { loader: 'postcss-loader' }, { loader: 'sass-loader' } ] It takes up way more sp…

I still wonder how come the first syntax was considered a good idea in the first place ? Figuring how to configure webpack 1 (haven't tried 2) is crazy, and I don't understand how people able to construct such a complex tool that is currently unique on the market, and works so well, managed to design a conf settings that badly.

> I still wonder how come the first syntax was considered a good idea in the first place ?

I think it came from RequireJS, probably intended for one-off usage (e.g. a single require that requires a certain loader)

Still a bad idea, though.

http://requirejs.org/docs/plugins.html (Jan 2011: https://web.archive.org/web/20110109084245/http://requirejs....)

Re: Webpack 2, RC 7

#15

Post by thelarkinn »

Thanks whoever posted this article!!! On behalf of the webpack core team, we thank everyone who's been using webpack 2 since beta, we are at the finish line for getting final release. :) stay tuned

Re: Webpack 2, RC 7

#16

Post by thelarkinn »

sametmax wrote: post #11
hughes wrote: post #4

Earlier quoted context omitted.

My favorite change is how configuration has been clarified. For example, see how loaders are configured now - instead of using a giant string delimited by special characters like this: 'css-loader?modules-true!postcss-loader!sass-loader' Loaders are configured with an ordered list: [ { loader: 'css-loader', options: { modules: true } }, { loader: 'postcss-loader' }, { loader: 'sass-loader' } ] It takes up way more sp…

I still wonder how come the first syntax was considered a good idea in the first place ? Figuring how to configure webpack 1 (haven't tried 2) is crazy, and I don't understand how people able to construct such a complex tool that is currently unique on the market, and works so well, managed to design a conf settings that badly.

Ironically the biggest challenge is involved with connecting a very declarative under the hood plugin architecture, to a more imperitive fluid configuration for users. We would love all the great ideas we can get!

Re: Webpack 2, RC 7

#17

Post by [deleted] »

sametmax wrote: post #11
hughes wrote: post #4

Earlier quoted context omitted.

My favorite change is how configuration has been clarified. For example, see how loaders are configured now - instead of using a giant string delimited by special characters like this: 'css-loader?modules-true!postcss-loader!sass-loader' Loaders are configured with an ordered list: [ { loader: 'css-loader', options: { modules: true } }, { loader: 'postcss-loader' }, { loader: 'sass-loader' } ] It takes up way more sp…

I still wonder how come the first syntax was considered a good idea in the first place ? Figuring how to configure webpack 1 (haven't tried 2) is crazy, and I don't understand how people able to construct such a complex tool that is currently unique on the market, and works so well, managed to design a conf settings that badly.

[deleted]

Re: Webpack 2, RC 7

#18

Post by [deleted] »

sametmax wrote: post #11
hughes wrote: post #4

Earlier quoted context omitted.

My favorite change is how configuration has been clarified. For example, see how loaders are configured now - instead of using a giant string delimited by special characters like this: 'css-loader?modules-true!postcss-loader!sass-loader' Loaders are configured with an ordered list: [ { loader: 'css-loader', options: { modules: true } }, { loader: 'postcss-loader' }, { loader: 'sass-loader' } ] It takes up way more sp…

I still wonder how come the first syntax was considered a good idea in the first place ? Figuring how to configure webpack 1 (haven't tried 2) is crazy, and I don't understand how people able to construct such a complex tool that is currently unique on the market, and works so well, managed to design a conf settings that badly.

[deleted]

Re: Webpack 2, RC 7

#19

Post by [deleted] »

sametmax wrote: post #11
hughes wrote: post #4

Earlier quoted context omitted.

My favorite change is how configuration has been clarified. For example, see how loaders are configured now - instead of using a giant string delimited by special characters like this: 'css-loader?modules-true!postcss-loader!sass-loader' Loaders are configured with an ordered list: [ { loader: 'css-loader', options: { modules: true } }, { loader: 'postcss-loader' }, { loader: 'sass-loader' } ] It takes up way more sp…

I still wonder how come the first syntax was considered a good idea in the first place ? Figuring how to configure webpack 1 (haven't tried 2) is crazy, and I don't understand how people able to construct such a complex tool that is currently unique on the market, and works so well, managed to design a conf settings that badly.

[deleted]

Re: Webpack 2, RC 7

#20

Post by frio »

Vevolut wrote: post #6
jagger27 wrote: post #5

Earlier quoted context omitted.

Seems like the headline feature is tree-shaking to remove unused files.

Except in my experience (and others as well) the tree shaking hasn't been working.

The problem with tree-shaking is that it's recursive -- every module has to do it properly, and at the moment, I'd wager most frontend modules in NPM don't.

If I responsibly say `import { map } from 'lodash'`;, but (say) my frontend rendering library says `import _ from 'lodash'; _.map(things, func);`, then unfortunately, transitively, I'll still get all of lodash.

Post reply on HN