Loading...Web Development
Front End Web Designers, Developers and Engineers
The always excellent Nate Koechley has posted a must-read presentation on Professional Frontend Engineering. The timing is great, since this is something I’ve been thinking about a lot lately. In particular, since I had just recently read Jeff Croft’s Who Owns JavaScript over at Blue Flavor. The comments alone on Croft’s article are worth the read, and if you haven’t taken the time to read Koechley’s presentation, I suggest you do so now. I know you’ll come back, I can trust you … right?
Back? Ok.
Front End Architecture
I’ve long been a fan of Garrett Dimon’s article, The Time is Now for Front-End Architects. It’s something I’ve been advocating, that I spoke about in my recent presentation, and also wrote about in the book.
What am I talking about? I’m talking about treating front end Web development as a first class citizen in Web building, at every layer and every tier, from design to backend software’s user interface layer.
Who Owns JavaScript
Croft’s article is an excellent discussion about in-house Web development teams and how the world of JavaScript seems to always be bestowed on Web designers, even though programming isn’t necessarily their forte.
The argument is typically that in-house teams are usually comprised of front end designers and back-end programmers. Designers are unfairly expected to be hard core designers, JavaScript programmers, as well as HTML and CSS guru’s.
And a lot of designers just aren’t there.
Modern Web Development Teams
Web development is a new software practice, and being a young industry there’s some problems still:
- we don’t know what to call things (job titles)
- Web design and development features different and new subject matters and responsibilities (job descriptions)
The structure I’m most familiar with is three levels: Web designer, front end developer, and back-end developers. Now, nuances and team structure around a career arc and so forth vary and I haven’t even fully arrived at my conclusions, but I think it’s the only model that makes sense. Let me explain why.
There’s an argument that says Web designers should “know their medium”, that being HTML and CSS. I believe this. However, being that I do some front end work, and some back end work, I think each layer is critical to the user interface of a Web site. Someone needs to fit at that intersection between the software and the design. Things are getting sufficiently complicated on the front end that it takes a lot of effort to get it just right.
One might also argue that there’s a fourth layer: Web Content Management. But that’s another article.
Responsible for Code in the Browser
Nate says that a frontend engineer is responsible for “View Source”. I’ve been saying front end Web developers are responsible for everything that is sent down to the browser. I like “view source” since it’s a concise and easy to state idea which is a common terminology. It’s easier to say, for sure.
I’m using “front end” and “frontend” both, because, frankly, I don’t know which is right. I never have. Opinions?
What Makes an Engineer
I think the distinction between a front end Web developer or designer (CSS, HTML) and an “engineer” is a fine line, but an engineer is going to take it to the next level.
An engineer will concern themselves with server-side architectures which impact the browser, the structure of a Web page and how it impacts performance and so forth. They’re going to work with JavaScript libraries creating reusable objects, create namespaces and structures which make sense, follow modern, unobtrusive techniques and avoid global variables. They’ll be concerned about accessibility, progressive enhancement, how server-side code renders the Web page’s user interface (UI), the data transport layer involved in Ajax, and configuring technologies such as HTTP compression.
I think there’s a place for front end Web designers and developers who concentrate on HTML and CSS, but I feel like the engineer is the next step up on the ladder.
Freaks
There are “freaks” (I call them freaks because they’re unusual and rare; also highly prized) that are capable designers, programmers, and can do just about everything. These guys are rare, and you should grab them up and hold on to them as tightly as you possibly can. They’ll have a unique perspective.
But the point is, they’re the exception to the rule. There’s so many blogs and Web sites of people out there talking about this stuff, it’s easy to fall into the trap of thinking that these people are commonplace. Trust me, I’ve placed job ads and seen resumes and tried to hire these people: they’re rare.
Fundamental Problem
The issue is that (most — there’s always exceptions) traditional server-side programmers don’t know and don’t care about the Web browser very much. Some guys I have extreme respect for have said to me, “I don’t know” when asked what server-side chunk of code output what client-side code. Some of these guys don’t even look. They don’t “view source”. Can you blame them? They’ve got high end business rules and logic and applications to just get working.
Even the folks that develop most modern frameworks don’t care about the browser very much. Most examples for ASP.NET just suck. How can you not care about your medium?
Someone’s got to.
Going back to Croft’s article the problem is this:
- UI / UX Designers: they don’t necessarily know programming
- Server-side developers: they don’t necessarily know Web browsers
Knowing the Web browser is critical to building a responsive, accessible, well designed, scalable, well structured Web site or Web application in 2008 and beyond.
Someone’s got to know the browser.
Jun 12, 11:56 AM in Web Development (filed under Web101)
Possibly Related Articles
Commenting is closed for this article.
Robert Jun 12, 01:24 PM #
My first impression was to say that the designer ought to be doing everything from Photoshop to CSS to PHP. Then I got down to the “Freaks” section and realized that’s where I fall in. At my current job, I’m the only web guy, and I work best having the project from start to finish. I’ve found this is the most agile way to work and provides the best finished product.
I’ve worked at different places in different roles in the more traditional style you discuss. I’ve been the designer + HTML / CSS / JavaScript coder with a separate PHP guy doing the brunt of the back end. I’ve also been the PHP + Javascript guy with separate Designers and HTML / CSS coders.
In the first situation, we were doing an “intranet” site. In the beginning, it was very difficult to maintain any sort of code quality in the HTML side. I would write nice templates, but his PHP spit out garbage. I was able to get him to improve the quality over a year, but it was never like what I’d be writing.
Eventually, I was able to work it out so that we used AJAX. All the PHP guy did was spit out valid XML / JSON, and I was able to insert data into the code based on that. It turned out to be pretty agile. I’d give him specs on the XML to output, and he’d program for that. I’d test on the sample files I’d given him. We were able to develop in tandem without having to check against one another.
However, that wouldn’t work for most sites.
At the job where I did PHP, we were incredibly slow to complete sites. The designer was a graphic designer doing his first real web jobs. So, the designs were naive a lot of times. Lots of useless flair-for-flair’s sake like we all do in the beginning. We would have to go through several internal iterations just so we could have something that could actually be turned into a web site. That in combination with bad management would have the front end and back end coders doing 90% of the total work in 10% of the time allotted for the project.
So, I guess my point is this: If you want to ensure that you’re going to have a great product, make sure the back end coders know how to write good HTML and make sure your designers can code HTML (even if they don’t have to as part of the job).
I don’t think either is asking too much. HTML and CSS aren’t hard. Doing them well is hard, but simply writing valid mark up (if you’re backend), or knowing whether something is possible and cost effective in HTML / CSS (if you’re frontend) isn’t hard. It just involves not being lazy and taking professional responsibility.
That last sentence is the rub with me, though. If you aren’t lazy and you care about your profession, you should be dabbling in PHP (or equivalent), CSS, HTML, JavaScript. You shouldn’t need a PHP programmer to write, e.g., a contact form. I mean, how many people does it take to screw in a light bulb?
Granted, it took me a year or more before I felt comfortable enough with my PHP skills to use them in a production environment beyond simple things, but I dabbled and worked at it until I got there BECAUSE I love what I do and I want to be the best at it.
Maniquí Jun 12, 08:56 PM #
I’ve recently (in fact, some minutes ago) discovered this blog.
Excellent article.
Sadly, I don’t fall in the “freak” category, and that makes me feel bad some times. So, reading that “freaks” are uncommon, makes me at least feel less bad :).
I’m a jack of all trades, but I consider myself pretty good (a “half-freak” maybe) at HTML and CSS, being able to have almost pixel perfect layouts (and at the same time, I know that pixel perfect isn’t really the goal if you are in this business), writing solid CSS hacks-free, coding über-semantic, valid, clean, standard HTML.
Of course, I’m still learning in every field. A little of JS/jQuery, a little of Django/Python (it’s what we use here at work), almost nothing of PHP, but I’m fan and lover of Textpattern since many years ago ;)
Robert (the above commenter) is the kind of developer I’m pointing to be one day (I hope it will be soon).
Again, right now, I’m just a jack of all trades (even, I’m over-intoxicated with web development articles about state-of-the-art techniques, best practices, progressive enhancement, accessibility, usability, SEO et all).
I hope I can capitalize this any time soon.
In the meanwhile, I’m just the man in the middle…
Sorry for my english…
Lynn Cherny Jun 15, 01:47 PM #
At Excite, oh so long ago, we understood this distinction. The front-end web developers lived in the same group as HTML/visual design and UI design. Sadly, I forget what they were called. But the group as a whole was called PAD – production and design, I think.
cody lindley Jun 18, 09:57 PM #
Its simple, just not accepted. Web teams should be divided into two groups. Creative and Engineering.
The creative group is made up of visual designers and interaction designers.
The Engineering group is made up of types of engineers. I’d say there are four types. – flash engineer – client-side engineer – server side engineer – DBA/Server engineer
In my humble opinion designers should not be responsible for engineering tasks. There are very few people who are great designers and great programmers. However, if you listen to the job market you’d think that everyone should be able to craft an interface and at the same time be versed in programming. Its ridiculous.
Seo Web Traffic Jul 23, 09:10 PM #
about Nate’s presentation I’m glad that he and generally the industry as a whole is coming to the conclusion that Frontend Engineering is more than just HTML + CSS. We need more evangelists and organizations to take up this cause and push our profession forward. I wish I could have been at your presentation to hear more of your thoughts, it looks like a great one from the slides.
Great post!
Cheers,
Blake