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.
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 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
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).
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 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
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.