Front-End Developer Toolbox: How Does Yours Measure Up?
Front-end development in 2017 is a complicated and constantly shifting landscape of frameworks, trends, libraries and strategies. It seems like there is a new ‘must use’ tool every few months. It can feel as though you’re drowning in quicksand trying to keep your head above the latest trends.
When you look at your front-end tool box, do you feel more like Bob Vila or Bob Saget?
My must haves for a good front-end toolset are:
Lint or Debug program
(Note that there are many other tools not covered here, such as your choice of computer, your IDE and other software. For this article, let's just cover the libraries and frameworks.)
If you’re like me, you started theming websites using plain old CSS and, like me, you probably griped about how long it took to theme something like a dropdown menu with hover and focus effects. Thankfully, some very smart people got fed up with the way we were forced to write CSS and came up with the idea of CSS Preprocessing.
CSS Preprocessors take a specific syntax of code and transform it into modern, browser-friendly CSS. They enable you to write code faster, keep your CSS "dry", and use variables and functions that should have been in CSS in the first place. While each preprocessor has its own syntax and method for outputting CSS, they all function in a similar manner. A recent poll by SitePoint found that 86% of front-end developers polled use some sort of preprocessor, with the top three being Sass, Less and Stylus.
I use Sass as my preprocessor of choice because I enjoy the flexibility and code control that it offers. It also gives me the ability to include vendor libraries like Compass and Bourbon and their advanced mixins. The use of mixins, extends and placeholders, along with the ability to import one stylesheet into another, allows me to build components of reusable code and to write leaner, cleaner styles which makes things not only easier to read but more performant as well. With components, I can insert and alter complex functionality as needed with minimal effort.
I’ve been a jQuery guy since I started my first web project ever, but the increasing popularity and stability of frameworks definitely make them an attractive choice. React and Angular seem to still be fighting it out for position as the most popular framework but React is supposed to be a bit easier to learn and if you’re a Drupal front-end developer, getting to know React is definitely a good idea given the recent push to use React for Drupal’s administrative UI’s.
A good task runner is another key front-end tool. Task runners work behind the scenes to run scripts for spinning up development servers, compiling code, testing, concatenating and compressing files, and deploying code. Grunt and Gulp are two of the most common task runners. Gulp seems to be winning the popularity contest, but Grunt still has a strong user base.
Grunt focuses on configuration and is structured around a set of built-in tasks, with support from custom plugins in the community. Grunt tasks are completely independent of each other, which often requires code repetition because source and destination files must be specified per task. This makes Grunt a bit more work for projects with many tasks as well as making it slower than Gulp.
Gulp is built on streams and pipelines instead, and takes advantage of node.js to connect code and tasks into a seamless output. Think of it like the Sass of task runners. Gulp community plugins are highly-focused micro tasks that usually try to do a single thing. These plugins are piped together in a gulp.js file allowing them to be processed simultaneously, while Grunt processes one task after another. The Gulp processing method is also one of the reasons it runs faster than Grunt.
Skip the task runners?
A recent trend is to skip the task runner completely and use plain npm scripts. These are very small configuration scripts defined in a package.json file and run through the command line. The big advantage of npm scripts is that you are always up to date. If a package is updated, the run script will automatically use the updated version (unless specified otherwise). If the same package is used through a Gulp task, the newest version of the package would not be available for use until the Gulp dependency developer updated the plugin. The downside is that each npm script only does the one thing its designed for, unless you concatenate additional commands to the script, or add pre and post hooks to expand it. For complex tasks, trying to define enough pre and post script hooks to get a manageable command can get out of hand quickly.
I use Gulp in combination with npm scripts to compile my Sass, run Stylelint, spin up a local browser instance that syncs with any Sass changes, generate a sprite and Sass mixins from my SVG files, and numerous other tasks. Using Gulp with npm scripts means that I can run one command ‘npm start’ to kick-off all the tasks in my gulp.js, and any npm scripts I have concatenated to run on ‘start’ in my package.json file.
Think back over all the time you’ve spent trying to find a missing semicolon or unclosed bracket that brought a project to its knees, while you manually scanned 1000s of lines of code to figure out what you did wrong. Wish you had that month or so of your life back? Tools like Stylelint, ESLint, and your browser’s built in development tools will not get that time back for you, but they will help prevent that pain from happening again.
Stylelint and ESLint are command line lint programs that comb your code and compare it against a set of specified rules. You can write your own rules, use an existing library, or a combination of both. Your linting can be targeted to follow a set of best practices, just the rules you most care about, or help you overcome bad coding habits.
And if you don't know who Bob Vila or Bob Saget is, you're probably younger than me!