Component-Based HTML: A Glimpse of the Future
The Web Dev Zone is brought to you in partnership with Mendix. Discover how IT departments looking for ways to keep up with demand for business apps has caused a new breed of developers to surface - the Rapid Application Developer.
Even though the entire web dev world is battling the impact of responsive design (me included), these past couple of months (maybe even years) I've been looking elsewhere to satisfy my front-end itches. Not that I think responsive is a minor issue, it's just that I believe there is more to web development than quick wins and rapid progress. My ultimate pet peeve is structured html and I'm more than excited to have finally found a big forum willing to support me in spreading my ideals.
Yesterday Smashing Magazine ran The Road To Reusable HTML components, an article I've been working on for quite a while. It's a plea to spend more time on writing sane, reusable and solid html packaged as a hands-on, practical rundown of my own methodology of writing html code. The article is pretty detailed so if you haven't read it already I propose you do so first.
Writing your own html (snippet)library is clearly only the beginning. More and more you feel that our industry is going to face one of the biggest conflicts/challenges it has ever known. On the one hand specialization is needed. Even something "simple" as html requires a lot of knowledge these days, especially if you're aiming for semantic value, reuse of code, accessibility and whatever else comes with the territory. Getting all these things right takes time.
We need ways to speed up our development, but in such a way that we can keep guaranteeing quality.
Writing component-based html is one step in the good direction, but it also stands at the base of a whole lot of other possible innovations. When you write basic visualizations for each component (whitelabel css) you have a model that works in the browser as soon as your html is finished (back-end devs appreciate this).
If you make an abstraction of your components, you can even develop a tool for wireframers to compose their wireframes using your components. The whitelabel css will visualize everything for them, add some basic responsive models and what you have is a responsive wireframing tool that outputs production-ready html. Sounds too futuristic for you? Well, not really. Save some details that's how we are coping with front-end development at my current job this very moment. Not everything works out of the box of course and conceptual wireframing is still best done in a specialized tool, but once it comes down to drawing detailed wireframes for every page, this sure comes in handy.
One thing is certain though, this is only the beginning.
We need to eliminate repetition and brainless actions from our daily work. The time I spend on composing page templates based on html I've already written is time I should spend on investigating new techniques and making sure my components can withstand various demands: enriching them with accessibility measures, semantic value and visual/functional variations. These are the things that really need our attention. In short: spend your time working on your library, not on laying out page after page after page.
The more monkey work we can reduce or even make redundant, the more time we can spend focusing on overall quality. And the way I see it, we're definitely going to need that time in the near future.