My (simplistic) understanding is that webpack is more simple than grunt and gulp to configure. Backed up by my observation that most of the most current projects seem to be embracing it - that's enough for me, it's the current winner so it's what I use. I don't have time and I'm not interested in doing a detailed technical analysis - my approach is just to try to understand what technologies are the latest - and on the assumption that they are the latest because they are better, and on the assumption that previous technologies that did the same thing will be superseded - I use them.
You can criticise this approach as just following the trends but I take this approach because it would be stupid to try to understand every single component of the ecosystem and then make my own careful choices - what is everyone else using right now? Probably good enough unless I know some good reason not to use it.
I am a beginner and struggle hard to understand the vast array of tech I need to do reactJS development. It hurts me very badly sometimes and I feel stupid because I don't grasp it all, but I have to get shit built so for the most part I'm just doing what others are doing and as I go I am learning more and more and in areas that I have gained real understanding I then make my own educated decisions about exactly how to do it in the right way.
> webpack is more simple than grunt and gulp to configure
That's the first time I've heard that one. In my opinion, what makes Webpack great is its raw power and module-based (rather than file-based) focus. Browserify is easy to work with and get started with but less powerful. (Granted, it's quickly catching up.) Webpack is a lot of things, but easy to configure is not one of them.
By the way, Webpack doesn't really replace Grunt or Gulp. It replaces Browserify. That said, if you use Webpack, you can easily get by with npm scripts instead of Grunt/Gulp.
Given that front ends have a huge visual component, it kind of makes sense that developers would approach them like clothing fashion: you don't have to watch the designers to look reasonably good, or even pay attention to construction, you just have to watch everyone else.
Well, at least that's what I picked up from this rather honest opinion.
I know a huge amount about software development and work with a wide range of technologies.
Learning some completely new field like browser based development is best done by just jumping in and trying to make stuff work. You learn along the way and much of it will be unfamiliar. Over time things will become more and more familiar until you start to develop expertise across the entire field.
If you are suggesting that instead I should learn by sitting down for six months in an ivory tower and learn all the theory and function of every part of the software ecosystem that I plan to work with so that I can then take every step of my journey as an expert, then you are misguided.
All software developers live in a fog of ignorance which they work to push back. No one knows everything. The best way to push back the fog of igorance is to start working with the technology to get real stuff done. To do so, it is necessary to make pragmatic decisions such as "well it looks like everyone in this field is using technology X - so that's what I'll use until I know enough to decide otherwise".
Are you someone with a deep knowledge of JS and react development? If yes, did you step in to it as an expert in all things? Did you use things without knowing why? Of course you did. Everyone has to.
I completely agree with your characterization of how beginners can feel. That said,
> If you are suggesting that instead I should learn by sitting down for six months in an ivory tower and learn all the theory and function of every part of the software ecosystem
It's not simply a choice between "learn for 6 months" and "use whatever the latest thing is". You seem to be advocating for the later, which I think is just as unworkable a solution as the former. For instance, a nice medium ground would be to read the github README as well as the front-page website of the candidates.
Also, as someone else here pointed out, you can't kill off gulp/grunt even if webpack exists, because webpack is not a task runner, and some people use the task-runner features of gulp to do more than combine modules, etc.
You admitted to being a beginner - a beginner shouldn't be recommending technology choices beyond that a particular choice might help people get started. There is too much a beginner does not know was his/her point.
He said he was a front end JS beginner. He also mentioned being a seasoned software engineer overall.
His advice is completely sound, and a very valid approach: Want to learn a new platform/ecosystem? Take whatever is the most popular and make stuff work. It's the fastest way to learn by far and with an free bonus you get actual valuable software.
Nobody flames people who learn Rails while learning Ruby! What's the matter with you guys?
The only mistake the GP made was "admit" on HN that he's a beginner at something.
From my limited POV, this is how I see most of the newcomers to JS community currently behaves. And it's a good example of 'learning by doing', which is the advice that everyone gives around here.
- Do some research, look what successful/smart/sane people are using/working on, and why.
- Jump in, hack stuff, make things work.
- Learn while creating. Discover the insights behind the choices that people you're following made.
- Start making your own informed choices.
As long as you're not stuck in the step 2, and advance beyond doing what everyone is doing, you're probably on the right track.
That's how I learned to build maintainable/scalable/successful applications.
I am not sure why the parent compares webpack to gulp/grunt. The latter are generalized task runners (think "make"), but the former is a tool for bundling together many small JS files into one.
Webpack (and browserify, a competitor that's very similar) bring you a module system so that dependencies are explicit with a require() call and you don't have a global namespace with hundreds of objects. JS doesn't have any such system built in. Packaging it into one file in the end, which they do, is necessary for performance so you don't make hundreds of network requests.
You still have the round-trip time for each level of dependencies if they're resolved on the client, at the very least. And a real-world performance comparison where the recursive dependencies are listed up front but sent in separate requests shows unbundling losing:
In order to be sold on webpack you need to understand the stack of problems it solves. I tried to do this during a talk last year; the relevant part is https://youtu.be/VkTCL6Nqm6Y?t=9m39s
Webpack isn't really plumbing like a task runner, it's primarily a dependency wrangler. If you have a page template, which declares dependencies on various partials, each of which declares dependencies on images and JS modules and CSS partials, then Webpack can grok all those dependencies and do things like bundling the images/JS/CSS needed for this or that subset of pages (along with hot loading, source maps, etc.).
Of course, it can also do stuff like minification and transpilation while it does this, so it tends to get compared to grunt/etc. But the magic of webpack isn't the bundling, it's that you can build highly modular pieces of web content and leave webpack to work out what needs bundling.
