Getting Started with Webpack 2 • Hacker News Board

Re: Getting Started with Webpack 2

#41

Post by shados » Wed, Nov 02, 2016, 2:41 PM UTC

allendoerfer wrote: post #15

TeffenEllis wrote: post #11

Earlier quoted context omitted.

I found the inclusion of Yarn in this tutorial to be misplaced. Adding another step to what is already considered a complex library feels unnecessary. Maybe the author is trying to make Yarn a trend?

> Maybe the author is trying to make Yarn a trend? The JavaScript community makes me a cranky old man, because yarn is even a very good idea and solves actual problems. Still that was the point in the article where I thought "fucking JS hipsters". No time to play with tooling, when there is actual work to do. Especially with other people in your team, whose time costs actual money, I think standardization of dev envi…

Gulp and Grunt were essentially wrong. Using a task runner as an asset pipeline makes no sense. A lot of things, like doing incremental compilation of Sass takes 100+ lines of Gulp crap to do, while it's the default in webpack.

Browserify was nice for simple cases, but getting it to do what's needed in a large, real world application was really difficult. Lately it has a lot of those features, but when Webpack became popular, it just didn't.

I started using Webpack after doing a length cost/benefit analysis and settling on.....gulp + browserify, because WebPack looked too complicated and people in the team had experience with browserify. After a week of trying to get it to do what we needed, I tried WebPack again and did it in an afternoon. That's when we switched.

Re: Getting Started with Webpack 2

#42

Post by vladimir-y » Wed, Nov 02, 2016, 2:41 PM UTC

kozak wrote: post #20

Webpack 2 is so awesome that I'm really confused why haven't they released it as a non-beta yet. It's way past MVP and has more than enough quality for a non-beta. It looks like the maintainers want it to get perfect and release it "when it's done", and that is so wrong.

Releasing in beta is not wrong, there are many really needed by default plugins and loaders that are supposed to work well with v2, so some time is needed for the transition period.

Re: Getting Started with Webpack 2

#43

Post by shados » Wed, Nov 02, 2016, 2:43 PM UTC

TeffenEllis wrote: post #10

Now that Webpack has tree shaking, are there still reasons to use Rollup?

Webpack still uses module wrappers, so tree shaking is mediocre in it (and I don't know if its still the case, but in some situations Webpack used to make the bundle LARGER when tree shaking was enabled).

The way we're looking at it, you use rollup to pre-bundle libraries where you want all of the dependencies inline and use tree shaking to make those as small as possible. You then consume rollup's output from Webpack, thus making dev time builds much, much faster and the resulting output super small.

Re: Getting Started with Webpack 2

#44

Post by vladimir-y » Wed, Nov 02, 2016, 2:47 PM UTC

shados wrote: post #41

allendoerfer wrote: post #15

Earlier quoted context omitted.

> Maybe the author is trying to make Yarn a trend? The JavaScript community makes me a cranky old man, because yarn is even a very good idea and solves actual problems. Still that was the point in the article where I thought "fucking JS hipsters". No time to play with tooling, when there is actual work to do. Especially with other people in your team, whose time costs actual money, I think standardization of dev envi…

Gulp and Grunt were essentially wrong. Using a task runner as an asset pipeline makes no sense. A lot of things, like doing incremental compilation of Sass takes 100+ lines of Gulp crap to do, while it's the default in webpack. Browserify was nice for simple cases, but getting it to do what's needed in a large, real world application was really difficult. Lately it has a lot of those features, but when Webpack became…

> Gulp and Grunt were essentially wrong.

They were not wrong, but they do a general automation (and sometimes it's needed), just a task runners and a wrong thing was to use them for web building automation collection scattered over the internet stuff together into the complex framework. So every team or project had own framework, which means no standard, and that's a bad thing. Webpack allows to defined a needed behavior in a kind of declarative way since it has a structure.

Re: Getting Started with Webpack 2

#45

Post by vladgur » Wed, Nov 02, 2016, 2:54 PM UTC

We have experienced issues getting sourcemaps support to work in Webpack 2 and had to use Webpack 1 instead. Lack of sourcemaps is a deal killer for us and for any major application IMHO. Has anyone experienced the same and has this been resolved?

Re: Getting Started with Webpack 2

#46

Post by Sacho » Wed, Nov 02, 2016, 3:02 PM UTC

neals wrote: post #9

I currently use gulp and, over the yars, have found many ways to do my own parsing and smart caching and stuff over, like checking and bumping version numbers, conditional compiling, caching assets etc. I'd hate to loose all that, but I do see the advantages of Webpack. How much control do I have with Webpack though? Can I still write my own hooks?

Why not use them together? Bundle your assets with gulp and bundle your code with webpack. You've already had to solve the problem of linking from code -> assets, which is what webpack solves by bundling both.

Re: Getting Started with Webpack 2

#47

Post by jagthebeetle » Wed, Nov 02, 2016, 3:24 PM UTC

Has anyone played with Bazel/Closure?

You get dependency management (resolution, pruning) for free from Closure and declarative build targets from Bazel. (Including dependencies on other targets, e.g. non-module-bundle.js)

To be fair, I don't think the (publicly) available rule set grants parity with webpack, but the syntax is a lot less gross and the concepts have been there from the start.

(Re gross: Instantiation in a config file?)

Re: Getting Started with Webpack 2

#48

Post by askAwayMan » Wed, Nov 02, 2016, 3:48 PM UTC

vladgur wrote: post #45

We have experienced issues getting sourcemaps support to work in Webpack 2 and had to use Webpack 1 instead. Lack of sourcemaps is a deal killer for us and for any major application IMHO. Has anyone experienced the same and has this been resolved?

Which version of the beta? We're using beta 25 currently with babel and source map support.

Re: Getting Started with Webpack 2

#49

Post by whostolemyhat » Wed, Nov 02, 2016, 4:20 PM UTC

tboyd47 wrote: post #34

blowski wrote: post #4

Interestingly, things seem to be settling down in the JS community. In the past, every time a library lacked a particular feature, the community suddenly abandoned it. At the same time, every new version release had all sorts of horrible breaking changes, that made upgrading a very scary task. Now, the JS community seems to be thinking more about stability and backwards compatibility. That's very welcome, at least fr…

I'm still skeptical. Webpack is one of the saner ones. Many JS libraries are still doing break-everything major version releases- Babel and Angular come to mind.

That's what a major version is supposed to signify though, isn't it? Most JS/NPM-based projects use semantic versioning, so a major version update means breaking/backwards-incompatible.

Re: Getting Started with Webpack 2

#50

Post by octref » Wed, Nov 02, 2016, 4:49 PM UTC

thelarkinn wrote: post #24

kozak wrote: post #20

Webpack 2 is so awesome that I'm really confused why haven't they released it as a non-beta yet. It's way past MVP and has more than enough quality for a non-beta. It looks like the maintainers want it to get perfect and release it "when it's done", and that is so wrong.

I can understand your concerns but we made a promise early on that we wouldnt release v2 from beta until our MVP docs milestone is complete. We are just around 90% completion ( http://github.com/webpack/webpack.js.org/milestone/1 ) After that we will release v2. Help always wanted! <3

Can you please add some documentation for sourcemap and debugging to the doc?

WP 1's sourcemap doc is confusing as hell and WP 2's doc just copied that over. I imagine debugging un-transpiled code with sourcemap is one of the most common use-cases.

And I'm not alone if you look at the disqus of WP's doc[0] and a blog by @bebraw[1], one of the guys running webpack.js.org.

I even opened an issue[2], I hope it can make into your MVP.

[0]: http://survivejs.com/webpack/developing-with-webpack/enablin...

[1]: https://webpack.github.io/docs/configuration.html

[2]: https://github.com/webpack/webpack.js.org/issues/273