cms
It's sad but true. The gap between back-end developers and front-end developers remains. In my plea to trust your htmler I focused on the importance of the work we do, I'll take this opportunity to get a little closer to one of the core issues tearing our priorities apart. Rather than target actual developers here (this article is meant to build bridges, not destroy them), let's see what drives them to discard our sweat and tears in favor of html poo.
Initiatives like Fronteers surely help our cause but to make this marriage work there has to be effort on both sides of the fence. Awareness of our job alone won't fix this somewhat awkward situation, it demands a more structural change in how web projects are developed. Our tools prove crucial in this process and that's exactly where things go wrong.
content management system
Most sites these days are built using external CMS systems. From small-scale projects using WordPress, middle-sized sites using Drupal to corporate monsters using Tridion. Static sites or sites using custom-made CMS systems are rare these days which is not that surprising considering the complexity of building a quality site. Most CMSes offer lots and lots of out-of-the-box functionalities that make the life of a developer a lot easier.
Content Management Systems these days do way more than simply managing content. The WMS-hype has long since gone, but in fact Web Management System is a much better description for the functions of a modern-day CMSes. These CMS systems are life savers, at the same time they are most often the biggest limiting factor within a project. While coping with all the complexities of setting up a site most CMSes lock themselves down, limiting flexibility in order to assure a working-out-of-the box experience for the layman.
And while I do understand the need for these simplistic solutions, locking out the pros to do a good job is definitely not the way to go. You won't hear me say this is an easy task to accomplish, front-end development doesn't know too many best practices and even those are often contested by different groups of people. The fact remains that if I deliver a set of static templates, your system needs to be able to implement these templates flawlessly. No questions asked.
cannot modify stuff
The truth is that most default implementations of a CMS fall short when it comes to front-end development. There's html-code vomited from the core of the system, css handling is handled in the least efficient (even faulty) manner possible and coding structures dictate how html pages are structured. If you want to know what kind of CMS people are using, it often suffices to look at the html source code. This is of course plain madness.
If you press hard enough you'll learn that most CMSes do offer the option to override html and you can often tweak the html code to perfection. Either the knowledge to do this is too limited or the CMS itself makes it too difficult to accomplish this within the confines of a project, but the result is always the same. Your meticulously developed templates are thrown overboard or they're used as a general guideline rather than a blueprint. Previous css work becomes obsolete and you'll need every trick in the book to cook up something that somewhat mimics the original design.
consumers must suffer
A website should be user-centered. And by user, I mean the people visiting your site, not the ones entering content. Your visitors interface with the front-end, meaning html, css and javascript. Messing this up is simply not an option anymore as it will visibly decrease the quality of your site. If a CMS is poor at html output you need to grow experts to bypass these problems and/or you need to budget this from the very start. Out-of-the-box solutions are good if you want to set up a quick, private initiative, but they simply won't do for corporate sites and professional projects.
Some people seem to believe front-end developers spend their days happily tweaking html and css, only to go back to Fairyland every evening to play with the magical animals and sing jolly songs while dancing in the middle of flower fields. I can assure you this is a far sniff away from reality. The fact that our work is often discarded because it's too difficult to implement into some or other automated system definitely doesn't help. I don't believe it's wise to start pointing fingers, but I hope it's clear by now that this is counter-productive and doesn't help the quality of the final product.
slowly but surely
Truth be told, CMSes are slowly changing to accommodate to the needs of the front-end developer. Drupal 7 should make a serious leap forward (when it's out of beta), SharePoint 2010 has dropped most of its tables (hell yeah!). Still, the need for skilled html skinners remains, no matter how hard it is to accomplish in the system of choice. If CMSes want to becomes WMSes they should remember that outputting html is a key feature and flexibility to change and adapt code is a priority.
If outputting custom html becomes easier developers should have little trouble implementing our work into their CMS of choice. Whether this is a definite promise remains to be seen.