As has been said a million and more times, front-end development has a lot of moving parts. I won’t say too much about it, because I’m pretty sure I mention it in almost every post I’ve ever written (but I have a word count quota to meet here and it’s not a bad thing to drill down on repeatedly). New technologies, new plugins, new frameworks, new workflows… pretty much every single day. It can get pretty insane to keep track of and I know all too well the temptation to work with something simply because it’s new and shiny.
Setting the new and shiny aside for a minute, there are a few things that will never go away. It’s these things that I want to focus on today, because they’re consistent for a reason. They keep your new and shiny behaving responsibly and well-mannered. They’re the reason you can get away with going a bit crazy on your next build. They’re also something that most developers avoid like the plague, not because they’re horrible things to do, but because boy oh boy are they ever tedious. These beasts of burden are called process and workflow.
Related: Designers, Holidays, and Themes, Oh My! A Front-End Guide To A Good Holiday
Front-End Workflow
The excitement and adventure of front-end development quickly becomes trite and tired when you take into account the number of things you have to take into account simply to make sure your wicked awesome (read that in the voice of Ben Affleck in The Town for humour points) animations work properly when and where they can (and have an appropriate fallback for when they can’t). There’s prefixes including -webkit-, -moz-, -ms-, and -o-. There’s device dependant CSS properties. There’s the inability for certain browsers (cough-Internet Explorer-cough) that can’t handle more than 4,095 CSS selectors. There’s optimizations for CSS and JS to ensure their file sizes aren’t larger than that obscenely large screen covering banner image registering at 4096×2304 pixels.
Where this starts to get nasty is when you start trying to handle all these things manually. Attempting to backtrack and cover all these bases after you’ve completed work on your build only to find that it’s sluggish and only works on one browser can be emotionally draining. I’ve thrown together a couple things that I find help a lot during the process of building a site that keep these things in mind for me so that I can continue to focus on the new and shiny.
Too long, didn’t read (or tl/dr)- The following is a collective of tools I use to ensure my sites are optimized and browser compatible the whole way through the development process:
Grunt: Grunt, if you’ve never heard of it, is a task runner. With a community supported slew of plugins (or tasks) that can be used to automate your development process, it alleviates a lot of frustration. Magento 2 is set to be released with a Grunt task runner that covers many of the bases above. Learning about it and applying it to your 1.9/1.14 (or older!) installs now can go a long way to helping you understand how Magento is doing it in Magento 2.
Alternatives of note: Gulp, Broccoli
Source: http://gruntjs.com/
Grunt Plugins (Tasks):
grunt-sass: All of our modern projects use SASS as a CSS precompiler. With the depth and complexity that comes with a modern Magento front-end build, the original SASS compiler built in Ruby can be quite slow and sluggish. grunt-sass makes use of libsass, which is a SASS port written in C/C++. It’s blazing speeds help to ensure development is being done efficiently with less wasted time.
grunt-contrib-watch: You don’t want to have to repeatedly type ‘grunt’ every time you make a SASS or JS change do you? Sounds inefficient and against the grain if you ask me. grunt-contrib-watch can monitor different types of files, in different locations, for changes and execute a series of tasks depending on what file changed, and where. I use it for concatenating 3rd party js libraries, compiling SASS into CSS, and doing live refreshes of these files upon task completion.
grunt-contrib-uglify: White space can add a lot to file sizes. Keep your js files slim and trim by uglifying them as you go. Your work can be done in the original, expanded versions, while your code actually references an uglified (or minified) version of your custom javascript files during the development process.
grunt-contrib-concat: Juggling a collection of 3rd party js libraries to handle things like carousels or hover event debouncing? Having all these files pulled into one can reduce HTTP requests and cut down on file size. grunt-contrib-watch keeps an eye on my ‘js/vendor’ folder and when a new file is added, it runs grunt-contrib-concat to pull them all into one plugins.js file and uglifies out to plugins.min.js using grunt-contrib-uglify.
grunt-exec: One of my favourites, grunt-exec is quite simple. All it does is run a command in your terminal. In this case, because I had some difficulty getting grunt-bless to work, I have Bless (see below) installed globally and use grunt-exec to execute when a CSS document gets unwieldy with over 4,095 selectors (though I do make a conscious effort to avoid this happening).
bless: Due to some versions of Internet Explorer not providing support for CSS documents with more than 4,095 selectors, Bless will jump in a ‘split’ your CSS files into two (or three, or four, or… please don’t split this much). This will allow for IE to properly handle your CSS. Keep in mind, though, that this will add an extra HTTP request.
Source: http://blesscss.com/
grunt-autoprefixer: Earlier on I mentioned that there’s a number of CSS properties that require prefixing in order to have them work “across the board” (or as close as we can get to that). grunt-autoprefixer uses the caniuse.com database to automatically add the prefixes that are needed, and remove the ones that don’t, based on a config option wherein you set the browser support you’re actively providing.
Related: App – etizing eCommerce
My PostCSS Methodology
I’m currently toying with the idea of converting my whole process over to a postcss methodology, but once again, I’m running off in search of new and shiny. What’s your process look like? How are you using industry tools to make your Magento workflow easier and less cumbersome?
Related: Modern Browser Technology and You
The post Front-End Workflow: Ensuring your Post-Development appeared first on Demac Media.
