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.

Non-semantic HTML

(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>

Did we not learn that table designs are bad because they heavily couple the design of your page to the meaning of the document? Yet we're doing exactly the same here! I'm hoping that I don't need to repeat the lessons as to why separation between style and content is important (and also, between behaviour, which is the JavaScript part of our front-end design world).

This has real, negative consequences for our apps - they become harder to make accessible and harder to maintain due to the heavy couplings between these layers. And they are layers, there's no particular reason why some HTML by itself should not be able to represent meaning without a MVC JavaScript framework underlying it. The problem is that we've sacrificed client experience (unless our clients are using modern, fast devices on high-speed Internet connections) in order for fancy technologies, and in fact our same high-quality modern user experiences can be delivered using traditional progressive enhancement techniques, rather than the more brittle rich web apps that have become the standard in modern web development. (I recently upgraded from a Samsung Galaxy S2 to a Nexus 5, webapp performance on mobile phones is a real problem unless you're using the latest and greatest).

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.

JavaScript library management

(tl;dr - managing JavaScript dependencies still sucks, and Bower has fundamental flaws that limits it's utility)

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.

Bower's other big problem over putting packages in a vendor directory is the lack of first-class support for AMDs. AMDs are the single biggest improvement to JavaScript in quite a long time and take the pain out of front-end development considerably. There's an extension that'll output a require config for my vendored packages (yay, yet another tool I need to run somewhere in my build pipeline), but it's still not as easy as just dropping the minified files in a directory called 'vendor' and adding a path to your require config. And dependency management tools should make life easier, not harder.

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

Media Queries

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