What sucks about front-end development
Front-end development still sucks, and it’s not only because of cross-browser compatibility, it’s also because of the tools we’re using. There are 3 areas that consistently cause problems for me, and there’s no way I’m the only one.
(tl;dr — table designs are bad, so why are we re-implementing them with non-semantic class names? We should use our CSS frameworks to have only abstract classes that we make concrete by extending them with semantic class names. Also, progressive enhancement isn’t dead and still has value.)
As I’m redeveloping Manchester.IO I’ve decided to use a responsive grid (specifically Gumby), mainly because it makes life easier, and secondly because it’s best practice and will probably result in a better looking site. That’s fine, but why does every single Sass/Less framework suggest first in the documentation that you should write your HTML like this?
<div class=”row”> <div class=”col-4">I’m some content!</div> <div class=”col-4">I’m some more content!</div> <div class=”col-4">I’m the last content on the line!</div> </div>
What I would like to see is a Sass framework that only provides mixins, and no concrete classes themselves (apart from maybe some reset and base typography rules). You’d extend the abstract ones with your semantic class definitions (maybe every section is a row, etc, whatever makes sense for your desired outcome). But ultimately, you should be able to take a reasonably defined HTML document and then style it how you want without making anything but minor changes to the HTML. At the very least that’d avoid situations like this one:
That’s over 200k of unused CSS being downloaded in my case, just because I decided to use Gumby.
What’s the best way we’ve got of managing vendored assets right now? Until recently, it was downloading zips and copying them into our project, but yay for Bower! Except Bower suffers from a fundamental flaw, in that it conflates the unbuilt source of a front-end library with the built version. Sure, frontend components are generally interpreted rather than compiled, but we often still want to do some post-processing to it (thankfully the Bower devs have already acknowledged that this is a big problem, but as far as I can tell there’s no immediate plan to fix it.
(As an aside about Python — I do most of my non-work web dev in Python nowadays, but Python’s setuptools doesn’t even pretend to know about any other languages, some sort of post-install hook would be nice, so it could run, e.g., Bundler, to install Compass/Sass, etc.)
(tl;dr — screen sizes don’t necessarily imply a device class directly, but that’s what we use it for)
Media queries are being used for things they were never intended to be. Just because a device has a small viewport doesn’t necessarily mean that it’s a phone, but that’s the inference we make (as we’ve got no other detail in which to make that determination, short of doing user agent sniffing), so we make our touch areas bigger because we assume it’s a touch screen device, and all sorts of other things, but it’s all just a guess. For example, what happens if the device is currently running over a mobile data network? Maybe we don’t want to fetch retina images to save on data allowances, perhaps we’ve got a device that’s controlled using a 5-point remote rather than a pointer and want to lay out our user interface differently.
I consider myself to be a “full-stack” developer, rather than just a front-end specialist, so maybe I only feel these issues because I’m comparing it directly to other parts of the software stack rather than considering the front-end in isolation, but front-end development still feels very immature and like the wild west, rather than the engineering discipline we’re striving to be. We need to make it better.
Originally published at www.pling.org.uk.