I think the biggest issue we’re currently experiencing in the front-end world is the fact that everything is beginning to become automated, we depend a little bit too much on frameworks, and not to mention things like dependency management, etc,.
You can imagine how difficult it might be for someone new to begin his journey in front-end development, the amount of tools we have to deal with is starting to overtake the process of writing actual code.
I recently wrote a blog post on project management tools for development teams, and I got inspired to look into some ‘basic’ workflow tools for standalone front-end developers. It’s important that we make a decision (agreement?) on which tools we are going to use, and then use them for the time being.
Staying productive is one of the most crucial habits / things we can do, in order to feel a sense of alignment with our projects and the work we do. It’s frustrating to begin learning front-end, only to realize that you don’t just need to learn a programming language, but dozens more tools and platforms to make it all work.
With that in mind, automation isn’t always meant to make us less productive, or gives the gateway to doing less work and spending more time thinking, it’s merely a way of being more efficient / effective with our code and projects.
I have no doubt in my mind that you already are familiar with these workflow tools, but perhaps you’re not, and so it is time that you introduce yourself to each other, and maybe along the way you will become good friends!
1. Anti-Code: Chrome Devtools Cheatsheet
I’m going to assume that you’re aware of the fact that Chrome is currently the hottest browser for front-end, due to the fact that it supports more HTML5 properties than any other web browser. (among other reasons)
This cheatsheet is brilliant for learning to work with the Chrome Devtools, and it can be immense help on getting up to speed with how most front-end developers manage their workflow. It’s hardly a tool (Devtools is!), but to me – it’s essential part of my daily development tasks.
2. Yeoman: Client-side Stack for Web Application Development
Yeoman is a opinionated client-side stack, consisting of all the necessary tools and frameworks that a front-end developer should need, to quickly adapt and build new web applications on the fly. Yeoman provides a lot of flexibility when it comes to customizing your own setup, with your own needs.
Stop wasting your time on writing endless boilerplates, and instead use Yeoman to free yourself for the time being. Plus, you get to increase your productivity, alongside the relief of having everything accessible and easy to manage.
3. Bower: Easy Front-end Package Management
The JavaScript community has been long waiting for a decent package management tool for its client-side projects, but something tells me that even Bower (built by Twitter) failed to achieve that goal.
Bower is a package manager for the web. It offers a generic, unopinionated solution to the problem of front-end package management, while exposing the package dependency model via an API that can be consumed by a more opinionated build stack. There are no system wide dependencies, no dependencies are shared between different apps, and the dependency tree is flat.
Instead of having to download and look for updates manually, like you used to, Bower gives you access to a wide library of packages that you can install and manage right away, doesn’t matter what version or which dependency you need – it’s all on the install feature. (see documentation)
4. Grunt: Task-based CMD Build Tool for JavaScript Projects
Grunt was built with one thing in mind: automating repetition, and doing it in such a manner that it doesn’t interfere with the rest of the development workflow, instead – it makes it much more smooth and productive.
You can automate things like deploying projects, linting your projects, compiling or minifying all at once, all of which are fairly time consuming tasks in the long run. It’s also a good alternative to Rake.
There are (literally) thousands of plugins available for Grunt, and the list has been growing at a rapid rate – one of the most extensive libraries of plugins I’ve ever seen! It has been long said that Grunt is a wonderful resource for not only developers, but also designers.
5. Gulp: Intuitive Streaming Build System
Gulp.js is the streaming build system. It’s use of streams and code-over-configuration makes for a simpler and more intuitive build. By preferring code over configuration, gulp keeps simple things simple and makes complex tasks manageable.
There is a lot of heated discussion about how Grunt and Gulp compare to each other, and while I won’t go into detail about those assumptions (to each his own), I do think that Gulp provides a fairly better – intuitive – syntax for those who’re developing in Node.js.
gulp is simply vinyl, vinyl-fs, orchestrator, a CLI, and a set of guidelines to help people make good plugins. Even with a tiny feature set, it has completely disrupted the build tool ecosystem and kicked off a new wave of awesome projects that are revolutionizing your workflow.
Productive Workflow Leads to Better Results
I suppose the list was very narrow sided, and there are surely many, many more tools which we could be adding to this list; but I think that is something I’ll do in the future (keep an eye out for it), as we’ve covered a fair share of stuff in this post already.
It’s going to take you a while to fully understand and grasp these tools, and even more time to learn how to use them properly in your projects, as with anything – do it for so long that it becomes a part of you, and you no longer need to think of how to do things the easy way.
How about you, are these tools something you use every day or do you prefer to use something completely different?
photos by lostinpixelation, MSA
Dave Schwantes should have drawn in a little more of that beer bottle in the middle frame of the cartoon…
Hey, I’m the guy who drew the Mount Saint Awesome comic (and I’ve also been doing a lot of work with Bower lately!). Thanks for properly siting/linking at the end. Also @Anon I didn’t really look at the 2nd frame that way until you mentioned it…