10 ms·
The Hitchhiker's Guide to Modern JavaScript Tooling
- k__ 11y agoWith NPM and Webpack you can get pretty far. With all it's plugins an loaders you're pretty much set.
- dominotw 11y agoI've never had the need to use gulp/grunt or any such thing after webpack.
- tete 11y agoGulp is really great and better, than Grunt, but sometimes make seems to be a good choice that people forget about.
- devNoise 11y agoI tend to agree that Gulp is better than Grunt. I prefer the code over configuration approach Gulp takes. The other benefits is that Gulp is streams based and will save you a lot of disk I/O over Grunt.
- tokenizerrr 11y agoI recently tried switching from Grunt to Gulp and was expecting to see improvements in build times, but my builds actually wound up taking about 2x as long (on an ssd). Maybe I was doing something wrong, I don't know, but it was pretty disheartening. Here is my Gruntfile in case anyone cares: http://hastebin.com/wezizasiye.js http://hastebin.com/wezizasiye.js
- tdumitrescu 11y agoIf build time is a big concern, I'd suggest Brunch. It starts out fast and it caches previously built assets so that subsequent builds are incremental.
- rout39574 11y agoHow is that different from make?
- tbolt 11y agothis post encapsulates why development with js can be a nightmare. you start with grunt because that's the cool one, then everyone shifts to the new cool one -gulp- but oh wait, if you are concerned about build time, you need to be using this other new hotness.
- nailer 11y agoI'd rather use JS than add shell mixed in with Makefile. Two extra languages just to run a build system seems like adding unnecessary complexity.
- aaronem 11y agoI find it depends on the scale of the project. If I just need something to encapsulate my test runner and packing tool invocations, then I'll just toss those in a five-line Makefile, because why add a heavyweight build tool most of whose capabilities I'm not going to exercise?
- rout39574 11y agoShell and make are pervasive. If you're not comfortable with them, you will glean great value from becoming so. Your perspective rings to me like "There's plenty of technical literature in Mandarin; learning English just to ...." Not wrong, per se. But profoundly limiting, and to an extent you won't comprehend until you've crossed that knowledge barrier. Elswhere in this comment stream someone talks about the 'innovation' of incremental builds in the JS build tool landscape... I think you might find that Make discovered, and solved, most of the build-system challenges the language-specific tools will encounter, decades ago.
- zaphar 11y agoExcept one of the most important ones. Hermetic and 100% Reproducible builds. Sadly most of the Make replacements still haven't really solved that one either so your point still stands in a way.
- nailer 11y agoIt's a dependency graph. It's just a data structure. You can do that in any language. Saying you need automake for a build system, or would gain anything from doing so compared to a native system, is akin to saying you need another language for arrays. Regarding your popularity argument: amongst other JS developers you'd get more network effect from gulp. If your backend is, say, Python or Ruby learning automake wouldn't help you there either.
- AdrianRossouw 11y agosince i switched to webpack, i've had very little reason to use gulp in my projects. Anything extra was very easily managed by some simple Makefiles.
- k__ 11y agoSame here. It didn't just eliminate the use of gulp for much things, but also minimized the boilerplate I needed to get this stuff done in gulp. Everything is just a "loader" away and doesn't need much configuration. I even got rid of Bower for most libraries.
- Plugawy 11y agoCan you post some examples of your Makefiles? I'm trying to work out how I can replace Rails' asset pipeline without getting a headache caused by overwhelming number of node-based tools I'd have to install. Having one tool + make sounds like something I'd gladly adopt.
- williamcotton 11y agoHere's something I made about 6 months ago: https://github.com/williamcotton/makeify https://github.com/williamcotton/makeify
- Plugawy 11y agoNice one! Thanks a lot
- kasbah 11y agoYes, I feel like both Gulp and Grunt miss something fundamental that Make still has. I don't want to depend on other people's plugins for basic tasks and I want to only rebuild the stuff that changed. I tried Gulp with some 'notice if changed' plugins but it didn't seem to work so I end up sticking to Make. Some of my Make build systems have gotten a bit unwieldy so recently I have been looking at using Ninja and ninja-build-gen from npm. This way I can still write my configure and my build tasks in JS/CoffeeScript and get to use a modern less cluttered version of Make that will scale well with the project.
- hyperhopper 11y agoMake doesn't work on windows. Its not cross platform, while Node, and all technologies built on top of it, are.
- deleted 11y ago[deleted]
- zaphar 11y agoWhat? http://gnuwin32.sourceforge.net/packages/make.htm http://gnuwin32.sourceforge.net/packages/make.htm
- dauoalagio 11y agoMake can be good but can also be quite tedious/verbose to get started. I actually prefer using the npm scripts and using the binary files in `./node_modules/.bin/{ webpack, babel, etc }` Takes no time at all and there is no interface that can break like in gulp or grunt
- Killswitch 11y agoI too used to do this, until I needed more complex things, or am trying to find a bug in my code and have to make a few small edits, save, run `npm run build` then refresh my browser, make changes, repeat step 40 times in a 15 minute timespan. Or I can create a couple gulp tasks (which honestly, is easy as heck) then a watcher using livereload, and run `gulp watch` then just be done with it.
- devNoise 11y agoThis a good overview of some popular tools for JavaScript development. The thing that gets me about modern JavaScript development is the amount of modules you download to build your code. Currently I'm going through a PluralSights course for Gulp.js. Just to help me build and test my code, over 240MB of modules were downloaded. I'm starting to understand the benefits of all those modules. The thing that gets me is that the process makes you download all those modules again for the next project.
- kriro 11y agoVery useful. This will be required reading for all our students :) I created a react/grunt/browserify/babelify (+bootstrap) starter repo to clone from github for them but think it's still confusing. This provides much needed background information in one bundled place (even though the stack is slightly different and only mentions grunt).
- aaronem 11y agoThat repo sounds like a good candidate for replacement with a Yeoman generator!
- kriro 11y agoYep pretty much a planned project but for now I'm keeping everything as sort of a learning exercise. master is ES5 and I have an es6 branch. The idea is to have students look at the ES5 version first to appreciate the ES6 changes. [actually a basic git primer is the first step :D] The more practical solution would indeed be yeoman (imo)
- heidar 11y agoIf you want to get started with this stuff but you're feeling lost or overwhelmed then the free SurviveJS - Webpack and React book is a nice place to start! It covers many of these tools. http://survivejs.com http://survivejs.com
- hex13 11y agoWe talk about "modern JavaScript tooling" but year after year, the list essentially stays the same. Maybe few new players have appeared (Gulp, WebPack, Babeljs) but they do exactly the same thing that the tools we had before (e.g. Grunt, Browserify, Traceur). It occurs to me that "modern JavaScript tooling" is growing only vertically (better tools to build, better tools to modularize, better tools to transpilation), but not horizontally. If we see some "brave new tool" on the scene, this tool will do exactly what previous tools did, only better. I would like to have some decent tools for: * analysing of project structure (e.g. dependencies between modules, graphs, trees etc.) * code visualising (not toy! Gource is beautiful, but pretty useless. JSCity... I also don't see much use of it. I would see something that would allow me to draw some useful information from code visualisation. Something that would allow to understand better. But I see only beautiful animations and abstract 3D scenes) * maintaining code (something that would allow me to conduct massive scale refactoring, or automatically convert code from one framework to another etc.) * better editors for HTML/CSS, maybe even some decent WYSIWYG Okay. Plain build systems and transpilers also are super useful. I think that Gulp, Babel.js, Browserify etc. are greeeat. But I think we need more. Something different. There is still room for innovation. Projects grow bigger and I think that we need something that helps us * to understand easily new codebase * to navigate codebase, conduct semantic search etc. * to maintaining, refactoring etc. I feel that some important tools are missing, not created yet.
- scribu 11y ago> something that would allow me to conduct massive scale refactoring Here's an interesting tool for that: http://www.graspjs.com/ http://www.graspjs.com/ (structural search/replace)
- applecore 11y agoThe very good thing about module bundlers versus transpilers and task runners is that changing a single file doesn't result in a complete rebuild of the project; since the bundler maintains a model of the dependencies between files, it only needs to recompile the files that matter.
- guntars 11y agoThe downside is that now you have a whole other ecosystem of tool wrappers that tends to lag behind the tools themselves. They also tend to be JS specific, so if you have any other assets, you'll still need a regular task runner.
- applecore 11y agoThat's why I keep everything in JavaScript, including HTML and inline styles.
- mbrock 11y agoI think it's good to note that you don't actually need a single one of these tools to make functioning software. You can pack your scripts with cat and download libraries with wget and use regular old JavaScript without transpilers. When you have a problem with this, you can use tools... But you don't have to top-load every project with a whole suite of complex tools just for the sake of it.
- aaronem 11y agoWell, you do at minimum need something that understands CommonJS modules, if you want to pack isomorphic code to run in the browser, so you need Browserify or Webpack. And you need a module downloader that resolves and installs dependencies, so you need NPM and/or Bower. And, if you want to write unit tests (which you should!) then you need a Javascript test harness, because otherwise you're going to have a bad time instantiating your modules and injecting mocks into them. You could do this in just plain Node, sure, but you'll end up reinventing a lot of wheels if you do. So you need Mocha, or something very like it. But build tools are sort of a luxury, sure. You can get by just fine with make, if you already know how to use it. And nobody needs transpilers, except people who just don't have enough problems in their lives already.
- TazeTSchnitzel 11y ago> Well, you do at minimum need something that understands CommonJS modules, if you want to pack isomorphic code to run in the browser, so you need Browserify or Webpack. No, you don't. These are optional. You only need these for larger applications that need packing. > And you need a module downloader that resolves and installs dependencies, so you need NPM and/or Bower. No, you don't. You can manually keep things up to date. > And, if you want to write unit tests (which you should!) then you need a Javascript test harness, because otherwise you're going to have a bad time instantiating your modules and injecting mocks into them. Okay, you probably do need this.
- Killswitch 11y agoYour first 2 responses fit into this category: > people who just don't have enough problems in their lives already.
- deleted 11y ago[deleted]
- deleted 11y ago[deleted]
- erokar 11y agoLost in the Bazar...
- jebblue 11y agoReading the page then the comments, even as a senior developer who only touches JavaScript when necessary; I don't see much unification in the JavaScript world today compared to 12 to 15 years ago. React seems to be a theme, if I want to develop a modern (is Web 2.0 still the term) single-page site (is that still a phrase?) using HTML5/CSS3/JavaScript...what environment exists that is cohesive and complete as either Eclipse for Java or Visual Studio for .NET? Here's my answer, as an outsider, Java dude who only suffers brief interludes with JavaScript...I'd pick jQuery Mobile or DART. The thing is...whenever these JavaScript tooling articles comes up I don't see those listed. I see names like React, Meteor, Gulp, Grunt, Webpack and maybe 3 dozen more.
- joesmo 11y ago"The biggest weakness of such small tools approach is that it is hard to learn what to use and how to configure it." No. By far the biggest weakness of such a small tools approach is a Balkanization of development tools that generally refuse to work with one another and often don't work very well by themselves. One library I really wanted to try was using Browserify but I wanted to use brunch/bower because my workflow was already in brunch. Even with the brunch-browserify plugin this wasn't possible. After wasting two days on it, I gave up and just used Browserify by itself. Another couple of hours it was actually working. This is typical. On another app, I use gulp. Another piece of garbage that claims that when you run a command 'gulp watch' it will automatically rebuild your assets. It won't. These are only three small projects, each using a different build tool: browserify, gulp, and brunch + bower. None of them are compatible with each other and it's unlikely they will ever work together in one project without hours or days of trial and error. If there was one monolithic (or not) dependency / build tool that actually worked, I'd much rather use that, and it would be a much better approach than having a whole bunch of small crappy tools that don't work together. tl;dr: Not only is having multiple tools doing the same thing in this area not appealing, it just leads to developers wasting massive amounts of time and "what the fucks?" working with half a dozen tools that do the same thing and do it poorly.
- SonicSoul 11y agoyes there is this overhead, but it also reduces dependency on any specific framework, avoids using big one-size-fits-all monoliths, let's you choose the best tool for the job, makes your team a lot more well rounded by understanding pros and cons of each of those libraries.
- joesmo 11y agoI don't see how this reduces dependencies on any specific framework or in any way affects that at all. I'm the one who chooses what dependencies and frameworks I work with. The only way these tools affect which dependencies I choose is that they limit the ones that can work with each other. Nor does it "avoid using big one-size-fits-all monoliths," because that wasn't a problem I had in the first place. The article is about build tools in case you haven't noticed. It does not let me choose the right tool for the job. That's exactly what I'm describing in the post. It forces you to use whatever the authors of library X thought is the right tool for the job. And the authors of library Y and the authors of library Z ... etc. to the point where it becomes impossible to actually work with libraries from different sources together unless you manually manage them. It does not make the team a lot more rounded to learn and understand a bunch of build tools that do the same thing as each other. What would make it more rounded is if these tools weren't so shitty, worked together, and there was only one of them so they could focus on actually building stuff instead of mentally masturbating about stupid build tools that don't work.
- talles 11y agoDoes webpack started to be more popular than browserify? I'm starting to see people talking more about webpack than the former...
- joemaller1 11y agoThe React world embraced WebPack after a modularity-kerfuffle back in January[1]. Pete Hunt followed that with his webpack-howto repo [2] which kind of turned the tide. I really like Gulp/Browserify/Watchify/BrowserSync, but I'm starting to feel left behind and need to give WebPack an honest try. [1]: http://blog.namangoel.com/browserify-vs-webpack-js-drama http://blog.namangoel.com/browserify-vs-webpack-js-drama [2]: https://github.com/petehunt/webpack-howto https://github.com/petehunt/webpack-howto
- iandanforth 11y agoThere is a fairly important point that is missed by this article. You do not need build tools to write JavaScript and depending on which tools you use there are significant drawbacks to using any them. Before you dive into the world of build tools and process management I urge you to write unminified, ES5 (aka the JavaScript that runs without transpilation today) until it hurts. Write unminified JavaScript and watch your page load times. Write ES5 and time how long it takes you to complete projects of a given size. Write reactjs code but use the JSXTransformer. Watch page performance. Watch how many times you reload the page in a given sitting. It's really only when you find yourself with a problem that you can quantify that these tools start to make sense. Discover for yourself why these tools exist or you'll waste a ton of time learning the newest thing and in the end not have gained much at all.
- JustSomeNobody 11y agoI wish and hope web developers (and developers in general) read your post. Very well said.
- jowiar 11y agoThere's a definite balance between cargo-culting and reinventing the wheel. Minification is often a premature optimization. A somewhat proper/standardized module system (aka that which comes with ES6), on the other hand, is almost a necessity when it comes to building software. Standalone JS was meant to add little bits of interactivity to documents. If what you're building is interactive documents, build tools are generally overkill. If you're building applications, the tools exist largely b/c JS-in-the-browser was not designed to build applications.
- sirgawain33 11y agoI highly recommend this road as well. Three exercises along the lines of the parent that I found particularly valuable: 1. Compare VanillaJS TodoMVC to your framework of choice http://todomvc.com/ http://todomvc.com/ https://github.com/tastejs/todomvc/tree/gh-pages/examples/vanillajs https://github.com/tastejs/todomvc/tree/gh-pages/examples/va... What does the framework buy you? Is the framework-powered code easier to read? Easier to understand for a newcomer to the code base? 2. Read every line of Effective Javascript (it's short and eminently practical) and write out every code example. http://www.amazon.com/Effective-JavaScript-Specific-Software-Development/dp/0321812182/ http://www.amazon.com/Effective-JavaScript-Specific-Software... There are about a dozen small errors in the code in the book, see if you can find them. 3. Read substack's alternative Javascript build flow: http://substack.net/task_automation_with_npm_run http://substack.net/task_automation_with_npm_run Think about the possibilities and limitations. (I personally love his approach at the beginning of projects when I could care less about fiddling with gulp and want to get into exploring the guts of a problem)
- deckar01 11y agoAnother tool that becomes useful as your npm dependency list grows is npm-shrinkwrap. It is too easy to get large projects into a state that the existing developers can build and test, but break in production builds and for new developers. Being able to strictly version dependencies and control minor package updates can save you from debugging bad builds and losing new contributors. It's not a silver bullet, but can save you some frustration when packages deviate from proper versioning practices.
- fiatjaf 11y agoBad. Please don't use any of these tools except if it is necessary. And it is not.
- if_by_whisky 11y agoA popular opinion seems to be that none of these tools are necessary-- if you don't use any tools then how do you write unit tests?
- eibrahim 11y agoIn my opinion Ember JS is the best framework out there. It's instantly productivity and everything just works out of the box. No worry about tooling and such. If you are coming from Ruby on Rails or similar platforms, ember JS is your best bet.
- reycharles 11y ago> This process is called transpilation and there are tools called transpilers which takes care of it for you. The process is called compilation, and the tools are called compilers!
- TeMPOraL 11y agoWeb scene likes inventing new words for old concepts.