I was looking at bits and pieces of the Front-end work I've been doing at Praekelt, and I decided to gather them together in one place. I call it my preferred Front-end development process because I'm trying to be more of a grown-up these days and accept compromise on some of these points :).
(Also around as a Gist)
Front-end development process
I build web sites so that people can access them quickly and easily, regardless of the device they’re using, the type of connection they are on, or any disabilities they have. That means I build things with Progressive Enhancement.
The PE TL;DR is: a basic, functional, experience is delivered to everyone. JavaScript is not required for any key functionality (because all your users are non-JS while they’re downloading your JS).
Progressive Enhancement
PE is an approach to web development that aims to deliver the best possible experience to the widest possible audience, by putting the user first. It works by layering on the content (HTML), presentation (CSS), and behaviour (JavaScript) bit by bit. It means using feature detection rather than device detection.
I do feature tests in JavaScript (possibly using a library like Modernizr) to load in CSS and JS enhancements that match the capabilities of the browser. Different browsers will be served different experiences: they will be consistent and may be quite similar, but will not be identical.
Browser Support
I treat browser support as a continuum rather than a list of what is and what isn’t supported. Every device with a browser is supported, but the target audience will guide where most development time will be spent on optimisation. Rather than grading browsers, each component (in HTML, CSS, and JS) of a site is graded.
Internet Explorer is notoriously difficult. The amount of time spent optimising for various versions of IE should be determined by your user base.
Performance and Accessibility
I care about front-end performance and accessibility, so I run regular perfomance and accessibility audits using tools like Google’s PageSpeed Insights, WebPageTest, and pa11y.
I prefer fewer, larger, files over many, smaller, ones, because latency is more of a constraining factor than bandwidth. I make my files as small as they can be, and serve all content using gzip.
Images are one of the biggest performance problems, so I follow Lara Hogan’s advice. I use CSS instead of images where I can, choose the right image format, and make sure that all images are optimised. Depending on the use case, I use the picture element (with the Picturefill polyfill).
CSS
I make sure that I provide fallbacks for fancier features, like providing an rgb fallback whenever rgba is used.
I keep all my CSS in a few, minified, external CSS files. I don’t use inline style blocks (except for fancy techniques like Critical CSS) or write inline CSS.
I write my CSS like SMACSS. CSS is organised into: Base; Layout; lots of Modules; States. I keep selector nesting shallow, and never use IDs for styling.
I make sites Responsive by default as a Future Friendly measure.
JavaScript
I write unobtrusive, (harshly) hinted, JS. I keep all my JS in a few, minified, external JS files. I don’t use inline script blocks (except for small, minified, things that must be in the document head, like Scott Jehl’s eCSSential for asynchronously loading stylesheets) or write inline JS. I only include jQuery when really necessary, preferring vanilla JavaScript code and micro-frameworks.
I Cut the Mustard (test the browser’s capabilites using a small bit of JS) and serve less capable browsers just the core, lighter and faster, experience, rather than sending them lots of code they will struggle to run.
Deciding in the the browser
I prefer to move into HTML, CSS, and JS sooner rather than later so that I can test in browsers, on real devices, to make better decisions. I build Front-end Style Guides in an Atomic Design-like style (like Pattern Lab) with pieces that combine to become the site / app.