I think Webpack solves a real problem in the web world, but holy cow is it a pain to configure in large applications. Anyone who has had to maintain a larger (and often dynamic) Webpack configuration knows what I am talking about.
I think Webpack is a step in the correct direction, but web bundlers are still in need of improving.
True. Several times I have resorted to putting random console.log's into the webpack core and it's plugins as the only way to figure out why the configuration doesn't work.
Having just tried roll up, it makes a number of assumptions about your code. I couldn't get React 15.x to bundle correctly with my code at the end and switched to webpack.
> I think Webpack solves a real problem in the web world, but holy cow is it a pain to configure in large applications. Anyone who has had to maintain a larger (and often dynamic) Webpack configuration knows what I am talking about.
Maybe I was doing it wrong but for a previous project I was using SystemJS for module loading + bundling and Gulp for SASS + TypeScript compilation and livereload. I've replaced all of this with a much simpler (before I had too many differences between development and production builds) Webpack configuration that does everything. Setting up both configurations drove me up the wall with the usual array of "module not found" and "file not found" problems you have to persist with but the Webpack setup feels more robust now that it's working.
Probably not an easy problem, but it would be amazing if build tools by default gave you a lot of help with debugging errors e.g. "module a/b/c not found, did you mean ../a/b/c?".
> What if we could take C# code, and transpile it into JavaScript? What if we could take a YAML configuration file, and create a working program just out of configuration? What if we took an image, and automatically made it cropped and greyscaled?
What?! Image, crop and greyscale? That doesn't sound like a job for a bundler. Is this sarcasm?
Which really is an anti-pattern IMO - but seeing people repeat the same mistakes with new tools over and over is not new I guess - but it is extremely powerful.
It's a valid use case. Think of something like a thumbnail generator for a directory of images. If you include an image in your application, maybe you also want to be easily pull in a thumbnail for it on a different summary page in your app.
Webpack just makes me so sad. It is slow, arbitrary, inconsistent and unstable. Just like gulp and grunt.
I seek a proper, fast, consistent, dependency driven JavaScript build tool.
Won't somebody share their make rules for .js?
I work on ~1000 lines of GNU make for a front-end build pipeline with dozens of projects with 600 kLOC TypeScript, 400 kLOC JavaScript, 80 kLOC LESS, and a variety of other things (formatting, i18n, Closure Compiler, Angular AOT, etc).
Make is truly a timeless tool. Parallel, incremental, and declarative; it's a well architected tool based on correct principles. Everything else -- Ant, Maven, Grunt, Gulp -- are diappointments by comparison. Unfortunately, however, make wasn't made to compose well; you'll rarely see people (including me) publishing and re-using rules.
If you want a general-purpose composable non-sucky build tool, check out Google Bazel (in beta): https://bazel.build/
> Unfortunately, however, make wasn't made to compose well; you'll rarely see people (including me) publishing and re-using rules
I'm not saying Gulp, Grunt or Webpack will suit your needs but I find Makefiles quickly become very unreadable and hard to debug. Its syntax for loops, conditions and arithmetic is awkward and hard to remember and the behaviour of variables is confusing. At least with the others the syntax is decent and there's tons of plugins for common tasks.
Why would Gulp for example not suit your use case?
> Unfortunately, however, make wasn't made to compose well
PMake (aka BSD Make) is actually fairly good in this regard- allowing for include libraries (so long as namespaces don't collide). Unfortunately it is not so well known...
I am (work at Lucid Software: www.lucidchart.com www.lucidpress.com). We're using in conjunction with Closure Library, Clutz, Tsickle and Angular AOT template compilation to get great code sizes.
And Google has always been a heavy user of course.
Closure Compiler is preternaturally good at dead code removal, inlining, minification. But you have to use advanced optimization mode, and write JS amenable to its static analysis. If you're willing to put in that work, you'll get fantastic minification. If you're not, you should just find another tool.
Scala.js includes Closure Compiler adv optimizations right in the standard workflow, so it's a good bet any Scala.js project will be using it.
I have an Angular 1.x app bundled with Webpack, which allows me some nice ES6 features. I especially like it for imports (which allows much better code completion than Angular's native Dependency Injection).
Configuring Webpack to do this was one of the hardest things I've ever done. :D
I had the same problem -- after throwing together a few open source front-end libraries, and struggling with each to get webpack, babel, karma, flow, etc. all working seamlessly together, I put together https://github.com/krakenjs/grumbler and now just fork this every time I want to start something new.
Being able to just start writing code without spending forever setting up the perfect environment is hugely liberating. I'd encourage everyone to find good boilerplates for what they want to do (or put together their own if nothing else fits)
in case its helpful to anyone, i was frustrated with this same thing too so i made a webapp to help with the boilerplate search. It also measures the "cognitive load" of a boilerplate to add some sort of cost function.
Every time I start a new web project, I try to find ways to not have to use something like Webpack. I keep hoping the community has finally solved the problem in a more elegant way. The additional mental overhead of a dependency like this isn't worth it.
Sadly, I haven't found a way around the dependency yet.
Have you tried budo[1]? I am the author, so very obviously biased, but the tool has a small following among some creative developers since it’s really quick and easy to work with.
Most of my projects don’t need the scalability of Facebook or Instagram, so I can do without some of Webpacks more nuanced features. My entire dev/build/deploy cycle is just a couple npm scripts.[2]
They help frame this domain's perspective on the timeless tension between usability and flexibility - ie am I prepared to sacrifice some configuration options in return for being able to get quickly setup?
Clearly the answer in a lot of cases is going to be 'no', but nevertheless seeing how difficult it can be to find that sweet spot between usability and flexibility might help one better appreciate the value returned by those difficulties.
Personally, I've found the commitment to stick to the conventions enforced by Create React App to have been largely beneficial (at least so far (in one project)). And I've been surprised how willing and able I am to creatively work within those limitations.
> am I prepared to sacrifice some configuration options in return for being able to get quickly setup?
The best part about create-react-app is the `eject` option. So you never have to ask that question. You can just get going with the defaults, then 'eject' your config files to tweak once you uncover your specific needs.
I am convinced this 'no lock-in' approach is the way to go for scaffolding builders and frameworks in general.
> The best part about create-react-app is the `eject` option
Best part or necessary evil? I'm glad it exists, but ultimately you lose a lot of the benefits of create-react-app (seamless updates to react-scripts, e.g. the move from Webpack 1 to 2) as soon as you eject, which is why it is somewhat discouraged, and why some people have built projects that allow you more config overrides without ejecting.
Webpack (or any other build tool, really) is complex because people's needs are complex.
You don't really need to spend too much time configuring Webpack if you're just trying to bundle a bunch of JS files together. I.e, if you don't need the fancy loaders and plugins and just want an optimized JS bundle, the instructions on this page are all you need: https://webpack.js.org/api/cli/ (see section titled "Usage Without Config File")
But of course, you don't want just that. You want support for ES6, JSX, bundling and optimizing CSS, autoprefixing, bundle splitting, building SVG sprite sheets, etc. etc. At that point you just have to deal with the complexity.
> Personally, I've found the commitment to stick to the conventions enforced by Create React App to have been largely beneficial (at least so far (in one project)). And I've been surprised how willing and able I am to creatively work within those limitations.
I feel the same way. I no longer configure my build system from scratch. I try to work with create-react-app's defaults for as long as possible, and eject if I can't coax it into doing something I need. It's no different from letting XCode or Visual Studio autogenerate a project for you and customizing it as you go along.
At the end of the day, I'd rather write code than configure build systems. But sadly, they're a necessary evil no matter what tech stack you work with. I personally feel that it's not worth spending time learning them deeply, but I'm prepared to pull up that Webpack manual one day because I know I'm definitely going to need it at some point.
I dealt with some Webpack issues at my last job, and for my current job, which started around the time that Rollup was becoming popular, I decided to try Rollup. Even though it happened to have some bugs (which I've reported and they were fixed) it seemed to be a lot better than my Webpack experience, partly because it didn't try to do too much and I had more freedom to do what I wanted. Of course the project I'm working on isn't terribly complex, so I don't need a ton of specific configurations, but it does use React and I felt working with Rollup was a bit easier than Webpack when concerning React, especially when talking about speed; I absolutely hated working with Webpack because I didn't want to wait 1.5-2 minutes just to start working, and have to wait 10 seconds each time I save a file. The only thing I hated more was the attitude from some coworkers that my computer was too slow rather than the tool being bad.
A lot of comments in this thread about struggles with setting up a config.
My intuition is that this is because we are using a declarative programming model: a config file, rather than code.
I don't really understand why we would use, say, Ruby to encode a web server, and then use JSON to encode the build process. We choose our programming languages very carefully for their ability to express powerful control structures, ease of maintenance, debuggability.... and then we use a brittle, underspecified language of flags, nested keys, and filesystem tests and side effects to program our build system... Why?
Can someone who believes in this declarative config build system explain why, in the abstract, it's a good fit for build processes, when we'd never choose a language like that for our actual codebase?
I'm influenced here by Jonathan Blow, who designed into Jai the ability to run arbitrary Jai code during the build process, for this exact reason.
41 comments
[ 3.0 ms ] story [ 91.8 ms ] threadI think Webpack is a step in the correct direction, but web bundlers are still in need of improving.
Maybe I was doing it wrong but for a previous project I was using SystemJS for module loading + bundling and Gulp for SASS + TypeScript compilation and livereload. I've replaced all of this with a much simpler (before I had too many differences between development and production builds) Webpack configuration that does everything. Setting up both configurations drove me up the wall with the usual array of "module not found" and "file not found" problems you have to persist with but the Webpack setup feels more robust now that it's working.
Probably not an easy problem, but it would be amazing if build tools by default gave you a lot of help with debugging errors e.g. "module a/b/c not found, did you mean ../a/b/c?".
What?! Image, crop and greyscale? That doesn't sound like a job for a bundler. Is this sarcasm?
Make is truly a timeless tool. Parallel, incremental, and declarative; it's a well architected tool based on correct principles. Everything else -- Ant, Maven, Grunt, Gulp -- are diappointments by comparison. Unfortunately, however, make wasn't made to compose well; you'll rarely see people (including me) publishing and re-using rules.
If you want a general-purpose composable non-sucky build tool, check out Google Bazel (in beta): https://bazel.build/
Blog post from Google Angular engineer, including thoughts on make and Bazel for front-end builds: https://medium.com/@Jakeherringbone/building-angular-apps-at...
I'm not saying Gulp, Grunt or Webpack will suit your needs but I find Makefiles quickly become very unreadable and hard to debug. Its syntax for loops, conditions and arithmetic is awkward and hard to remember and the behaviour of variables is confusing. At least with the others the syntax is decent and there's tons of plugins for common tasks.
Why would Gulp for example not suit your use case?
PMake (aka BSD Make) is actually fairly good in this regard- allowing for include libraries (so long as namespaces don't collide). Unfortunately it is not so well known...
And Google has always been a heavy user of course.
Closure Compiler is preternaturally good at dead code removal, inlining, minification. But you have to use advanced optimization mode, and write JS amenable to its static analysis. If you're willing to put in that work, you'll get fantastic minification. If you're not, you should just find another tool.
Scala.js includes Closure Compiler adv optimizations right in the standard workflow, so it's a good bet any Scala.js project will be using it.
Configuring Webpack to do this was one of the hardest things I've ever done. :D
That's why I made a boiler plate project with React SSR, TypeScript, and Webpack
https://github.com/styfle/react-server-example-tsx
Being able to just start writing code without spending forever setting up the perfect environment is hugely liberating. I'd encourage everyone to find good boilerplates for what they want to do (or put together their own if nothing else fits)
Here are the two boilerplates mentioned:
https://packagejason.herokuapp.com/krakenjs/grumbler
https://packagejason.herokuapp.com/styfle/react-server-examp...
and you can search others to your fancy.
Smaller, type-checked build files, even has a native packager plugin for building RPMs... really very nice.
Sadly, I haven't found a way around the dependency yet.
Most of my projects don’t need the scalability of Facebook or Instagram, so I can do without some of Webpacks more nuanced features. My entire dev/build/deploy cycle is just a couple npm scripts.[2]
1 - https://github.com/mattdesl/budo
2 - https://github.com/Jam3/360-image-viewer/blob/master/package...
https://github.com/insin/nwb
https://github.com/saguijs/sagui
https://github.com/mozilla-neutrino/neutrino-dev
https://github.com/facebookincubator/create-react-app
They help frame this domain's perspective on the timeless tension between usability and flexibility - ie am I prepared to sacrifice some configuration options in return for being able to get quickly setup?
Clearly the answer in a lot of cases is going to be 'no', but nevertheless seeing how difficult it can be to find that sweet spot between usability and flexibility might help one better appreciate the value returned by those difficulties.
Personally, I've found the commitment to stick to the conventions enforced by Create React App to have been largely beneficial (at least so far (in one project)). And I've been surprised how willing and able I am to creatively work within those limitations.
The best part about create-react-app is the `eject` option. So you never have to ask that question. You can just get going with the defaults, then 'eject' your config files to tweak once you uncover your specific needs.
I am convinced this 'no lock-in' approach is the way to go for scaffolding builders and frameworks in general.
Best part or necessary evil? I'm glad it exists, but ultimately you lose a lot of the benefits of create-react-app (seamless updates to react-scripts, e.g. the move from Webpack 1 to 2) as soon as you eject, which is why it is somewhat discouraged, and why some people have built projects that allow you more config overrides without ejecting.
You don't really need to spend too much time configuring Webpack if you're just trying to bundle a bunch of JS files together. I.e, if you don't need the fancy loaders and plugins and just want an optimized JS bundle, the instructions on this page are all you need: https://webpack.js.org/api/cli/ (see section titled "Usage Without Config File")
But of course, you don't want just that. You want support for ES6, JSX, bundling and optimizing CSS, autoprefixing, bundle splitting, building SVG sprite sheets, etc. etc. At that point you just have to deal with the complexity.
> Personally, I've found the commitment to stick to the conventions enforced by Create React App to have been largely beneficial (at least so far (in one project)). And I've been surprised how willing and able I am to creatively work within those limitations.
I feel the same way. I no longer configure my build system from scratch. I try to work with create-react-app's defaults for as long as possible, and eject if I can't coax it into doing something I need. It's no different from letting XCode or Visual Studio autogenerate a project for you and customizing it as you go along.
At the end of the day, I'd rather write code than configure build systems. But sadly, they're a necessary evil no matter what tech stack you work with. I personally feel that it's not worth spending time learning them deeply, but I'm prepared to pull up that Webpack manual one day because I know I'm definitely going to need it at some point.
http://brunch.io
My intuition is that this is because we are using a declarative programming model: a config file, rather than code.
I don't really understand why we would use, say, Ruby to encode a web server, and then use JSON to encode the build process. We choose our programming languages very carefully for their ability to express powerful control structures, ease of maintenance, debuggability.... and then we use a brittle, underspecified language of flags, nested keys, and filesystem tests and side effects to program our build system... Why?
Can someone who believes in this declarative config build system explain why, in the abstract, it's a good fit for build processes, when we'd never choose a language like that for our actual codebase?
I'm influenced here by Jonathan Blow, who designed into Jai the ability to run arbitrary Jai code during the build process, for this exact reason.