I just had a friend at work ask that most innocuous of questions, "So, what should I learn if I want to be web developer?" which led us into a pretty good discussion about all things web related and to give him (Hi Nat!) a place to reference my ramblings I thought I'd jot down what I suggested.

Define "Web Developer"

Web developer can pretty much mean anything these days so I find it best to ask yourself what it is you really want to do.  I've been in shops where web developer meant just HTML/CSS while in others the dev does it all, from comps to HTML to database interaction.  In my friend's case it meant creating a dynamic database-driven website from nothing more than a designer's comps and the napkin the business leaders scribbled on in between rounds of golf.  Which was good because that's how I define it.

Stage 1 - Learn HTML/CSS

You've gotta learn the basic currency of the web before you can get fancy pants on it so getting a solid understanding of good, standards-based semantic HTML and CSS (vs. table tag soup) is key.  Regardless of which whiz-bang rocket framework you use in the end it all comes down to pushing HTML so you need to know how to craft good basic pages.

I also suggest forgetting about Dreamweaver, FrontPage or any other HTML editor, for now.  In fact I'd suggest using just a really solid text editor like TextPad, InType or E.  My current favorite is InType because it doesn't require the cygwin install like E yet it has better syntax highlighting and snippet expansion than TextPad.  When learning HTML you want to be as close to the metal as possible.

There are a ton of great books and websites out there teaching this stuff.  Two of my favorites are "Bulletproof Web Design" and "Web Standards Solutions", both by Dan Cederholm, who presents web design (as in the HTML, not Photoshop comp work) in a real-world, useful manner.  Good stuff.

Stage 2 - Learn JavaScript

I'm still iffy on this one since you could argue that JavaScript could come later but I feel it's best to at least get a rudimentary understanding of JavaScript to learn the basics like client-side validation, confirmation boxes and how to use one of the various JavaScript libraries out there like Prototype, jQuery, ExtJS.  Most server-side frameworks try to color the basic way you use JavaScript which I feel can dilute a person's understanding of just what client-side coding is all about.

Stage 3 - Pick Your Poison (Server-Side Framework)

Ahh, the golden ring, the big prize, what it's all about, at least for me, the server-side framework that makes all the magic happen when it comes to dynamic page generation.  This was probably the hardest thing to guide him on because I've worked with most of the major frameworks and they all have pros and cons.  The big three to me are ASP.NET, Rails and PHP.  They all have great support, vibrant communities and very active development.  There is also Java, but I was badly scarred when I learned Java's AWT and Swing frameworks so I'm going to completely ignore it since even thinking about it again makes me whimper :)

ASP.NET - I'm a little biased towards .NET because it offers a great springboard in terms further types of development.  Want to do create a desktop application?  No problem, you already know the IDE and C# (OK, or Visual Basic).  Feel like being more creative and want to do something Flashy?  .NET has you covered with Silverlight.  It's like a gateway drug of development, especially once you start factoring in things like IronPython, IronRuby and MVC.  And despite what some people say ASP.NET isn't just for corporate drones, there's no Web 2.0 site out there that can't be coded in .NET.  Downsides are that it's a little more complex to get started and that it'll warp your fragile little mind when it comes to the bastard child that is WebForms.

Rails - I think learning Ruby (the language of Rails) is a great addition to any developer's knowledge, regardless of what they code in by day.  If someone is interested strictly in single focus, highly dynamic web sites and really has an aversion to Microsoft this is where I'd steer them.  It's a much better abstraction of the web than .NET's WebForms and you can really get rocking quickly without having to understand much with Rails.  The downside is finding jobs in your area looking for entry-level Rails devs.

PHP - This is sort of the monkey in the middle.  There are a ton of great PHP jobs but it's lost a little of it's hipster sizzle, which isn't exactly a bad thing.  PHP is a great choice for the newbie consultant looking to work with small to medium-sized companies because there are a lot of CMS packages in PHP and you can get solid PHP hosting for a song.

In the end I suggested that he go through job descriptions he was interested in (shhh, don't tell his boss) and see what they were asking for in terms of knowledge.  This brings up another good point, why do you want to be a web developer?  If it's just for a better job then I stand by my suggestion.  On the other hand if it's because you want to do Website X or Project Y then that completely changes the game and makes it easier.  You pick the technology and learning curve that will get you quickest to your goal.  In the end users could care less if your site is in Rails, .NET or PHP.

I'm starting to see more ASP.NET MVC samples and questions come out and I'm realizing that a large portion of the ASP.NET crowd doesn't even realize that a huge reason for the MVC movement is because of the Ruby on Rails framework.  A lot of new .NET MVC developers are struggling with architectural questions that have already been debated and answered in the Rails community, which makes Rails a great resource for when you're first starting out or you're curious how to handle certain situations, like nested resources or how to structure your controllers.

Speaking of controllers one great thing from Rails that I hope more MVC developers embrace is REST.  Instead of repeating everything just watch David Heinemeier Hansson's keynote speech from RailsConf back in 2006.  Sure, it's almost two years but for ASP.NET developers it may as well be yesterday.  I'd suggest starting from the second part since the first segment is just normal conference ra-ra-ra.

Check it out here (don't forget to download the slides that he refers to here).

Note

He talks about using a semi-colon in the URL to denote an aspect/action of a controller, like this:

/people/1;edit

Well, you can ignore that and just assume he *really* meant to say:

/people/1/edit

They dropped that semi-colon silliness in Rails 2.0 and it feels much cleaner.

I've been dabbling in the Ruby on Rails world for awhile and I've always been drawn to the very clean separation of the Model-View-Controller framework, something Rails pretty much nailed in their implementation.  I've done a few small Rails sites here and there, played with it enough to be dangerous but I didn't use it enough in my daily life to really get it under my belt.  At the same time I was doing a lot of ASP.NET work and felt like I was constantly fighting the WebForms architecture to get it to produce proper stateless standards-compliant web applications that were based around the concept of request/response.  I'd disable ViewState, override Inits(), hack into the page lifecycle and ignore server controls so I had real control the HTML output and get back my CSS id selectors.  In a very bad way WebForms reminded me of VB6 and all the hacks I had to do during my stint with that language.

The most frustrating point came when the CSS Adapters were released and touted as some kind of panacea to those that cared about web standards when in reality they are more akin to giving a woman with a horrible breast job a big baggy sweater with a picture of a nice rack on the front.  Sure, it may be a pretty picture but the scar tissue and ugly layers are still there.

I think I got some of my faith back after I started reading Rob Conery's blog because in him I found a Rails enthusiast who still enjoyed the many good aspects of ASP.NET and C#.  Instead of just jumping ship he was bringing some of the better elements, and more importantly concepts, over to the .NET side with the SubSonic project.  Then he somehow got mixed up with some other crazy people like Phil Haack, Scott Guthrie and Scott Hanselman and now we have the ASP.NET 3.5 Extensions Preview which contains a juicy little nugget otherwise known as ASP.NET MVC.

After wading through the bits, doing a few sample projects and generally taking their version of MVC for a walk-about I can say I'm once again excited about .NET.  Sure there are some rough spots and some areas that are a bit too "chewy" (you know a line of code that's a 100 characters long and includes at least three generics and two type casts?  yeah, that's chewy) and design decisions that some people are taking umbrage over but all in all it feels useful, feels clean and feels like real programming.

In an odd way I have the same feeling I had back in the day when I switched from Visual Basic to Delphi (which I still think is the best tool for creating native Win32 applications), like I once again have control.