Webpack: The Missing Tutorial | Hacker News Reader

Webpack: The Missing Tutorial

github.com

97 pointsshekhargulati42 comments

There's no shortage of Webpack tutorials, and this one looks fine so props to the author. However, the best Webpack tutorial I've seen for beginners (and experts!) is this video that explains it from a conceptual point of view[1], explaining what exactly Webpack does and not just how to use it:

https://www.youtube.com/watch?v=WQue1AN93YU

[1] This thread's post does this too, which is awesome!

That video was really helpful, thanks.

I tweeted “A 250 KB render-blocking bundle.js in <head> which also includes all the CSS and SVG files?” in response to that video, and didn’t get a good answer. If anyone here wants to respond, I’m interested to know more :)

If that bothers you, you can make the entry file be a tiny do-nothing loader module that dynamically loads other modules when the page is ready. Chunking files in this manner is trivially easy.

You can also separate CSS and SVGs and whatever else you want into external files using the external file plugin.

Finally- there's no reason you need to load the bundle in <head>.

Hm, a big render-blocking bundle in <head> seems like such an obvious anti-pattern. “If that bothers you” makes it seem like I’m nitpicking, but this is a huge issue, I think.

If your entire app is rendered by JavaScript then it doesn't matter.

also you don't need to make it a blocking script tag in your <head>, you could load it at the end of <body>, it doesn't prescribe anything.

I may be in the minority, but I don't want to watch videos when learning how to use things. I want written tutorials that I can refer back to when necessary.

My big problem with tutorials in JS-land is that so many seem to assume too much background knowledge in the reader. Webpack has been no exception; as someone who generally doesn't do front-end stuff I have really had to dig around to find out how things actually work and find things like lists of valid options for different sections.

I spent this morning watching functional js videos - it was great. Will be doing more of that in the future.

Honestly this might sound rude but a lot of written tutorials/blog posts in JS are made by people with good intentions but not a lot of experience or expertise, so they end up hand-waving a lot or just not explaining things right. The linked video is by a long time, well-respected frontend developer.

I love videos to learn... but as someone working for a company that don't allow any videos through the firewall... written posts are also useful.

Odd that 7 years later, and JS build tools still don't match the level of optimization you get in Closure Compiler.

IMHO, the speed of the build tool is less of a priority than the speed of the code it produces. You pay the cost of the build tool mostly in integration tests or production builds but shouldn't pay it during development.

However your users pay for inefficiencies times the number of times the app is loaded. The state of JS tooling is woefully behind other languages and IMHO still behind the state of the art 5 years ago. Any non trivial sized app for example will require global dead code analysis and method and field level pruning as your dependencies grow over the lifetime of your app, all apps tend to bloat from unneeded code pulled in.

Ironically it exists in compile-to-JS languages. I think ClojureScript uses Closure (naming accident), but the PureScript compiler does dead-code analysis and removal. Elm doesn't yet, but it's on the roadmap and partially finished.

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.

By "user" you mean developer, but you're trading off compile time pain for you, and saddling everyone else with downloading an extra 100kb, which on mobile networks or in developing countries is unforgivable.

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.

Closure Compiler also has pluggability, however the plugins must be written in Java, which is a downside for the JS ecosystem. For example, asset packaging wise, there's stuff like GSS Compiler integration, where goog.getCssName('foo') is translated into an obfuscated short className, while the GSS compiler optimized, prunes, and combines GSS.

GWT was the same way, asset packaging was a core feature even in 2009. For example, it would automatically compile CSS, UI templates, and images, auto-optimizing them, and auto-sprite-sheeting everything, while packaging things into as few HTTP requests as possible.

The real issue is that to do this in a safe way for JS requires coding conventions be adhered to, or the adoption of TypeScript and annotations. Closure's advanced mode will break JS that tries to get too fancy with dynamism.

    require('style!css!../css/style.css');

What is this I don't even.

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.

In case it was really a question: this passes `../css/styles.css` into the css loader then the style loader when `require`-ing. Normally this is setup in a webpack.config so you can just do `require('../css/styles.css')` normally

Be careful jumping into webpack and getting it to load everything (JSON, style sources, HTML partials (!)) with require/import. It can wreak havoc with your testing.

Couldn't agree more. Also, if you want server side code to work without bundling you'll want to be careful there too.

I have css requires restricted to the client entry file to keep other modules testable/usable server side otherwise.

I hate to say it (I've enjoyed the benefits of using webpack on a few projects now) but I feel like it's all a bit too late for webpack (2).

Rollup or Brunch seem to offer a preferable alternative with speed, ease of use, and optimisation.

What is Rollup vs Brunch? Coming from someone who just understood why we have Webpack vs Browserify.

They're both alternative build tools

Rollup is very similar to Webpack but is architectually different to allow it to optimise assets further and faster.

Brunch has actually been around since before Grunt, it's just not marketed. It works in very simple fashion, just install plugins via npm and start using them, no need to edit configuration files (unless you have very specific requirements).

I would consider Rollup as the new hotness, building upon the success of other tools and starting from a better position to create an optimised tool.

Brunch is a long time standing tool that does a job very well and if your project doesn't require any special configuration or architecture it's so easy to use (it can be configured though).

How fast is Brunch and Rollup compared to Webpack? Is there something similar to Webpack dev server [0] in Rollup?

[0] - https://webpack.github.io/docs/webpack-dev-server.html

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

Thank you for the link. This sounds scary though.

> Webpack will perform less-favorably compared to Rollup as the number of modules increases.

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

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.

Google Chrome developers just made a video about it: https://www.youtube.com/watch?v=OhPUaEuEaXk

To clarify because I nearly skipped over this video thinking it's about those two:

The video actually explains what browserify/webpack do, as well as what rollup brings to the table. I don't think it covers brunch, however -- maybe I missed it.

Make sure to watch the video with annotations. There are a lot of related links and clarifications.

Brunch is purely an asset build tool. Almost zero-config, very fast, older than Grunt, used for Elixir's Phoenix framework to deal with frontend so got a bit of traction recently.

And recently introduced hot reloading support.

Hah, I hear you! It's barely been 2 month that I got started with Webpack/React. Gave me a pretty hard time, learning all it's quirks... specially the way it handles CSS. And seems there's something new on the block already!

Considering the React community has settled on Webpack and from what I hear so has Angular 2, I think it's here to stay for a while.

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).

I agree, Brunch is infinitely easier to use. It's used as the default asset compilation tool for new Elixir Phoenix projects.

Interesting, I've pretty much entirely replaced brunch with webpack in my projects over the last few years, and found it much easier. The larger adoption and active community made it a lot easier to move forward when encountering webpack issues; surely that's thanks to the rapid spread of react, but if it means I spend less time wading through build problems in my non-react projects then that's fine with me.

What Sort of problems did you come across with Brunch that Webpack solved for you?

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)!!!

The rate of new JavaScript build tools is absolutely ludicrous.

I get the impressions javascript devs can't google, the just write a new version of whatever tool they need.

Reply on news.ycombinator.com