4 ms·

Interesting to see that Webpack has continued to gain ground on Gulp as the leading top-level build tool that people use, because from my experience it seems sl

Interesting to see that Webpack has continued to gain ground on Gulp as the leading top-level build tool that people use, because from my experience it seems slightly over-engineered for 99% of use cases. Webpack uses the "configure a black box + add a bunch of plugins" approach to the front-end build pipeline, whereas I recently used Gulp to create a beautiful build workflow using Rollup, Babel ES6, JSX, Sass, and a basic livereload webserver in less than 80 lines of very readable, plain javascript code that would take roughly 5 minutes to explain to a new developer on my team faced with build pipeline modifications. I also don't think many people understand that using Webpack encourages non-ES6 import semantics that will break your source code if you ever decide to switch from Webpack. Encouraging things like "import app.css" seems like it might confuse junior developers who don't understand what's going on under the hood, or have to eventually work in non-Webpack systems. Sorry for the rant here, haha, I'm a huge fan of these surveys and love taking the opportunity to talk crap on build tools / frameworks :).

saosebastiao 9y ago
> Interesting to see that Webpack ... because from my experience it seems slightly over-engineered for 99% of use cases. Overengineered? I feel like un-engineered is the right word for it. I use it, but I dread touching anything in my config, cause every time I do, something breaks. I've tried gulp and grunt, and both of those are pretty bad as well. Different problems, but problems nonetheless. I'd love to see Parcel deliver on their promises, but as of right now it's alpha level for even basic use cases.
- natural219 9y ago
  Curious what you dislike about Gulp? I keep hearing people poo-poo it and say that it's "totally uncool now", but I can't understand anyone's frustrations with it, especially compared to other build tools.
  - chrisco255 9y ago
    Nothing wrong with it. It's just not as powerful as Webpack.
  - saosebastiao 9y ago
    If you're familiar with the jdk ecosystem, I can make an analogy: webpack is to SBT as gulp is to gradle as brunch is to maven. Their styles essentially boil down to different philosophies (code-is-config, build-is-code, and declarative-config respectively). Gulp takes the philosophy that build is code. You hand code all of your pipelines. That's works perfectly fine for simple applications where all you're doing is writing code in a single language (like say just javascript for a node backend), but I've found that it is an unadulterated nightmare trying to get things to work across types of files, as is required by front end development. Your HTML, Javascript, and CSS interact with each other in several different ways, and things no longer fit into a neat pipelines abstraction...it resembles a graph more than anything. Throw in transpilers or compilers, parallel processing pipelines (like for sourcemaps), and it quickly becomes buggy chaos. I maintain that the best abstraction for a build system is that found in Make. Make is actually brilliant in some respects...it is a language for declaratively building a data flow between processing pipelines, but allowing you to use a Bash-ish imperative style to build those pipelines. The problems of Make are many: not everything uses files as inputs or outputs, not everything has a 1:1 input-output ratio, dynamically selecting inputs or naming outputs is horrendously buggy, etc.. But the concept and philosophy behind it are brilliant. If there is any build system of the future, it will be borrowing heavily from Make.
    - natural219 9y ago
      Thanks for the great response! I don't think I understand how HTML, CSS, and Javascript interaction makes Gulp development complicated. My CSS files are totally separate from my HTML/javascript, and are just included directly in my index.html. I use JSX with React to do inline HTML markup inside my .js files, which Babel handles just fine through its transform-react-jsx plugin, included easily in a one-line command in my Gulpfile which is just a very simple "babel" function call configurable via a regular .babelrc file. Basically, I have yet to hit any limitations with the "build-is-code" philosophy, despite years of people telling me it's an awful and horrible thing to do. I can't forsee my <75 line Gulpfile growing too much, as the plugin ecosystem is robust and I already have all the features I could possibly want. For reference, here is my simple Gulp setup. Each line is easily readable and explainable to anyone who knows basic Javascript (and a single Node.js primitive called "pipe"). As I asked another commentor: If you can point me to a clear tutorial on Make that lets me do all the things this Gulpfile does with extreme ease, I'll abandon Gulp and use Make exclusively for all front-end projects. https://gist.github.com/c-johnson/b66d376b686c16efeb26484e89279558 https://gist.github.com/c-johnson/b66d376b686c16efeb26484e89...
megaman22 9y ago
The whole front-end build process ecosystem seems hopelessly complicated and frustrating to me, but I'm a hoary, old, nearly thirty, backend developer. I've yet to have anyone satisfactorily explain why grunt or gulp or webpack is better than makefiles and shell scripts, other than "But its JavaScript!" Every month or so, dependencies break, and everything changes; it seems like a lot if work for very little result.
- natural219 9y ago
  Bash and C absolutely suck to work with if you're not a systems developer. There's so many caveats, gotchas, extra ways to do things, hidden things you have to learn, and lack of clear explanations that touching any ordinary shell file makes me want to scream. If someone wrote a "makefiles for web dummies" tutorial that told me exactly how to do things everything in bash I know how to do with javascript, I'd love to read it.
  - megaman22 9y ago
    Make is it's own thing, and not really tied to C in any way. I've written more makefiles for Java projects when I despised Eclipse than for any other reason. I'm sure that's completely wrong and fucking awful, but it worked really, really well.
    - pjmlp 9y ago
      Make was the choosen tool for Java projects before Ant came into the scene.
    - h_r 9y ago
      While I can somewhat sympathize with wanting to use make, it's the dependency management with Java that would be just horrible. Maven-based dependency management saves you a world of misery most of the time. And when you have conflicts to deal with it's 1000 times worse doing it by hand.
- always_good 9y ago
  Well, portability, for one. Also, Webpack is a sequence of one-liner incantations that do things that would be annoying to by hand, like starting a websocket server to talk to your application to hot-swap the code. The declarative config is an improvement over Gulp and Makefiles for that reason. Same reason I prefer pom.xml over build.gradle.

saosebastiao 9y ago

> Interesting to see that Webpack ... because from my experience it seems slightly over-engineered for 99% of use cases. Overengineered? I feel like un-engineered is the right word for it. I use it, but I dread touching anything in my config, cause every time I do, something breaks. I've tried gulp and grunt, and both of those are pretty bad as well. Different problems, but problems nonetheless. I'd love to see Parcel deliver on their promises, but as of right now it's alpha level for even basic use cases.

natural219 9y ago
Curious what you dislike about Gulp? I keep hearing people poo-poo it and say that it's "totally uncool now", but I can't understand anyone's frustrations with it, especially compared to other build tools.
- chrisco255 9y ago
  Nothing wrong with it. It's just not as powerful as Webpack.
- saosebastiao 9y ago
  If you're familiar with the jdk ecosystem, I can make an analogy: webpack is to SBT as gulp is to gradle as brunch is to maven. Their styles essentially boil down to different philosophies (code-is-config, build-is-code, and declarative-config respectively). Gulp takes the philosophy that build is code. You hand code all of your pipelines. That's works perfectly fine for simple applications where all you're doing is writing code in a single language (like say just javascript for a node backend), but I've found that it is an unadulterated nightmare trying to get things to work across types of files, as is required by front end development. Your HTML, Javascript, and CSS interact with each other in several different ways, and things no longer fit into a neat pipelines abstraction...it resembles a graph more than anything. Throw in transpilers or compilers, parallel processing pipelines (like for sourcemaps), and it quickly becomes buggy chaos. I maintain that the best abstraction for a build system is that found in Make. Make is actually brilliant in some respects...it is a language for declaratively building a data flow between processing pipelines, but allowing you to use a Bash-ish imperative style to build those pipelines. The problems of Make are many: not everything uses files as inputs or outputs, not everything has a 1:1 input-output ratio, dynamically selecting inputs or naming outputs is horrendously buggy, etc.. But the concept and philosophy behind it are brilliant. If there is any build system of the future, it will be borrowing heavily from Make.
  - natural219 9y ago
    Thanks for the great response! I don't think I understand how HTML, CSS, and Javascript interaction makes Gulp development complicated. My CSS files are totally separate from my HTML/javascript, and are just included directly in my index.html. I use JSX with React to do inline HTML markup inside my .js files, which Babel handles just fine through its transform-react-jsx plugin, included easily in a one-line command in my Gulpfile which is just a very simple "babel" function call configurable via a regular .babelrc file. Basically, I have yet to hit any limitations with the "build-is-code" philosophy, despite years of people telling me it's an awful and horrible thing to do. I can't forsee my <75 line Gulpfile growing too much, as the plugin ecosystem is robust and I already have all the features I could possibly want. For reference, here is my simple Gulp setup. Each line is easily readable and explainable to anyone who knows basic Javascript (and a single Node.js primitive called "pipe"). As I asked another commentor: If you can point me to a clear tutorial on Make that lets me do all the things this Gulpfile does with extreme ease, I'll abandon Gulp and use Make exclusively for all front-end projects. https://gist.github.com/c-johnson/b66d376b686c16efeb26484e89279558 https://gist.github.com/c-johnson/b66d376b686c16efeb26484e89...

megaman22 9y ago

The whole front-end build process ecosystem seems hopelessly complicated and frustrating to me, but I'm a hoary, old, nearly thirty, backend developer. I've yet to have anyone satisfactorily explain why grunt or gulp or webpack is better than makefiles and shell scripts, other than "But its JavaScript!" Every month or so, dependencies break, and everything changes; it seems like a lot if work for very little result.

natural219 9y ago
Bash and C absolutely suck to work with if you're not a systems developer. There's so many caveats, gotchas, extra ways to do things, hidden things you have to learn, and lack of clear explanations that touching any ordinary shell file makes me want to scream. If someone wrote a "makefiles for web dummies" tutorial that told me exactly how to do things everything in bash I know how to do with javascript, I'd love to read it.
- megaman22 9y ago
  Make is it's own thing, and not really tied to C in any way. I've written more makefiles for Java projects when I despised Eclipse than for any other reason. I'm sure that's completely wrong and fucking awful, but it worked really, really well.
  - pjmlp 9y ago
    Make was the choosen tool for Java projects before Ant came into the scene.
  - h_r 9y ago
    While I can somewhat sympathize with wanting to use make, it's the dependency management with Java that would be just horrible. Maven-based dependency management saves you a world of misery most of the time. And when you have conflicts to deal with it's 1000 times worse doing it by hand.
always_good 9y ago
Well, portability, for one. Also, Webpack is a sequence of one-liner incantations that do things that would be annoying to by hand, like starting a websocket server to talk to your application to hot-swap the code. The declarative config is an improvement over Gulp and Makefiles for that reason. Same reason I prefer pom.xml over build.gradle.