(This is a sequel to my Coders and Professional Programmers article)
I'm fairly sure the year was 2001. It was before I did my transition from coder to professional, but it was long after I became a real web developer (1994). This was the year that the web became severely corrupted by an influx of thousands of MFC/VB developers thinking they were web developers simply because they knew how to drag-n-drop a control onto a canvas and make something appear in a web browser. The influx was, of course, due to the release of ASP.NET. These people were not web developers and that same coder-mill continually throws out unprofessional after unprofessional today. This was the year I got so upset with the pragmatic, unprofessional web developers running around taking my work that I retired for 3 years to go back to college.
So, what is a web developer? Surely is at least one definition per person in the entire industry, but I must say that, at root, it's a person who understands and can proficiently interaction with web technologies. What web technologies? Today, these include, at a minimum, semantic XHTML, CSS, and Modern JavaScript. In a sense, you could easily mark these as the pillars of web programming. Without academic and hands-on knowledge of these technologies, there is no web devolvement (yes, both are required-- and despite what the pragmatists think, the former is critical). Furthermore, this technology list changes over time. If I were to retire today, I have no right to come back in 5 years claiming to be a web developers. To be a web developer at that time, I need to learn a new X, Y, and Z in including their guidelines and best practices. You must keep up or be left behind.
Having said that, PHP, JSP, and ASP.NET developers often inappropriately call themselves web developers. Not all PHP, JSP, or ASP.NET developers are like this, especially PHP developers! Respect, respect! In any case, I can kind of see the confusion here, but even still, a quick realization of what these technologies are should have killed any thoughts of this a long time ago. These people work with server-side technologies, not web technologies. The same CGI model used 15 years ago is the same model today. The only thing these people are doing is creating code that runs on a server and shipping the output. Period. That's not web development; this is the same work you would do if you were to build an Excel report. It’s just work behind the scenes that may or may not touch a web browser. Even then, just because it hit a web browser, doesn’t mean its web development. There’s no client-side technologies involved at all. Without deeply interacting with client-side technologies, there is no web development. In fact, the inanimate object known as a web server is more of a web development than server-side-only people.
Web development begins at the point when you begin to ponder the technologies and implementation from the perspective of the client-side. I'm sure most people won't believe me when I say this, but I did web development for my 4 years of high school before I even knew that you could use server-side software to dynamically create pages. Everything I did was in pure JavaScript and fancy frame manipulation. This was web development. I didn't need CGI or Perl. PHP, JSP, and ASP.NET simply sends out a stream and it just so happens that a web browser may be the one making the request. The output may be for a web browser, but that in absolutely no way makes it web development. That's like going to a foreign country and using a translator device and saying because you have that device, you speak the language. You in absolutely no way speak the language! Worst, some people will defend, virtually to the death, the idea that they do speak the language simply because they know a few words to "fix" the translation! We see this in server-side-only developers who, because they know a few HTML tags, think they know the technologies.
Most of the time, however, server-side-only developers really think they are web developers. So, this simple and obvious explanation won't do. Therefore, we are forced to make a distinction between web 1.0 and web 2.0 developers. We often think of web 2.0 as being quick, dynamic, and smooth client-side dynamics. This is from a marketing perspective, but it's hardly a definition that satisfies the computer scientist. The distinction I use is actually a bit more straightforward: web 2.0 development is development from the client-side perspective. This definition actually reminds me of the definition of a series I learned in my Real Analysis class in college: a mapping from N to R. How in the WORLD is that a series!? Isn't a series a set of entities or something? Well, somehow it's a mapping from N to R (I've yet to hear another professor give this same definition, but the point is that "formal definitions" in mathematics rarely look like their application in reality).
When I talk about web 2.0 to a colleague or a client I'm talking about web-specific design and implementation from the perspective of the client. From this perspective calls are made to various services for interaction with outside data. In other words, web 2.0 is a client-service model for the web. In this sense, what is web 1.0? Just the opposite: development from the server-side perspective. This is ASP.NET development, for example. When you are working with ASP.NET, you are working from the perspective of the server and you send data out. In this model, you have a logically central system with entities accessing it. In reality, this isn’t web development—it’s development of something that may or may not do web development for you. Web 1.0 is a server-client model for the web (notice the word server, instead of service—as seen in the web 2.0 model) If you are a deep Microsoft developer you recognize the web 2.0 paradigm: WPF/WCF allows you to easy create a client-service model bypassing the client-server model all together. You create your client interfaces in WPF and access WCF servers as you need them.
In this perspective, what does this mean in terms of the actual technologies? Well, almost all my web applications are done using the web 2.0 model. That is, all my programming is done from the perspective of being inside the web browser. I'll directly modify the DOM and access data via AJAX calls as required. Some of my applications are pure-AJAX. That is, not single postback in the entire system (like meebo.com-- meebo is a prime example of a web 2.0; everything is from the perspective of the client with communication via AJAX services.) In fact, my controls are very Google-ish. Google is also deep into this model. See their AdSense, AdWords, or Analytics controls; insert a declarative script and it does the rest from the perspective of the client. As you can see here, you don't even need the XHR object for web 2.0!
What does ASP.NET AJAX bring? In this model, ASP.NET AJAX is as web 1.0 technology that gives you the dynamics of web 2.0. This was actual the entire point behind creating it. Web 1.0 developers (who are often not web developers at all!) can use their existing server-side perspective and paradigms to implement dynamics on the remote system (in a web 1.0 model the client is the remote entity-- whereas in web 2.0 the services are remote). ASP.NET AJAX very much allows for a web 2.0 model, but that's not how it's primarily marketed. As a side note, I should mention that, this model for explaining web 1.0 and 2.0 is only a logical representation and therefore can not be right nor can it be wrong. The fancy marketing representation kind of works too, but it's often too abstract to have real meaning.
Personally, I think the web 1.0 model of development is counterproductive and encourages sloppy priorities. The user experience is the point of the system. Without that, the entire point of the web site is dead. One of my problems with ASP.NET AJAX is how it's marketed. The server-perspective model of development encourages development that seems backwards. Furthermore, because of this, the aforementioned so-called "web developers" continue to spread their disease of pragmatism all over the world further aiding in the disintegration of quality. As I've originally stated, most of these people don't understand even the basics of semantic XHTML, which is the single most fundamental aspect of web development, which can be seen in their use of div-soup or <br/> mania. These people may be awesome server-side professionals putting my enterprise architecture skills to absolute shame and run circles around me in just about any algorithm or design pattern implementation, but they are only coders when it comes to the web.
After years and years of dealing with people like this, I've come to notice a few signs of web 1.0 coders:
- If someone says "Firefox? How's that better than IE?", it goes without saying that this person not only hasn't the first clue about web development, they don't even understand the tool which represents the core purpose of web development: the web browser. People like this are almost always helpless. You could try to explain the true power of CSS, the fact that SVG, HTML5, and Canvases are in every web browser except IE, or talk about how Firefox has the architecture of an operating system with its console, it's own registry (about:config), as well as the ability to install apps (extensions), but you're probably only going to get the same pragmatic blank stare of a coder. Fortunately, I haven’t heard say this in at least 3 years.
- If someone says "I know CSS, here..." and shows you how they used font-size, color, and font-weight on a few elements contained in a table embedded in a table embedded in yet another table, then you have your work cut out for you, because you met a person who thinks HTML is the latest cool technology on the block and hasn't the first clue what CSS really means. As I've stated in my article "CSS Architecture", CSS is not just a styling technology. Furthermore, we web 2.0 developers realize that CSS is to be used in harmony with semantic XHTML and therefore understand the dangers of using a table. These people obviously don't. Of course, the minute their boss asks for mobile support, they come running to you because they now realize "DOH! Tables are too wide! AHH! Tables make the page size too big!" They will have to learn their lesson eventually.
- If someone says "I know JavaScript, here... " and they show you a validation function, then you need to explain to them that JavaScript isn't merely a scripting language, but is rather a very powerful object-oriented/functional programming language which often puts strongly-typed languages to shame. It includes closures, namespaces, an extremely rich object system, object-oriented access levels, multi cast events, and a boat load of core JavaScript objects. Yet web 1.0 developers haven't the first clue. This problem isn’t nearly as bad as it used to be, though. MSDN magazine devoted some time to the topic in the May 2007 issue and the number of JavaScript experts in the Microsoft community is growing very rapidly.
- If someone says "Hmm... I don't see the control you are talking about in my toolbox", then you know you are dealing with a coder. Not only that, you're probably dealing with a person who has never, ever learned what semantic development even is. Typically people like this will use the dead concept of a WYSIWYG designer to drag-n-drop controls and set properties with their mouse. Clearly, these people focus more on how something seems to look at the moment, not how the page is actually built. Pragmatists. Personally, I’ve never designer support into anything, ever. If you can’t program it, don’t develop it! I personally find it extremely unprofessional to even allow designer-support. The target audience typically has absolutely no concept of the difference between a semantic <h1></h1> and a pragmatic <div id="myHeader"></div>. Not only will their code cause problems down the road, your code will never integrate with it, which, of course, means you will be rewriting everything. Anyone who understands the importance of semantic XHTML understands the sheer severity of this problem. You will break a page's structure by relying on a designer. A designer should only be used by a professional who knows how to fix it's flaws. Since only a professional would be able to fix the flaws, it follows that only a professional should do web development. Duh? For more information on semantic XHTML, see any modern web 2.0 book or my mini-article here (a quick note-- when I was formatting this post in WLW, every one of my list items would start a new list-- if I didn't understand semantic XHTML, I would have been completely stuck [also notice I'm using the semantic term "list item" not the syntactical term "<li />"-- focus on what things ARE, not what they DO-- try focusing on what something IS using a WYDIWYG designer!])
I know I've written about this topic before, but it's is just such a critically important topic. Just because someone does something, that doesn't mean they are in that profession. I change my own oil and change my tires, but this doesn't make me a mechanic. A few months ago I was talking to a guy who actually said that he doesn't care about what he produces, because "it's just a job". Just a job!? Why don't you just get another one! These people need to stop masquerading as web developers, stop undercutting my professional company by offering $3.75/hour unprofessional "development", start upping their own standards and start showing a little respect to us that were here first. To a lot of us professionals this isn’t just a “job”; it’s actually become part of us! Unfortunately, I've learned years ago that people don't change. Not for their marriage, not for their family, and especially not for their careers. It's hopeless. Moving on.
}