The state of front-end web development has changed significantly over the last couple of years. Perhaps it was the introduction of responsive design in early 2010, the release of a retina iPad and, shortly thereafter, the retina Macbook pro in mid-2012, or Adobe “killing” mobile flash in late 2011 that prompted the change.
A few years ago, a front-end developer title often defined the term “developer” rather loosely. HTML and CSS were often the only required languages for this role and are really considered to be content markup languages rather than true development languages (however you might choose to define that). A few years before that, we were building websites purely with HTML and images, using tables to implement our layouts. A lot has changed. If you are interested in learning more web history, check out Eric Meyer’s excellent podcast, The Web Behind.
Regardless of what actually prompted this recent shift, I believe there are (at least) two major reasons that the front-end developer role will continue to be significant for quite some time:
- CSS and image support has gotten much more powerful and complex.
CSS3, Retina Images, and Bandwidth, Oh My!
The CSS3 spec added lots of very powerful new features. Things like rounded corners, shadows and gradients can be achieved easily in browsers that support CSS3. There are also more advanced features like CSS transforms and animations which require a bit more knowledge about things like keyframes and perspective. Specific browser prefixes must be applied for many of these new features in order to ensure backwards compatibility as the spec continues to evolve.
Of course, the downside to all of this is that CSS code has become hard to maintain. Fortunately, CSS pre-processors have been created to help make CSS code more maintainable and object-oriented (ish). Sass and LESS add features like functions, variables and mixins as well as code libraries (Sass has Compass). Sass does seem to be gaining in popularity for a number of reasons, but the point is that this is one more tool for a front-end developer to learn.
A hot topic in the front-end developer community at the moment is debating how to support images across different devices, resolutions, pixel densities and varying connection speeds. The increasing consumer use of retina-density displays and better internet access from smartphones requires developers to think about how to potentially support multiple sizes of higher quality images at lower file sizes. There are many solutions for supporting higher resolution images on retina displays. You could detect a retina display and serve up double resolution (@2x) images for those displays. This requires two versions of every image to be created which isn’t so bad. The problem is that a device like an iPhone has a retina display as does something like a Macbook Pro. The Macbook Pro could be connected via Ethernet to a fast connection and the iPhone may be on 4G now, but in seconds, it could be down to an edge connection as the user moves away from the nearest cell tower. This article does a good job of explaining the pitfalls of trying to measure or predict bandwidth at the CSS level to serve up different image sizes. So, there is some added complexity that comes with more mobile devices and retina displays.
In addition, any image, whether it’s targeted at a retina screen or a smartphone, should have as small a file size as possible. Tools like:
can do an amazing job of reducing file size while maintaining quality. Even with these tools, a great deal of manual effort is still required to make sure that the images maintain quality once compressed.
These are very exciting times indeed for front-end devs. So much new technology is being released that the door is wide open for innovation. I’m just excited that we are no longer using table layouts.