5 ms·
The problem is that new and better ways to do things come along (ES2015 versus JS, webpack versus grunt/gulp), but the old ways hang around like a bad smell. H
by hoodoof 11y ago
The problem is that new and better ways to do things come along (ES2015 versus JS, webpack versus grunt/gulp), but the old ways hang around like a bad smell.
How the heck as a beginner are you meant to fight your way through all the noise of the old, bad ways of doing things? How is a beginner meant to know that really they should be using ES2015 and webpack rather than JS and gulp/grunt? How does a beginner even come to understand that in the reactJS world they might be reading something relevant, but then again they might be reading something completely irrelevant and in compatible (i.e. ES2015 verus JS).
Really when a new technology comes along that is a clear "winner", serious consideration should be given to just getting rid of the "old" way.
Unless Grunt and Gulp are going to somehow make a big comeback, the should be loudly killed off.
Damn - whenever I read the React documentation I have to filter out all the irrelevant code that is not ES2015. Why is all that non-ES2015 code there still?
Old tech should be visibly and loudly killed. No wonder its hard for beginners - its all the damn noise made by the "old" ways of doing things.
The react ecosystem is filled with the living dead - technology that has died but just won't go away.
Things should remain backward compatible but only for a very short window, it's really unhelpful to have many many different ways of doing the same thing, it fragments everything including the learning curve. Witness Perl.
Beginners (and I am one) don't need to be shown every possible way to do things - they need be given a rock solid, opinionated path on the current right way to get the job done. I don't care if that opinionated path changes every month, I just want to not have to work it out by fighting through two years of zombie tech to eventually figure it out.
- tptacek 11y agoSell me on Webpack, and, in particular, on why I should care about this particular bit of plumbing.
- hoodoof 11y agoMy (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.
- tptacek 11y agoThis response sums up something important about the Javascript development community that I cannot put into words.
- modarts 11y agoYou take the struggles of a beginner as an indictment on the broader professional JS development community?
- tptacek 11y agoIt has nothing to do with them being a "beginner".
- spicyj 11y agoI believe (and hope) this is not representative of the JS community.
- isolate 11y agoGiven 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.
- bpatrianakos 11y agoI think it sums up the Beginner Community in general, not the JS community. You see this with beginners in everything.
- mbrock 11y agoMy reaction to your comment is likewise ineffable and mysterious.
- amorphid 11y agoThe JavaScript "community" feels like more a large country.
- onewaystreet 11y agohttp://survivejs.com/webpack_react/webpack_compared/ http://survivejs.com/webpack_react/webpack_compared/ https://medium.com/@housecor/browserify-vs-webpack-b3d7ca08a0a9 https://medium.com/@housecor/browserify-vs-webpack-b3d7ca08a...
- peterhunt 11y agoIn 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 https://youtu.be/VkTCL6Nqm6Y?t=9m39s
- sandGorgon 11y agoWhat do you think about jspm and systemjs - the way it separates front end vs back end dependencies and generates a config.js was very nifty.
- peterhunt 11y agoHaven't used it, but I don't believe it has code splitting?
- spicyj 11y agoI 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.
- carbocation 11y agoBundling JS files into one big file is obviated by http2.
- spicyj 11y agoYou 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: http://engineering.khanacademy.org/posts/js-packaging-http2.htm http://engineering.khanacademy.org/posts/js-packaging-http2....
- gedy 11y agoI think it's due to Webpack replacing/eliminating much of what we used to do "manually" in Grunt/Gulp such as transpiling, building, combining, etc. In most of my projects, I no longer needed Grunt for anything aside from deploying to production, etc.
- fenomas 11y agoWebpack 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.
- statictype 11y agoThings should remain backward compatible but only for a very short window, it's really unhelpful to have many many different ways of doing the same thing, it fragments everything including the learning curve. Witness Perl. Sounds like a terrible way to build commercial software. The problem isn't that old things don't die away quickly - far from it - the problem is that we have too many new things coming in that keep changing every few days. I'm building a 10k line coffeescript app that works on top of react. All I care about is getting a toolchain to compile the coffeescript and generate source maps. I don't care about dicking around with npm and node and grunt other than to make the build process work. Tell me why I should care about grunt or gulp or webpack? React introduces a massive win over traditional ways of building UIs that makes learning how to write apps with it worth learning. Why should I care about learning grunt and then learning gulp and then learning webpack, when all I'm using it for is to compile my coffeescript? If I could get away with a Makefile, I probably would.
- bphogan 11y ago> If I could get away with a Makefile, I probably would. You kinda can. I'm seriously considering that in conjunction with <http://entrproject.org/> http://entrproject.org/> for watching file changes. I wrote the book Automate With Grunt out of anger at the terrible docs for Grunt and my displeasure that there was yet another build system out there. And just as the book was released, Gulp came along. Then Webpack. And now there's tools like Brunch. I still use Grunt, because I spent time learning it. And I'll be damned if I'm going to waste time learning a new tool without a really good reason other than "Coke vs Pepsi". (edited for organization because I'm tired.)
- DCoder 11y agoNitpick - Grunt is a task runner, Gulp and Brunch are build tools, Webpack is just a module bundler, it's not a full build tool - it's more a replacement for r.js than for Gulp (and it's remarkably faster than r.js). After trying out Grunt and Gulp, I found Gulp to be more to my liking because the tasks are written as actual JS code, not as a pile of configuration. Plus, it runs the tasks in parallel if they don't depend on each other, whereas Grunt defaults to running them sequentially.
- leo_mck 11y agoI do not think any way of doing things should be killed. People should educate themselves to be able to choose the tool they feel comfortable to do what they need. It is simply as that. If the old tools work and you like them, use them. If you are a beginner and do not know what tools you should use it is your problem. I agree that the things could be better but I think that this idea of making everything super easy for beginners is not a thing we should always focus first. I do not meant to sound harsh but I do not know if things could be much better considering all the things happening with JS on the last years.
- Scarbutt 11y agoDamn - whenever I read the React documentation I have to filter out all the irrelevant code that is not ES2015. Why is all that non-ES2015 code there still? Because browsers don't fully support ES2015 yet? not everyone wants to use/learn new buggy transpilers, new build tools, add more boilerplate, etc..
- ocean3 11y agoWhy not just npm scripts instead of webpack/grunt/gulp?
- Tankenstein 11y agoBecause just bash would be insane to get the features of something like webpack or gulp.
- reinhardt 11y ago> I don't care if that opinionated path changes every month Good for you, you'll feel right at home because that's exactly what's happening in JS-land, and it's a major reason many of us opt to stay the hell away from such a fad-driven development ecosystem.