Project Management

Why traditionalists should take Web developers seriously

Justin James urges traditionalists to drop their prejudice against Web developers. He says that Web developers have the skills that even traditional applications will use in the future.

There used to be a sharp distinction between application developers and Web developers. This made sense when technologies such as Perl/CGI, classic ASP, standard JSP, and PHP ruled the Web development roost. But this distinction is becoming less relevant with the demise of Perl/CGI, the replacement of ASP with ASP.NET, JSP getting the full Java Beans treatment, and PHP being moved to an increasingly niche market and PHP playing an increasingly specialized role. Sadly, recruiters and hiring managers do not quite see it this way — and neither do many developers.

In the TechRepublic forums, many Web developers say they are often not taken seriously by people involved in more traditional development models. I think this attitude comes from the way many Web applications are architected. In reality, these applications are probably not true Web applications but rather dynamic Web sites. The dynamic Web site systems are written in a way that makes traditional developers shudder. These systems are not traditional, and it would be a mess to write a desktop application or server-side service the way these programs are written.

This is changing quickly. Over the course of the last year, I reviewed hundreds of resumes and interviewed dozens of applicants. I found that applicants who had not necessarily worked with Web applications were still a great fit for our positions — as long as they were starting in the middle tier and data access layers of the application. Out of the 10 or so developers we hired, only one is especially experienced in the presentation end of Web applications (HTML, CSS, JavaScript), and some of the others have "drag 'n drop" level experience within Visual Studio. This mix of experience is working out just fine.

Web applications are "icebergs" just like more traditional applications — only a small fraction of the actual code results in something visible to the end users. Anything below the presentation layer in a Web application is almost identical to a traditional application. The challenges are the same — the differences lie in how they are resolved. For example, in a Web application, the Web/application server automatically handles the multiplexing of incoming connections; the consequence is that you need to learn and work with the assumptions that the Web/application server performs that multiplexing. (Concurrent access to session data immediately comes to mind as an example.)

The presentation layers are getting more and more similar. The WPF replacement for Windows Forms in .NET brings the declarative markup language syntax to desktop applications (for better or worse). Silverlight makes the XAML syntax work for Web applications, which unifies the presentation layer for Windows and the Web. Frameworks and techniques like OpenLaszlo, Adobe AIR, and AJAX are trying very hard to allow Web applications to look, feel, and behave like traditional desktop applications. I believe that trying to put that type of functionality on top of the HTTP protocol is a bad kludge at best, but my opinion seems to be in the minority.

I think these systems are train wrecks, and TechRepublic readers seem to agree with me based on their feedback. Even if you're not a big fan of things like this, Web services are here to stay. As a result, even if these systems do not gain much traction, the trend towards RPC-type functionality over the HTTP protocol is only getting bigger. This means that even traditional developers are dealing with Web services and that they often replace their proprietary communications between client and server with Web services. The end result is that, even where the presentation layer relies upon native GUI API calls, the architecture is (for all intents and purposes) an N - 1 tiered application.

Traditionalists need to drop their prejudice against Web developers because Web developers have the skills that even traditional applications will be using in the future. As we head towards the point of inflection between client/servers applications and Web applications, shops that rule out Web developers as second rate will find themselves increasingly unable to hire talent or even compete.



Justin James is the Lead Architect for Conigent.

Editor's Picks