Webpack 2.2 – Release Candidate
medium.com
medium.com
That's good. It's kinda funny how this is a very frequent pattern: Build something full of magic and, as you grow more mature and hit pain points, end up removing the magic.
I've had a very similar experience in my career so far as a dev. My code used to be full of magic, auto-guessing things based on how methods are named, etc. I've moved away from that, it wastes more time than it saves.
Anyone else with the same experience?
I always felt indifferent about it, and the config style felt a bit like Revenge of Grunt, but after using it and especially after reading your tweets and responses to issues on github, I finally understood why Webpack is so popular.
I know project maintainers often work hard for little reward, but you're consistently gentle and helpful with beginners and people with complaints about Webpack. Thank you.
This goes to more than just you, but please always feel welcome to reach out.
Mostly due to less magic, tbh
The thing about magic is it's just as mystical when it breaks as it is when it works. That's why it's magic.
That's the most concise way of describing the problem I've seen yet. I'm stealing that. Thank you!
I would infinitely prefer to use JS tooling over Java's in general so maybe that's not saying much.
Webpack is practically a blank slate.
Not to say there's anything wrong with tutorial-style documentation in and of itself. However, it becomes problematic when it is the only documentation.
Then you just find yourself digging around in source code because the "It's easy, simple and magic!" style of documentation turned out to be woefully inadequate, if not actively confusing.
I guess one reason is that the tooling is there to bring in the magic in the first place.
The other could be that tools being created because of the needs of a specific workflow and the magic is there because authors just wanted to have something working, then it got popular and now people want to use it in all sorts of workflows.
Speaking of magic or trying to be too clever with your code reminds me of the Grep Test [0], which I always try to conform. In the end it's not fun forcing others to deal with your magic. Remember: code is read way more often than it is written, so don't be lazy to type a bit more — help others.
Hibernate went through this too. I came to prefer myBatis, but going through JPA is nicer. JPA is certainly not less magical than Hibernate though, just the culmination of many years of work in this area.
SQL Alchemy is also nice like this. The magical ORM is built on an extremely robust and well-documented relational database querying library. There's an escape hatch to reality if the magic fails you, always. Can't say that about Hibernate 3—see the HQL/Criteria API madness (again, fixed in JPA).
I went through a very hyper-annotation period with Java. I have since calmed down. I still make annotations, occasionally, but I don't let them be the only route to the work. Always have the annotations help something build a configuration through a standard API, then the work happens against that configuration. You can ditch the annotations if they're a pain that way, or bridge between something else (XML probably) without writing the same code twice.
I learned how to use Webpack but still think it sucks and it's incredibly complicated for what it does for 90% of use cases.
Smart defaults. -Then- let me configure if I need to.
"Can we make smarter defaults"
We support a lot of build targets and are agnostic to library and stack so it's going to be a challenge but with your help and the community I know we can get it done.
webpack-make --scss --hot-middleware --blah
or something, potentially?
Since the core team needs to focus on implementing more opt features like rollup and better top level minification, we left this for a chunk of our contribute team to help design and come up with. Help always wanted!!!
but also please have those discoverable.
I've come to hate the word default because people have a different idea of what it means.
Is it a site default, an app default, per-instance default ...?
Which one applies? Apps should document at runtime what the values are and where they come from.
However I think that if you have a clear model of how everything works you don't need that much magic because building the solution to any particular use case is not really an onerous task in itself.
The experience with Webpack2 is so much better:
- Cleaner documentation
- Saner configuration files:
- It errors out if you add incorrect flags!
- This means that postcss et. al. use config files
- Saner module definitions (now called rules):
- No query flags!
- Actual object support!
If you're thinking of upgrading it's not that much effort given the new documentation, too. Definitely worthwhile, and there seems to be less occasional build bugs using this with newer babel plugins (originally switched because of a crazy stackoverflow parsing a two-deep object).
One word of warning: LoaderOptionsPlugin _may_ mess with "context", so you should always redefine it in each plugin option object.
For example, using PostCSS without a .postcssrc:
// postcss hasn't yet started to use options within rule definitons of
// webpack 2; instead, we use a LoaderOptionsPlugin which provides
// webpack 1 support of options to postcss.
// https://github.com/postcss/postcss-loader/issues/92#issuecomment-251439696
new webpack.LoaderOptionsPlugin({
options: {
// See https://github.com/postcss/postcss-loader/issues/99#issuecomment-248878925 and
// https://github.com/webpack/webpack/issues/3018#issuecomment-248445176
context: __dirname,
postcss: [
require('postcss-mixins'),
require('postcss-simple-vars'),
// TODO: Remove and use css variables (http://cssnext.io/features/#custom-properties-var)
require('postcss-constants')({
defaults: defaults
}),
require('postcss-each'),
require('postcss-cssnext')({
browsers: 'last 2 versions',
features: {
// https://github.com/robwierzbowski/node-pixrem/issues/40
rem: false
},
import: true,
compress: false,
messages: true
}),
require('postcss-nested'),
require('lost')
]
}
})
See, maybe this is the get-off-my-lawn coming out of me but it pains me that that complex setup is the nicest and fastest frontend build pipeline you've had.
Almost a whole decade ago we had pretty simple and straight forward build patterns for frontend. Essentially running the site as is from the VCS was in "debug" mode and you'd write scripts that combines and minifies everything and plugs it right back into the html when you "build" it. And that it was it. Simple and fast.
I'm sure using ES2015, TypeScript, SCSS, handlebars and a million other things that get transpiled, concatenated and minified help with productivity for some people but it just seems insanely overly complex to me especially when half of the examples that show how "simple" many of these technologies are can also be made very simple using standard API calls.
I like things simple. As simple as possible. Webpack is probably not for me but I wanted to provide my own perspective to see if anyone shares it or if I'm more of an outlier.
> Almost a whole decade ago we had pretty simple and straight forward build patterns for frontend.
a decode ago, we didn't really build web apps like today though. The browser landscape was different. The technology was different.. but the most important: the expectation was different. Man, 10 years ago we still had flash.
> [...] help with productivity for some people but it just seems insanely overly complex to me
It is. To be honest, if I'd start today, I'd be super lost too.. but it is a one-time cost/investment to start to gain that productivity.
I think the biggest upside of this whole thing is working at scale in terms of human. Good modularization allows you to achieve this.. in the old school day, that was either a big javascript bundle, or a bunch of them inserted in the pages as global.
My opinion is: if you think you don't need it, don't bother with it. I didn't understand webpack until I needed it. I didn't understand React until I needed it. I didn't understand docker and kubernetes until I needed it. Trying to force yourself to use thing when you don't see the usefulness is counter productive.
> a decode ago, we didn't really build web apps like today though. The browser landscape was different. The technology was different.. but the most important: the expectation was different. Man, 10 years ago we still had flash.
Other than dealing with more browser incompatibilities that we have less of most of my work was still fairly complex web applications. We just didn't have many if any frameworks so depending on the experience of the starting developer you most likely walked into a wall of spaghetti which I understand frameworks can sometimes help even new developers write cleaner code.
Also Flash was amazing back then, heh :)
Meanwhile, I'm working on _another_ site that requires the hybrid approach of SPA for smooth transitions and caching and what not, yet the SEO and first-boot speed of a server-side-rendered site. This (obviously) has a more complicated build 'pipeline' to achieve a more sophisticated feature set.
I've tried using Webpack in its begginings, because React people only talked in Webpack terms, but then switched back to Browserify, which is simple, not magical and straightforward. I tried using Webpack again lately, with the bizarre Gatsby static site generator, and the failures are enourmous. I can't even understand how exactly does a loader work. Gatsby makes forced use of something called webpack-config or something like that, which is just a useless abstraction on top of the already confusing Webpack config.
Please, someone explain to me what does this thing do that Browserify can't.
Nowadays not a lot more, but when it came out it was a revelation.
The key thing to note is that replicating webpack's abilities in browserify takes about the same or more amount of config and boilerplate.
More generally, browserify seemed very Node-focused in attitude and webpack made a lot of design choices particularly for the web. Things like having uglify built in, ability to not just bundle javascript but also other assets (like pictures and css). I bet all these things were possible with browserify, given the right transform, but I liked that with webpack it was the norm. It seemed designed for the problem I had: coding a web app. Browserify seemed designed for "I have this huge node program that i want to port to the browser with a little effort possible".
The main difference was that WebPack bundled it all together so it was all ready out of the box.
webpack.js.org/concepts
Native ES2015 modules support?
Longer story: it's more of a kitchen sink approach that does more out of the box whereas Browserify is more minimal.
Webpack is very config heavy too.
I give Webpack a lot of crap on Twitter about what I see as encouraging bad practices but to it's credit it's developing very nicely.
But if you're happy with Browserify there is absolutely no reason to switch other than tool-chain momentum.
If you want a simple build tool, that works out of the box, you could check brunch perhaps.
For my workflow, I just need ES6 transpile, module bundling, minifying, and auto build with watch for multiple pages. Code split sounds good on paper but I do my grouping of files explicitly anyway. HMR sounds nice but I haven't got hot reload working yet. Manual refresh the page isn't too bad.
I've spent way too much time on configuration and getting the tool chain to work, and less time on developing real feature. Getting really sick of it.
In age of HTTP/2 packing is not recommended anymore but I love so many features of Webpack, are you guys going to adopt to HTTP/2 paradigms?
Great work, thanks!
It's designed to allow you to specify a max and min file size and webpack(2) will create x bundles of those size up to a certain number (if specifies). The advantages are now you are drastically increasing the delivery of your js and other assets but still bundled for opt.
Sokra (Tobias) wrote an article about this research if you are interested!!
https://medium.com/webpack/webpack-http-2-7083ec3f3ce6#.5yca...
Also to see an example of the API usage you can visit our core repo under examples where we explain the trade offs (compression vs cacheability):
https://github.com/webpack/webpack/tree/master/examples/http...
(Side note - I have a complex app but still get ~1sec build times, why the fuss over HMR?)
Also even if you have a fast build, refreshing might require refetching data from a server.
In any case browserify also has HMR and it's great.
If you are using a ton of loaders that aren't v2 ready you may have a more painful experience, you'll have to get familiar with the LoaderOptionsPlugin.
If you're newish to webpack it could be a frustrating experience.
Shout out to the webpack team though, It's an impressive tool.
> * add `import()` as Code Splitting construct. It should be used instead of `System.import` when possible. `System.import` will be deprecated in webpack 2 release (removed in webpack 3) as it's behavior is incorrect according to the spec.
I was under the impression `System.import` would be the new way to do code splitting and hence supersede `require.ensure()`. After further checking, now it seems like the function-like `import()` will be used instead [1], which is better accepted in browsers than `System.import()`.
[0] https://github.com/webpack/webpack/releases/tag/v2.1.0-beta.... [1] https://github.com/webpack/webpack/issues/3098