While back-end technology has become more and more abstracted and powerful with frameworks like .Net, Rails, and their Java counterparts, the possibilities with front-end technology have grown increasingly complex. The web needs more front-end architects before poor implementations of front-end technology hobble the potential benefits of recent advances.
Thanks to things like better cross-browser support of advanced technologies, an increased focus on user experience, and a greater awareness in topics like accessibility, it’s no longer as simple as HTML & CSS, and almost any team needs someone that truly understands and is experienced with everything that touches the front-end.
The Person
This isn’t a short or simple list, and while a front-end architect shouldn’t know each of these topics inside and out, they should know enough to discuss the finer points of any of the following:
- XHTML
- CSS
- Cross-Browser and Cross-Platform Compatibility
- DOM Scripting
- AJAX
- Flash
- Progressive Enhancement and Graceful Degradation
- Accessibility
- Usability
- Information Architecture
- Interface Design
- Visual Design
- Presentation Logic (ASPX, Rails Views, etc.)
- Business Rules & Logic*
Being a front-end architect requires a strong command of each of these areas. For instance, they need to be able to decide whether a certain feature needs AJAX or a conventional page refresh. Which is more usable? How does it affect accessibility? Does it make sense to use flash instead?
Cleaning Up the Mess
Intermingling presentation, structure, behavior, and business logic leads to unnecessarily complex and twisted solutions that are difficult (Read: Expensive.) to maintain. Just like the back-end needs to be properly separated into a database access layer, business logic, presentation logic, etc., front-end development is now sufficiently complex to justify its own architect.
it’s not enough to write good markup, or avoid using tables. That was the first step. That was front-end architecture 101. Now it’s time to focus on DOM Scripting, AJAX, Accessibility, and the next level.
Programming is a Must
While many might consider themselves front-end architects, I’d argue that true programming knowledge is the one requirement where most fall short. I’m not talking about being able to cut, paste, and hack code, but rather the ability to have an educated conversation with an experienced engineer on how to best integrate with the front-end.
This means really understanding the point where the markup meets the business logic. If an engineer says that something is impossible because you can’t do it with an ASP.Net DataGrid, a front-end architect should be able to show them how and why to use a DataList or a Repeater instead and explain why the DataGrid is the wrong choice for the situation..
That’s just one example, but the point is that knowing the client-side code isn’t enough. Being able to speak on the same terms as the engineers and discuss the best solution for the critical integration points is an absolute must.
The Current State of the Disconnect
The reason we’re in the state we are today is that so few people truly bridge the gap between front and back-end. The average engineer has little to no interest or experience with markup, CSS, or DOM Scripting, let alone accessibility or typography. On the flip side, most client-side developers have little to no true experience working with the back-end technology. A few weeks of PHP does not make one a programmer, and a few weeks of XHTML does not make one a serious client-side developer.
The Culprits
Right off the top of my head, I see ASP.Net’s initial and complete disregard for web standards and Websphere’s equally dismal use of web standards (We’re talking tables and spacer gifs here.) as being the perfect examples. These are huge frameworks used on enterprise projects that output markup that would look bad even by 1999 standards.
How is it possible that such large and “professional” products could ignore what is arguably the easiest aspect of the whole project? The static code. The reason is that, while I’m sure both products are great from a technical standpoint, the markup, CSS, and other client-side technologies were a complete afterthought. Presentation logic, markup, and behavior are all intermingled with nary a thought towards accessibility, web standards, or clean separation of the front-end technologies. Raise your hand if you think that’s an acceptable practice in 2006.
Summary
If some of the highest profile products and projects in the world are doing such a poor job of getting things right, how many others are falling short as well? There is no doubt in my mind that there is a need for front-end architects, and we need them yesterday.
When it comes down to it, we have a bundle of technologies that are inter-related with very few people really digging in to understand the relationship between them all. Unfortunately, the real value of doing something correctly is the ease of maintenance and long-term adaptability, and in the heat of the moment, it’s easier to just look the other way and slap something together. For some, that may be an acceptable way of doing things. However, for most of us, that’s a poor decision, and generally unprofessional.
I’ll leave you with this thought. If you dropped your car off at the mechanic, had some repairs done, and then looked under the hood to see copious amounts of duct tape, what would be your opinion of the mechanic?