Developers, developers, developers! It's been Microsoft's mantra for a long time. They had the VB developers "back in the day" (a Tuesday, I believe) and when .NET came out, they needed a way to keep them.
So, what do you do with a bunch of developers that don't want to learn a new way of doing things? Simple - don't make them learn.
ASP.NET has a low barrier of entry
So, now, there's this new .NET "thing" and there's all sorts of ways to make a presentation layer for your applications. You can start using WinForms, or you can use ASP.NET. (Now, you can also start using WPF, or Silverlight, but we're talking about the dark ages of 2002. Bear with me.) From what I recall, it seems like that Microsoft was pushing ASP.NET pretty hard, and leaving WinForms as a not-quite second class citizen.
So, ASP.NET. It's fantastic. I loved it and I still think it's a fantastic platform for any development - web-focused or otherwise. Microsoft did too, and they did several things to make it easy to start developing applications in ASP.NET. They used a lot of conventions from the old VB world of Forms development (TextBox, Label, Button) for the presentation, and they presented a fairly robust event-driven model for UI interaction. They kept the same basic state management tools available to you from ASP classic, and tried to make it as easy as possible to migrate existing ASP applications to .NET.
(Side note - anyone who's actually done a migration like that with a "real" application knows that it's not trivial at all. But Microsoft did try.)
What Microsoft failed to do with ASP, and what they sort-of did with ASP.NET was abstract the messy land of web development, with it's:
- HTTP verbs (POST, GET)
- Javascript
- the HTML DOM
- CSS
- Different browser issues (usually related to the items above).
They shipped a bunch of tools (DataGrids, several wizards) that would allow you to make your easy, cookie-cutter "enter some data and display it back to the user, or throw it in the database" applications very quickly.
I know I'm glossing over a lot of stuff. Bear with me.
Rails and Scaffolding
What? Ruby? Rails? Blasphemy!
Seriously though, this is great stuff. I have yet to do more than play with it, but I've made a commitment to start learning something new, and Ruby is a start.
So, what do I do? I start reading blogs. I've been reading a lot of Giles Bowkett. He's abrasive, but he takes a side, and I like that. Something he touched on is part of the inspiration behind this whole article:
I recently tried to get the Rails core team to switch the for loops in the scaffolding templates to iterators, on the grounds that this would encourage new Rails programmers to use iterators instead of repeating their bad old habits with for loops. I failed completely. Josh Susser said that replacing for loops with iterators would set up a barrier to adoption for new Rails programmers, and that was that. The idea didn't fly for a second.
So - barriers of entry <=> Bad.
The whole philosophy behind the Rails team is to get programmers using Rails (and Ruby). The easier it is to switch, the better.
The state of Web Development Now
So, what's happening now? You don't find a lot of WinForms developers, for one. I've been on job hunts recently, and let me tell you - Microsoft shops don't care about WinForms. They all want ASP.NET. (Or they're stuck supporting their old VB apps. But they're moving them to ASP.NET.)
So, now all of the developers working on Microsoft's platform have ASP.NET based applications. You have zillions of web applications out there that basically all do the same thing - enter data into a database and display it back later. And a lot of them are exactly the same. Sure, the database is different, and the colors are different, but there's not a huge differentiator in applications that are developed for ASP.NET, if you stick to the DataGrid/GridView application model.
Where you find the truly outstanding applications now, is both a great idea, with great execution, in ways that make that web browser dance. And there's frameworks out there that try to help you (ASP.NET AJAX, control suites like telerik or ComponentOne).
However, several of these still provide somewhat leaky abstractions. FileUpload controls don't work correctly in UpdatePanels. Validators don't work correctly anymore. ComponentOne's grid looks great, but only if you're willing to put up with it's bloat. (It emits a TON of code to the browser.)
However, think of those applications that just give you the "holy shit" moment when you figure out what's really going on.
I'm sure you've probably got your own list, but these are ones that really stuck out in my mind. And what do they have in common? These applications were built with the understanding that the browser is fickle, but powerful, and take advantage of the HTML/CSS/Javascript "mess."
Go Learn Something!
So, what's the point of all this? Go learn what you're emitting to the browser! Here's some problems that, without knowing about the HTML DOM and Javascript, I would have had a nightmare of a time dealing with.
- The ASP.NET Label - is there any more mis-used control? This needs to have the AssociatedControlID property filled in, so that it actually renders as a <label> or you'll end up with a <span>. Heaps of problems there. Much better to use a Literal if you're just trying to throw some text up on the page.
Side note - DataBinding (for globalization), in my experience, is easier with a Label. It has all the properties that you'll need to globalize. So, what can you do? Override the default rendering (as a <span>) with something else if it's screwing up your CSS. Or roll your own control. The CSS Friendly Adapters are a good place to start. - The DataGrid, or the GridView. Good for simple stuff, but I bet you won't find many of those on anything that is public facing - too much to send up to the browser. Use a Repeater instead.
Scott Watermasysk has a great article about these tips, and others as well.
I'm sure there are other problems out there, but these are just some of what I've encountered. But, without the big picture, I couldn't have solved them as effectively as I would have liked.
Congratulations! You've reached the end. Thanks for reading, and I'll (hopefully) have some more in the future.
