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.

The cool kids over on the other side of the fence always make these really cool "cheat sheets" for whatever bit of tech kit they're using and I fully expect someone with some good design skills to produce one for ASP.NET MVC.

You hear that Rob Conery?  Scott Hanselman?  How about you Phil Haack?  I fully expect Scott Guthrie, who is a Word among Bytes, to conscript some stylish hipster graphic designer to produce a masterful, stylish and yes, useful cheat sheet for the MVC masses at Mix '08, an event I sadly won't be attending because my company considers computers and those that make them work to be second class citizens.  I'm lucky if I get  to upgrade my IDE before the next one comes out much less attend an actual conference.  I've heard of conference swag but I've never actually received any of this mythical bounty.

Still, I desire, want and dare I say expect said cool cheat sheet.

Here are some examples for those that need some prompting and design ideas and to figure out just what in the hell I'm talking about:

• REST Cheat Sheet
• Prototype.js Cheat Sheet
• Rails Cheat Sheet
• What Goes Where (Ruby on Rails cheat sheet by Amy Hoy)
• Form Helpers (Ruby on Rails cheat sheet by Amy Hoy)

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.

Often you'll need to represent some hierarchical or parent-child relationship in your application and one thing you'll struggle with is how to cleanly mesh both the parent and child controllers yet keep them nice and RESTful.  The secret is in good routing.

The problem

A popular example is tickets belonging to events (event as in Burning Man, not OnClick) and you want to get all the tickets for a certain event, as well as be able to work with just tickets or events.  You want nice and pretty urls as well, so you're hoping for something like this:

/events/1/tickets	all tickets for event 1
/events/1/tickets/new	add a new ticket for event 1
/tickets/list	all tickets for all events

 

The Messy Way

My first idea was to add a Tickets action to my Events controller so I could call EventsController.Tickets(int eventId) but that didn't really help when I wanted to view all the tickets for all the events.  Plus it broke the whole REST idea and that's bad for maintainability.

My second idea was a butt-ugly url along the lines of /tickets/list?event_id=1 but that just kicks the whole MVC, SEO-friendly url philosophy in the nuts.  Repeatedly.

The Routes Way

A Big Thanks goes to Adam Wiggins whose post about nested resources finally set off the lightbulb in my brain.  Instead of trying to make my controllers do all the work why not take advantage of the actual mechanism that's there to handle these sorts of things and put it to use.  That would be the routing mechanism that makes all your urls pretty and dictates which controller does what.  Here is the way to keep your urls pretty and to have both a separate Events and Tickets controller yet still maintain the cool parent/child relationship:

[code=csharp]RouteTable.Routes.Add(new Route { Url = "events/[eventId]/tickets/[action]/[id]", Defaults = new { controller = "Tickets", action = "List", id = (string)null }, RouteHandler = typeof(MvcRouteHandler) });[/code]

(yes, I know, my code formatting sucks, I'll update it this weekend)

Once I discovered this I smacked myself on the forehead for not realizing just how simple this whole thing was.