The mindset of a modern web developer...

So what makes a good web developer? There are a few things, but the first is the most definitive and it's the one that so so generic that it is really an answer to the question "what makes someone at good anything?" The answer is: the ability to paradigm shift. Without this skill a person is utterly useless. If you come at new technology with comments like "that seem so stupid" or "uh, that makes no sense", then you're probably not only going to be a failure in the web, but also in all of life. In a world where medical science has a half life of four years and technology has a half life of two, you have to be able to adapt to new things with little to no whining.

With respect to the technical skills, there are a few fundamental things that really defines what makes web development, a web developer at all. Back in 1999 when I was in the business of pioneering web application development, having a solid foundation in server-side classical of web development was something that was really a requirement. I remember single-handedly porting our corporate VB applications to ASP in no time at all. The kind of skills required in this was an entire host of web development tricks to help maintain state and other things. This of course was only half the story. The other half of web development was the browser-side.

Back then, the web really got away from standardization and IE was the "standard" browser. So, I was able to build my web applications with a ton of [now extremely icky] "DHTML". Not only that, more advanced web applications could tap into the world of remote scripting (this was 1999, not 2005--anyone who thinks Ajax is new is obviously new to web development) So, while around the beginning of the new millennium web development was a big complexity on the server-side, it was very simple on the client side: there was no pride taken in client-side web development and there was only one "supported" browser. I should also mention that this was not the beginning of web development. I've been building advanced JavaScript applications since 1995 and back then we had Netscape Navigator 2/3, which allowed for the creation of very powerful client-side web apps. In those days, server-side development wasn't even a big deal..and client-side, well...no one knew you could do half the stuff you could do (people would still be freaked out by the stuff I built in 1997.)

So that's an old school web developer: classical (ASP/PHP) serverside language and support for basically just one web browser. Here's the kicker though: a web developer back then with no new skills is NOT a web developer today, he or she is really just a legact support developer. By standing by and doing nothing, a web developer, doing nothing different and losing no skills, loses his or her standing as a web development even though he or she still innapropriately holds the title.

The new professionalism is one of purity and respect for the web and focus on the solution more than the mechanics of the system. Today, there is absolutely no excuse for a Microsoft shop to use ASP.NET 2.0 for their server side technology. There's no need to do any voodoo with state management or any magic with form validations--it all just happens with ASP.NET. The other part of modern web development is of course the client-side. Today, however web development for the clientside has grown much more complex. The blame for this in my mind lays almost entirely on the shoulders of Internet Ex. (forgive me-- I can't bring myself to write that name out). By having absolutely no respect for the laws that the W3C has set forward, IE has actively damaged our world's information infrastructure, ironically without legal repurcussions or action from Geneva. Fortunately, today we have what I call the savior to the web: Firefox. With it's focus on purity and respect for the web, it brings a glimmer of hope to the future of the Internet as a whole. Firefox however is NOT part of the new professionalism for the client-side! I want to make this very clear: while an old school veteran web developer (someone from 1999-2000) "optimized" for specific browsers, a web developer today writes for the specifications (what some call "standards") just like a C++, Java, or C# developer would. That is, web developers today do not ask the question "What's the target browser?", we just write something that is for the W3C/ECMA specifications ("standards"). If it doesn't work somewhere, fine...we will add backward compatibility for that particular part of the system. The other day someone said to me "I'm not into standards as much as you". Clearly this person isn't a programmer. Programmers know that if you dont' follow the rules, your code doesn't compile.

Now what are some of the fundamentals of modern web development?

First, you would your C++ code to be syntax checked at compile time, so it follows you should write your XHTML/CSS/JavaScript to be syntax checked at "compile" time. Writing something and saying it works because you "tested" it, does not mean it's right or even wors. Furthermore, focusing on making something "work" isn't even the point. No one initially writes C++ code to work. A programmer writes his or her C++ code to first to be syntaxicly correct and then makes it works. Without the former, you can't even test the latter! The same pattern goes for modern web development. This is the same not only for JavaScript, but also for XHTML page structure and CSS page style. This is why validation is not just a good idea, but is absolutely required.

Second, modern web development deals with code-behinds. That is, there is a clear separation between different types of coding. On the client-side there is the page structure (XHTML), the page style (CSS), and the logic (JavaScript). On the server side, there is the declarative page (ASP.NET) and there is the code-behind (C#). Each of these things are in their own files, clearly separated from the others.

The purpose is multifold, but the two main purposes are...

• to the allow for easy management
• to minimize the rippling effects of changes on the system; that is to lower coupling.

The one thing that I find odd about developers (no just web developers) is that there seem to be two massive camps that both flaw in their understanding of this. There is the side people that knows to separate their page structure and their server-side code behind. These are the ASP.NET programmers. Then there's the camp that knows to separate their page structure from their page style. These are the linux-ish web developers. The former camp doesn't really understand why there is a separation of style from the structure on the client-side and the latter camp usually thinks it's odd that there's a code separation on the server-side. You would think that each would step back and have their own "aha!!" moments saying something to the effect of "OHHHH I'm all for code separation...Duh!! You're doing the same thing as I am doing! Rockin'!!" As it is though, people just don't seem to like that level of consistency.

Third, Modern web development has a simplified page structure model. HTML was a presentational language and HTML 4.0 was a nightmare. The rules in HTML 4.0 frankly didn't make much sense. Fortunately, HTML is obsolete. Today we use XHTML, which feels a bit like HTML 3.2, but it's written as XML -- so there at least some logic to the page! XHTML is a structure format, not a presentational format. It has no style elements. Sure, the browser can do some stuff by way of default styles or holding to tradition ( i.e. h1 is bigger than h6), but in the end XHTML has no presentation. It gets it's presentation from CSS.

A modern web developer builds what the page "is" in XHTML and how the page "views" in CSS. A related principle is a principle take from object-orientation: development based on what things are, not what things do. Ideally you want to tell technology what you want, not how to give you want you want; this is at the heart of abstraction. A great first step towards this is to think about what things "are", not what things "do". For example, in the past we thought about lines and page breaks. Put some text down, then a <br/>, then more text and then another <br/>. In this model, we are telling the technology how to do it's job, when we should just be telling it what you want and let it deal with the details. That's why in the XHTML/CSS model you never use <br/> (save for some advanced CSS tricks). In the new model you have paragraphs (<p>text</p> ), because that's what they are!

Fourth, modern web development is for devices, not for browsers. In this world where a ton of people have Internet on their cell phones, there's no way to just write something that is for a browser. This is one reason HTML is obsolete. You can't really get the uselessness of HTML into a cell phone. You can however get XML (XHTML) into a cell phone. This is possible due to the fact that XHTML has no presentation (because XML has no presentation--as I say, the presentation XHTML does have is by browser defaults and tradition). So, you can actually have a media specific CSS pages for each device. You can have one page structure-- that is, one definition of what the page is and have multiple "views" associated with it. There can be one view (one CSS page) for hand held devices, one view for your printer, one view for your monitor, one "view" for audio devices for the hearing impaired, and other views for other devices. This is the beauty of XML-- it really is extensible!

That's another point of irony--the ASP.NET people who are seriously into XML just can't seem to get it through their heads how web development is XML based now adays. That leads to the common problem of ASP.NET (1.x) developers not even being able to spell CSS.

Fifth, modern web development is tableless. This one probably the most frustrating for new web developer. You could be a 10-year veteran, but if you don't know XHTML/CSS web development--you are in the camp of new web developers. Table layouts used to be an extremely powerful tool for development. I can remember when tables first became popular many, many years ago. I thought they were the coolest thing since the popularizing of the mouse. After I finally figured how the pattern of "tr" and "td" I was virtually unstoppable! Table's however have many problem.

First of all they are very rigid. Secondly, they severely break the model of programming to what things are, not what things do. With you setup a table you are way too involved in the intricate implementation of something, when we should be telling the system what we want (i.e. a product list) and have it do the work. Thirdly, they really don't make logical sense in the flow of a page. You read a page from top to bottom and then all the sudden you have this complex puzzle called a table. You went from simple to complex way too fast. That's not a smooth curve to complexity as is desired, that a jolt into madness.

That leads to another major problem: tables are WAY too complicated! Writing them is a breeze, a skilled table writer can come up with a table to match virtually any rigid scenario. Reading them however is another story. They are a complete nightmare to edit, and cause a complete nightmare in the editing of elements in particular table cells.

Sixth, modern web development doesn't go gung ho with JavaScript, but will however see ECMAScript as a valuable tool and will know when to use and when to avoid it. I'm a veteran JavaScript programmer. I jumped on it in it's first release over a decade ago and I've been working with most of the great JavaScript (and proprietary DHTML-style ickyness) APIs since their preview stages. I've seen browsers do things 10 years ago that would make some people still gets getty even today. That said, I think the use of JavaScript (or more appropriately ECMAScript) in public websites is almost slanderous. For web application however it can be a great tool, but to a certain point.

I've been playing with the new Yahoo Mail and I have to give it about 2 stars out of 10. Their use of remote scripting is a bit overboard and things just don't seem intuitive at all. Gmail on the other hand is what I consider one of the greatest gifts to the world! It's use of JavaScript is very nice. Everything is very responsive and there isn't much by way of annoying and inappropriate "desktop application" emulation like what you see in Yahoo Mail or the newer versions of Outlook Web Access in IE. So, I don't consider JavaScript/"Ajax" part of the mindset of modern web development. That said, there are a few things a modern web developer will see with regard to client-side scripting.

First, DHTML is an obsolte term and generally reffers to IE-only client side work. Secondly, the appropriate technology for client-side web scripting is the standardized "ECMAScript", which completely replaces JavaScript. When it comes to ECMAScript, I am a huge fan of using it to create simple applications or to subtly support application. Last year I wrote a children's application in about 15 lines of pure XHTML (including the doctype and all that jazz) and about 2,000 lines of pure ECMAScript.

The difference between old school web development and modern web development is really is the purpose and placement of the code. Things like "window.open" for a website pop-up are extremely annoying. It drives me nuts that my favorite electronics store requires me to deal with a lame "window.open" pop-up that to pay my bill online. I would much rather ctrl-click to have that open up in a new tab in Firefox! The use of JavaScript in that scenario is not a convenience, but a severe annoyance. Gmail on the other hand as I say works with JavaScript beautifully. There are also a few amazing and clean Mozilla applications around written in ECMAScript. If I were to put a rule of thumb of this I would have to say that a wise web developer only uses JavaScript (well, "ECMAScript") when the website's foundation is based upon JavaScript. Websites are not based on JavaScript, they are based on XHTML. Applications like Gmail however are based on JavaScript. Furthermore, going overboard and trying to inappropriately emulate desktop applications like Yahoo Mail is trying to do, is however a big no-no.

Those are some of what I consider to be the fundamental mindsets at the very heart of modern web development. This isn't really a complete list, but it does give somewhat of a feel of what is required of someone before he or she can seriously be called a web development now adays.