Site Meter
 
 

Mindset shifts between ASP.NET and MVC/Rails (and the future of web development…)

Let’s imagine your web development team is going to move out of “classic” ASP.NET and into MonoRail/ASP.NET MVC/etc. We assume you have a good reason (“It’s new and exciting” is usually good enough for us devs).

What kind of issues are you going to face? What questions are going to keep coming up?

“… but how do I do postbacks?”

The loss of the postback model is going to hit a lot of web developers hard – there’s a big mindset shift to make. So how did we get here, and where are we going?

In the history of web development so far, there have basically been two major different approaches/philosophies to web UI.

1. Event-driven

Just like with native GUI apps, we imagine that when the user clicks a button, we can change the text on some label. When they change a value in a list, the “total” is updated. The fact that this stateful UI has to be transmitted over HTTP is just a technical obstacle to be overcome.

2. RESTful

Following the principles of REST and SOA, we understand that the cleanest web apps are stateless. We think in terms of requests and responses, working with HTTP rather than against it.

While RESTful apps are the fashion today, don’t forget that it’s the older technology. In 1997, the age of Perl, we had no choice. The first Event-driven platforms came later, achieving their statefulness through complicated abstraction layers (ASP.NET), fiddly scripting (AJAX), or abandoning HTML entirely (Flash).

Here’s another way of comparing the two mindsets:

Event-driven RESTful
ASP.NET RoR, MonoRail, ASP.NET MVC
Stateful Stateless
Heavyweight Lightweight
Overcomes HTTP Embraces HTTP
Widgets HTML
3rd-party controls DIY
Design view Code view
GUI Web page
Postbacks -
Partial page updates* Full page updates
Web 1.0 (uncool) Web 2.0 (cool)

* I know classic ASP.NET actually replaces the whole page on a postback, but the mental model is that it’s doing partial page updates. It just technically uses full page updates to achieve that.

Note I’m trying to keep AJAX out of this, because it’s just a way of strapping extra event-driven semantics on top of whatever other platform you’re using. I totally accept that it’s useful today, but in 3-5 years it will be gone and we won’t miss it.

So which should I use?

Another way to think about the progression of these approaches is like this:

  RESTful Event-driven
Ineffective web technology Perl, Plain PHP ASP.NET
Effective web technology RoR, MonoRail, (ASP.NET MVC?) ?

The most effective web frameworks today are undoubtedly the highly-streamlined, designed-for-HTTP, MVC derivatives. I call ASP.NET “ineffective” because anyone who’s used it for more than a few years knows that the abstraction doesn’t really work, it tends to be too heavyweight, and the “page lifecycle” is the software equivalent of cholera.

What’s the future?

The future is not Ruby on Rails. It’s not ASP.NET MVC either, though that will hopefully improve our industry for the next 2-4 years and you should probably use it.

The future is, inevitably, obviously, undoubtedly, the question mark on the table above. It has to be an event-driven architecture since that matches both the end-user and developer’s instincts about UIs. But unlike ASP.NET, it will be thick-client, not a load of leaky abstractions. It may be so well integrated into the OS that users don’t think of it as being different to their local apps.

In other words, the future is client-side. Well, it’s going to be interesting anyway.

7 Responses to Mindset shifts between ASP.NET and MVC/Rails (and the future of web development…)

  1. Pingback: 98clouds » Mindset shifts between ASP.NET and MVC/Rails (and the future of …

  2. Hmmm Calling PERL ineffective :)

    Now that’s something I wouldn’t say to quickly.

  3. Jackie

    Interesting article.

    So, are you a proponent of asp.net MVC? I can accept this new framework just fine except that I can’t tolerate embedding codes by intertwining and the curly braces in the view. What do you think?

    Also, why are you so certain that AJAX will be gone in 3 to 5 years? Can you explain a little? Thanks.

  4. Jackie

    OK, special character combination such as the < % are filtered out. I meant I hate to embed codes between a lot of < and the percentage sign, and a lot of curly braces.

  5. Steve

    > I can’t tolerate embedding codes by intertwining and the curly braces in the view.

    I can tolerate it. In fact, I find it works great. What practical problems do you find with that when building MonoRail or ASP.NET MVC view templates?

  6. Jackie

    Frankly, there are no practical problems about it, but I think it is hard to read and error-prone. Of course, the problem is minimized with Visual Studio intellisense.

  7. I together with my buddies ended up going through the best suggestions found on your web blog and so immediately I had a terrible suspicion I had not expressed respect to you for them. My young men are actually as a consequence warmed to read through them and have now undoubtedly been taking pleasure in these things. Appreciation for being considerably thoughtful and then for obtaining some cool things most people are really wanting to discover. Our honest regret for not saying thanks to you earlier.