Branching out, or “How to live life outside ASP.NET MVC”

I’m in the early stages of writing a web app with a friend who has been somewhat on the periphery of ASP.NET MVC. As in, when someone says “let’s build a web app”, he doesn’t automatically reach for the MVC project template as I typically do. Bear in mind, he’s also not a web forms fan either.

Instead, he has a very specific architecture in mind that has taken me some time to come around to. A simplified version of it is thus: there is one web application for the various HTML files (and yes, they will be HTML only) and another for the “services”. The services one will serve up primarily JSON to the client which will interact with it with a very healthy dose of JavaScript. This is one reason we’ve decided on OpenRasta for the services layer.

I’ve deferred to my friend on some of this because I feel like I have too much emotional investment in MVC these days (as you can tell by my tendency to erroneously drop the ASP.NET part of the name). Suffice it to say he’s led development on some major league websites that have more traffic in an hour than I have cycles in my family tree. So I feel confident in his evaluation skillz. He has a more rounded view of the world, partially because of his experience with these websites and partially because he hasn’t been drinking the kool-aid as much as I have for some of this stuff.

One of those areas where he isn’t tightly coupled is with JavaScript libraries. Me, I’m a jQuery guy. Not because I like it better than the other libraries but because it’s the only library I’ve ever used and it hasn’t caused me any pain. He has only a passing knowledge of a few of them and attacked the problem of which one to choose more objectively.

To that end, we’ve settled on MooTools, at least for the time being. The main technical reason for this is because jQuery is getting too popular and we don’t want to be perceived as jumping on the bandwagon. We feel that if it’s good enough for Microsoft to throw its support behind, then we need to look at something else.

I jest, of course. In fact, our research shows it to be faster than jQuery and I have it on pretty good authority it is well-suited if you plan to have a somewhat complicated object model on the client. During my spike, I did find it to be more verbose than jQuery but not prohibitively so.

Another JavaScript library we’re playing with is Embedded JavaScript, which is a view engine for JavaScript. With it, you can define views like so:

<h2><%= petNameForRack %></h2>
<ul>
<% for( var i = 0; i < guns.length; i++ ) { %>
    <li><%= guns[i] %></li>
<% } %>
</ul>

This would be stored in an external file and you render it with some JavaScript like so:

function renderListOfLovers( )
{
    var jsonRequest = new Request.JSON( {
        url: "http://localhost/Services.Web/Lovers",
        method: "get",
        onSuccess: function( gunRackList ) {
            gunRackList.Racks.each( buildItem );
        } ).send( );
}

function buildItem( item )
{
    target = $("destinationDiv"); 
    var div = new Element( "div" );
    var view = "views/MyListOLovers.ejs";  // Contains the view shown above
    new EJS( {url: view} ).update(div, item);
    div.inject(target);
}

That’s mostly from memory so don’t be cuttin’ and pastin’ none. In the first function, we call out to our OpenRasta service which is configured to return a list of gun racks as JSON by default. When that call succeeds, it creates a new DIV, renders the view in it, then injects it into into a target container.

All in all, it’s an interesting way of doing things. It’s nice that JSON has become kind of the de facto standard for passing stuff around with the various frameworks because it would be a pain to have to retrieve the list from OpenRasta in one format, convert it to another to work with MooTools, then another to work with EJS.

All of this pretty much worked out of the box, too. The spike involved very little actual troubleshooting. It was mostly getting used to the syntax (e.g. I would have thought the MooTools inject function would act on the target rather than the item being injected).

I also discovered you can throw an instance of a custom MooTools class into a view as well with no further changes required. Maybe that’s obvious if you are intimately aware of how JavaScript handles classes but my own experience has been limited to: new ActiveXObject(“MSXML2.XMLHttp”);

On the EJS side of things, it also comes with a bunch of view helpers which are analogous to the dumping ground that is HTML extension methods with ASP.NET MVC.

One roadblock I’ve hit is that while you have the power of a full-fledged library at your disposal with MooTools, in the EJS views, you are limited to only what it supports between the angle brackets. But as a wise man said: in the end, it’s just JavaScript so you can make it do what you want anyway.

How this will end up playing out when things get hairy is still anyone’s guess. But the pain-free spike has been pretty encouraging so far.

Kyle the Scriptified

This entry was posted in ASP.NET MVC, Javascript. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Hendry Luk

    I never realized that TDD and maintainability has gainned so much traction in Javascript land.
    I was assuming anything written in Javascript was automatically untestable and hard to maintain.
    Hence my panic when hearing MVC on JS. Things that were previously within my comfort strong-type IDE-friendly fully testable c# code (I’m talking about C of MVC), now have to move out to alien hostile javascript world.
    To me this is a huge leap. Thanks for the post, looking forward to your next posts about this adventure :)

  • http://codebetter.com/members/kylebaley/default.aspx Kyle Baley

    Hendry,

    At the moment, we’re re-evaluating whether or not where doing too much technology just for the sake of it. So we’re test-driving things using MooTools for the views rather than EJS. TDD experience is too early to tell.

    Re: Captcha. Works on Firefox for me. Haven’t tried any others.

  • Hendry Luk

    I don’t feel comfortable with the idea of MVC in Javascript, mainly because unit-testing is painful to a level that I don’t dare to even think about it.
    How’s your TDD experience with EJS?

    P.s., is it just me or codebetter’s captcha only works on IE?

  • http://codebetter.com/members/kylebaley/default.aspx Kyle Baley

    Victor: Actually, we considered JavaScript MVC. That’s how we found EJS. We felt that a full-on MVC framework would have been overkill but we haven’t discounted it completely yet. As it is, we’re still evaluating alternatives.

  • Victor Kornov

    one more JMVC link, this time with video http://javascriptchicago.com/blog/?p=65

  • Victor Kornov

    I’d consider http://javascriptmvc.com/ as client side MVC implementation, see http://bit.ly/cO4O7 for a quick introduction. Your choice of client side templates is an early version of jmvc’s Views ;) by same people.

  • http://codebetter.com/members/kylebaley/default.aspx Kyle Baley

    As far the Ajax client templates, someone also brought this up in the cross-post on my home blog. It will be something worth checking out for sure. I think this will become a more common alternative in the coming days.

    http://theruntime.com/blogs/jaykimble/archive/2009/06/01/clientscript-as-the-view-controller.aspx

  • http://codebetter.com/members/kylebaley/default.aspx Kyle Baley

    Given how often I do it, I should probably provide a definition in the header of my blog.

  • aReader

    My mistake then, I wasn’t familiar with that particular word as I’m not a native english speaker, so I got it out of context.

  • http://weblogs.asp.net/bleroy Bertrand Le Roy

    @aReader: and of course you didn’t read the next sentence? (“I jest, of course”)?

    @Kyle: I’d be interested to know what you think of the new Microsoft Ajax 4.0 client templates, which would give you something pretty close to this?

  • aReader

    “The main technical reason for this is because jQuery is getting too popular and we don’t want to be perceived as jumping on the bandwagon. We feel that if it’s good enough for Microsoft to throw its support behind, then we need to look at something else.”

    Yeah, that’s very objective and technical…