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.
I find that where there'a magic, there's usually tutorial-style documentation.
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.
This situation keeps occurring especially with tooling.
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.
For me that's one of a reasons that as full-time Ruby/RoR developer I've started learning (& loving) Python. Some time ago I've started to realize that too much is happening under-the-hood in many of the libraries I'm using and somewhat in my applications. After few months Python is much more verbose and readable for me and I don't have dilemma whenever I should I implement certain thing this or that way.
Oh man! That exactly describes my 2016 experience. We spent the entire year working on a project at work. It started off with a lot of magic to make on-boarding other "non-technical" people easier. After the summer we began ditching magic for a simplistic approach.
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.
Definitely. But I have come to appreciate a sprinkle of magic, especially if you can say show how the magic transforms something into something else that happens to be more verbose.
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'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.
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.
Hey Sean — I've been away from JS for a while and I'm just getting back, so I used Webpack for the first time this week.
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.
Well thank you for always being candid and honest with your feedback to us. We really rely on feedback from the community who is ultimately in charge of the direction of this incredibly humbling project.
This goes to more than just you, but please always feel welcome to reach out.
Totally understand, now that webpack 2 is almost out the door, this is one of our top 5 overhauls we want to make.
"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.
Well, as one of the maintainers besides working on core, and loaders/plugins, my role is to rep the voice of all of you to the core team, and also the other way around. Just here to help :)
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!!!
Hah, nice. Sounds like you guys are pretty on top of things :)
Afraid I'm not nearly caught up on webpack best practices to take a good whack at it, hah
I solved this by keeping my Webpack build process in it's own repository, with a JSON file that dictates entry and exit points for builds. When doing a new frontend project, I use git submodules to import my build pipeline and just change a few variables and I'm set.
Yep. That's one of the reasons why I love Redux, and why I don't quite get a lot of the complaints about it requiring "too much boilerplate". I've certainly looked for some ways to be a bit more DRY in using it, but there's also good reasons for having things like action type constants and action creator functions.
The problem with magic - and I think it's the problem in webpack's case - is that magic is often predicated not on a clear model of how things work in your system but just a list of use cases that will be automatically handled without you having to think.
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.
POM is not exactly intuitive, but the configuration directives are at least discoverable. If you're using a decent IDE, all the config options and values work with autocomplete. It's also pretty trivial to generate an archetype for most common needs.
But that's more of a documentation issue rather than an xml/json issue - you could certainly have an xml file without a schema. I think it mainly shows the maturity of Maven vs webpack(which is currently working hard on documenting everything).
I used to wonder what people meant when describing "magic code" but after using a dynamic language MVC framework and seeing how things can be done different ways I have realized that mostly what people mean by that expression is using strings to indicate what code should be called rather than the features of the language. I'm somewhat undecided still on what to think of these sorts of patterns.
I avoid any library that is too magical. If a project asks you to just run this magical tool that will organize your source tree just so, and then it asks you to put your source code for each thing in a certain place, and don't worry about anything, it'll just work (cough cough RoR cough cough), then I'm not interested. Because sooner or later, it won't just work. And then I'll have to figure out what went wrong, which you won't have told us how to do.
Recently moved to this from webpack 1 for both personal projects and work. Webpack 2 combined with Yarn running inside of Docker to automate builds is the nicest (and fastest) frontend build pipeline I've had yet.
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!
Plus tree shaking, code splitting etc. It's way better. Now looking forward to integrating babili within webpack to remove uglify.
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).
> Webpack 2 combined with Yarn running inside of Docker to automate builds is the nicest (and fastest) frontend build pipeline I've had yet.
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.
Go build a simple website and use simple tools. It's that easy - people are still using `cat`, right? I just deployed a site that's just all just one HTML file with inline CSS and JS tags. 'Deploying' is as simple as copying the source files up to S3.
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 was only referring to web applications. Websites I would expect to be pretty simple and straight forward. Simple tools can be used to build both. Simply because you use simple tools doesn't mean you can't create the necessary complexity.
How have you found plug in support? The new features, etc look great, but I'm worried that there will lots of plugins that simply don't support the new version, or only have buggy bleeding edge versions that do....
Also, if you find a plugin or a loader who is struggling to support or catch up, just drop us a message on github or tweet me at @thelarkinn, and myself or one of the other maintainers will offer to help or take over the plugin. We have a whole contrib team dedicated to helping maintain our core org loaders and we are always wanting to keep the ecosystem strong and up to date.
There's `webpack.LoaderOptionsPlugin` which allows backwards compatibility, generally solves the problem.
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')
]
}
})
You can get around this by using a postcss plugin to read from the common config file (.postcssrc iirc) also, but I depend on requires for postcss-constants so couldn't.
This thing is so complicated and so full of magic and options and the documentation is so shallow, I can't find examples, can't get a tutorial that isn't uselessly superficial.
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.
Hey sorry this was your first (or many) experience(s). If I can be of any help, I'd recommend checking out our Concepts section which I authored for first-time users and those trying to understand the overall principles of loaders/plugins.
No that was handwritten by Tobias the original author and I shared it on Twitter a few weeks back. We do have a lot of abstraction and complexity internally. But we like the direction and way it has allowed us to pivot toward and away new/old features.
Webpack has the very useful "chunking" system which is able to figure out common dependencies, and based on how often they are re-used across your app, determine whether they should be bundled separately. It's really good if you're trying to find an optimal balance between the number of files on a page and the cacheability of each one. I haven't seen that feature in Browserify or other module bundlers. Of course, with HTTP/2 server push hopefully a lot of these issues will go away.
That sounds like exactly the sort of magic they are talking about. I'll take predictable over magic any day, in this case it sounds like the sort of decision that's best left to people anyway.
When I switched from browserify to webpack, everybody was using grunt or gulp to trigger full browserify builds on every change. Browserify had watchify, but it was bolted on, buggy, and slow. Webpack had a devserver with incremental builds that just worked.
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".
They are all complicate. I've tried the older Webpack 2.x and got a number of errors. Didn't have time to resolve all of them. Went with the simpler rollup, and be done with it.
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.
Sorry to hear that was your experience, but also glad to hear you found a solution that works. If you do come back to trying webpack, we're happy to help get you up and running. Feel free to reach out on twitter or github @TheLarkInn
That's true, and I'm glad they aren't jumping the gun. Browserify is all about node compatibility, so I'll gladly wait until Node implements ES Module support.
Browserify is not maintained anymore. It's sad, but it simply is out of the competition. Also, chances are you can easily find webpack loaders for your workflow where you would struggle to find an equivalent browserify plugin that works and is maintained.
I'd say that's pretty big.
If you want a simple build tool, that works out of the box, you could check brunch perhaps.
It is hard to find well maintained JS libraries in these days. Thanks a lot for the mature work done here, especially in terms of documentation. So many OS projects launch their new shiny versions in such a rush, they leave their users in darkness for a very long time.
No they didn't. Webpack 2 has been kept in alpha and beta for so long exactly because the documentation was lacking. If anything that fact alone shows a good amount of maturity.
This complaint looks to me about some devs jumping to use the alpha version of v2 and got confused about which version the homepage points to. This is separate and a minor problem which they have fixed anyways.
Their versioning strategy for 2.0 was pretty poor - it hasn't actually had a proper non-alpha/beta/rc yet until now. It was precisely documentation that was holding them back from declaring 2.x as 'stable'
We have a plugin built around the research on HTTP/2 and web perf (which based on the data so far points to bundling still yielding the optimal results) called AgressiveSplittingPlugin.
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!!
webpack is great. HMR and code-splitting are killer features. Only thing that I'm worried about is tree shaking. There are a couple of long standing issues about problems with classes and export all statements. Rollup is missing code-spliting, webpack doesn't do tree shaking well and complains about bundle sizes. Not sure what to do. If somehow rollup could be integrated, that would be perfect.
Not having to refresh which means preserving state. If I have a modal opened and I want to make a change to the modal UI, if I refresh I would have to reopen the modal. With HMR the modal just rerenders.
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.
Thank goodness I decided to bite the bullet last week and make the jump to v2. Upgrade took a while but was rather painless thanks to the great migration guide on the new documentation site.
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.
Reading through the Webpack2 release tags I came across the v2.1.0-beta28 changelog, which mentions:
> * 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()`.
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?