I’m always trying to find new ways of making the front-end development workflow easier, faster, more structured, and more maintainable. As the web environment is becoming more complex, we need to embrace the tools and use them to help us create a good architecture that allows us to concentrate on the task at hand.
Everyone has his or her own coding style and preferred ways of working. The web evolves rapidly so changing our mindsets and constantly adapting to new ways of thinking and working is a must for front-end developers.
Frameworks and Boilerplates
I’ve studied dozens of boilerplates and frameworks, from the most popular ones to lesser-known ones, to see how some of the brightest minds in the industry approach common front-end tasks. A lot of research, hard work and talent has been put to these frameworks and I’ve adopted many ideas, best practices and snippets from them. But while they help a lot, still none of them alone can solve all the issues we encounter in our daily development work because each project has different requirements. Many frameworks have accessibility barriers, or simply try to contain too much and solve too many problems at once, pre-defining every possible component or grid variation. These frameworks are good for prototyping because they offer generic catch-all solutions.
Then, on the other end of the spectrum, you have simpler boilerplates that only contain the bare minimum, maybe just a few files to get you started, lacking integrated build processes or assets you often need in your own project work. What I’m mostly interested in is finding the workflow that doesn’t assume too much, but at the same supports the most common development, test and build tasks, and suggests methodologies that help creating modular and maintainable code.
My Project Workflow
When you start developing for production, you have to think about your actual project requirements. At that point, you probably don’t need half of what these ready-made frameworks offer. Instead, you’ll want to start clean, reuse and add new code only when you need it.
Front-end development tasks often include creating, copying and deleting folders and assets, preprocessing code, testing it, linting it, concatenating and minifying it, managing dependencies, generating documentation, and adding timestamp for version handling. You might also want to generate icons and compress your images.
So I’ve created a Grunt-based Front-End Workflow on GitHub where I’ve also added some boilerplate code. My goal was to establish a minimal base workflow that contains the basic tools, methodologies and assets that I often need when I start a new project. Depending on the project, I can then adapt or extend that framework to support any project requirements.
From my experience, the base workflow needs the following:
- Structured architecture that supports frequent isolated changes (Agile!)
- CSS methodology
- Responsive techniques and oldIE handling
- Image compression and icons handling
- Automated testing in different browsers
- Build process that supports various loading strategies
- Livereload (nice-to-have)
- Fluid grid (nice-to-have, you probably need a grid but it shouldn’t be pre-defined)
With that list, it’s obvious that my base development workflow contains more than what the word “base” implies. It’s also slightly opinionated as certain tools are included while some others are not. But if you think of it, it has to be a bit opinionated because this is the setup that I like to use. It’s work in progress and might and probably will change in the future as new tools and methodologies emerge. But for now, it takes care of the tasks that I regularly need, listed earlier in this post. Core technologies are Ruby, Sass, Compass, Node.js, Grunt, SMACSS, OOCSS, and Karma test runner. The goal is to support code reuse, modularity and Responsive Web Design.
Share on Twitter.
Partial Credits & Inspiration List
Partial credits & inspiration list of the resources I used to create my Grunt workflow:
Sass and CSS
- OOCSS, Media object, Flag object
- About HTML semantics and front-end architecture
- CSS Architecture
- Essential considerations for crafting quality media queries
- Don’t use IDs in CSS selectors?
- Mobile first CSS and getting Sass to help with legacy IE
- Sass IE
- scss toolkit
Frameworks and grids
- Fluid Grid with Sass
- The Semantic Grid
- Building a Nested Responsive Grid with Sass & Compass
- Building a modern grid system
- One Web Boilerplate
- HTML5 Boilerplate
- The real HTML5 boilerplate
- HTML5 Mobile Boilerplate
- 320AndUp, and more recently, Rock Hammer
- ZURB Foundation
- Twitter Bootstrap
- Developing Backbone.js Applications
- Backbone.js & RequireJS TodoMVC Example
- Backbone Boilerplate
- Backbone Boilerplate with multipage RequireJS Setup
- Requirejs multipage-shim example
- RequireJS example.build.js
- Grunt task runner
- Testing Require.js code with Karma
- iCITA‘s ARIA Examples
- The DSGWG recommendation for keyboard shortcuts to be used in website widgets
- Filament Group GitHub repository
- Accessible Patterns
(Plus many other resources I probably forgot to include here.)