thelarkinn

Coming from a no-design-ux background, I never considered this and it would be a perfect issue on our github. Would you be interested in creating it? github.com/webpack/webpack.js.org/issues/new

Thanks for the thoughtful reply. I've created an issue for it so that we can discuss and plan where and what content should be added. https://github.com/webpack/webpack.js.org/issues/416

Also, if you would like to be involved in the discussion or thread, feel free to. We welcome constructive ideas and suggestions.

Have you checked out webpack.js.org/concepts. webpack.js.org is our entire new documentation effort designed initially for first time users.

Take a look and feel free to submit an issue if there are things that are still confusing or you would like to see more of.

We wanted to give influence to those who are involved in open source and contributing to the community. Would be happy to discuss alternative options.

DISCLAIMER: (dupe comment) This was an alpha feature that got leaked that we didn't expect to be circulated. Therefore we don't have UX/UI yet. We would love help and support so PR's, suggestions, issues are all welcome on github.com/webpack/webpack.js.org

Hey!!! This was an alpha feature that got leaked that we didn't expect to be circulated. Therefore we don't have UX/UI yet. We would love help and support so PR's, suggestions, issues are all welcome on github.com/webpack/webpack.js.org

By all means we take PR's as well. Our MVP list is pretty set in stone and we don't want to extend our timeline. However simply by adding the issue to the new docs repo, I'll make sure the information will get prioritized for adding.

Rich couldn't have said better !!!!

Id recommend our newer upgrade guide. https://webpack.js.org/how-to/upgrade-from-webpack-1/

Id recommend our newer upgrade guide. https://webpack.js.org/how-to/upgrade-from-webpack-1/

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

True, which is why we haven't ignore this and are hoping to add features like scope hoisting (and personally I'd love to pass the AST program that webpack's parser creates right in to closure compiler js to see how "advanced" it can compiler) and other features. Because in the end, the api possibilities that webpack provides for plugins makes the tool limitless.

Does anyone find this search results on ISAAC CHOI ironic? (Photo shows google search results with Poker Player for online gambling site as one of the top results).

Wonder where all that money went. ;-)

http://imgur.com/a/bX9po

It's not, in the end load and runtime perf boil down more to what and how much you load up front.

Not the conventional method of using it. Is a legacy syntax, you just require the file and it will be imperitively loaded via your loader chain.

I think closure compiler is the perfect example of how saving extra 100kb is has never been worth the poor user experience. Despite the pain in setting up webpack, the result is an excellent collection of features that goes beyond just JavaScript.

> So, what do you think

This is an interesting perspective! One thing to note is that you never have to import images and other assets into js to express that as a dependency!!

One of the coolest features about webpack is its community plugins such as html-webpack-plugin. For example through html-loader and html-webpack-plugin, you can specify in your index.html _template_ an image src or src set, this also tells html-loader to express those URLs as webpack dependencies allowing you to use image and file loaders!!

Do people often do this? I'm not sure. That's one of our main goals with webpack (2) is to provide education on different ways to approach different scenarios through our new documentation. When you don't let webpack manage all of your dependencies (code and non-code) you significantly lose out on a wealth of features for PWA, and PRPL standards.

So in the end? Maybe I am a bit biased ;) but I definitely disagree with the premise that you let other build tools handle other assets.

Rollup as the new hotness for _libraries_. We know that libraries see a weak point for us as well as runtime overhead for many modules in Webpack bundles, but Rollup is just tackling one challenge and that is js perf. Webpack manages all of your assets (even if they don't get bundled together). Along with a hundred different out of the box features.

Here is a up to date write-up for our proposal and review of performance in our repo https://github.com/webpack/webpack/issues/2873#issuecomment-...

Yes exactly! Out of the box webpack solves a bunch of really complex problems that frameworks or 10tools combined would have to solve (code-splitting, lazy-loading, multiple targets (webworker, web, node, electron, etc.).

Our vision is to be able to integrate as many perf features as possible, (sw-precache, rollup module inlining, a universal generic compressor/minifier for es6).

The margin in size and speed for webpack2 compared to rollup is pretty minimal ~5%. Plus we plan on integrating rollup scope hoisting after we release webpack 2.x (which is stable, however pending the finishing of our documentation)!!!