Years ago I considered Javascript to be more or less of a joke as a language.  At the time browser implementations made creating a consistent implementation both dangerous and time consuming.  Time passed and several very significant things happened:

1. FireFox 1.0 and the modern browser.
2. Google Maps
3. jQuery
4. Web-scale loads

Because of these developments, much of my recent work has been able to leverage Javascript more fully thus making the browser an integral part of a fully distributed system.  Specifically, with Javascript we can leverage the browser to handle portions of the load and to enhance the user experience.  Ever noticed how during intermittent network connectivity, Gmail will let you know that it’s trying to send your email?

Here’s the general idea:

1. Have the server render views in pure HTML+CSS and view models as JSON—avoid any kind of server-side code.
2. Use a Javascript templating engine such as jQuery Templates to bind the JSON model to the view.

Granted, you must be sensitive to a search engine’s inability to index in this scenario, so this should generally be used for pages where user-specific data is shown.

An interesting advantage of this pattern is the reduced coupling on the server-side component of the system.  In fact, I wouldn’t particularly care if it was written in PHP or Ruby or whatever.  As long as it could push down the appropriate HTML and JSON, I could easily have the browser take care of everything else.

Warning: If you do this, your HTML designers will love you. No server side markup in the views? Designers are in heaven. And for them to be able to test different aspects of the view by changing simple JSON files—all without having a local web server (IIS) or even a local database. Life can’t get any better than this!

Another advantage that I’ve talked about previously would be to pre-render JSON views into files and to store them on some form of CDN. In fact, you could potentially store your HTML views on a CDN along with pre-rendered JSON view models such that users would be unaffected by outages of your system—at least for the purpose of querying and viewing application state.

Conclusion

One of my primary objectives in programming is choice. I want to be free to adapt and innovate my system. Tight coupling is the enemy of choice. Once you’re coupled, you’re restricted in your ability to choose. This isn’t to say that you write so many layers of abstraction that you can swap anything and everything. Instead, it’s about making wise decisions relative to areas that have a tendency to change quickly.

By making views pure HTML with CSS and by leveraging Javascript templating to integrate the view model, we have significantly reduced any requirements on the server for performing this work for us.  Server side <% %> tag soup?  Gone.  No need to worry about Razor.  In fact, the server side becomes very naïve and almost an afterthought in the entire process.  The result is that we really start to focus on the total user experience and ultimately delivering business value instead of focusing so closely on the technical aspect of the business.

Jimmy Bogard’s recent blog post entitled Cleaning up POSTs in ASP.NET MVC was a great read.  But I wanted to share another method that I have used with great success in recent months.  One of the primary issues that Jimmy is trying to solve in his blog post is that of DRYing up duplicate code by creating application-level infrastructure code that can easily be used and varied within certain boundaries.

According to REST-based principles and general best practices in web programming, a GET request issued to a server should not change application state.  It’s only issuing a query.  The code to serve this kind of request is simple enough—just go and get the data.  But a POST (and a PUT for that matter) is another story entirely.  In this case, the user is instructing us to invoke some mutating behavior.  According to the pattern, the basic steps are:

1. The user enters data into a form and clicks submit.
2. The browser POSTs the data to the web server.
3. The model binders facilitate validation of the incoming data for correctness, e.g. are all of the fields populated with reasonable values?
4. If the proper input values are incorrect or missing, the controller returns an error view to the user.
5. If the input passes all validation,  the controller invokes the desired behavior and redirects the user to a success page.

All in all, it’s a relatively simple pattern and one that is used with much success all over the web in virtually all web frameworks.

Interestingly enough, one of the reasons for the POST-Validate-Redirect pattern has to do with default browser behavior.  For example, if we didn’t redirect a user and instead just showed a view, a user refreshing that page would get that wonderfully confusing “Do you want to re-post this data?” message.  Hence the redirect at the end to avoid the problem altogether.  Typically we redirect users to a page where they can see the results of their operation so that they know its successful.

But what if your views are updated asynchronously?  In this case, wouldn’t it be confusing to your user if you immediately redirected them to a page that supposedly contained the results of the operation but the views were not yet updated with the results of the operation?  And what if we wanted to submit data to the server without making the user leave the current page?

Enter a new paradigm: Ajax.

[CAVEAT: I realize that this requires Javascript to be enabled within the browser.  I’ve decided that I’m not catering the .5% to 1% of people on the web who disable Javascript.  There are too many benefits.  Also note also that SEO practices are not relevant here because the user is submitting data to the server.]

One of the techniques that has worked wonders for me is facilitated by Ajax requests.  The general idea is something like this:

1. The users enters data into a form and clicks submit.
2. The browser POSTs the data to the web server using an Ajax request (typically through jQuery).
3. The model binders facilitate validation of the incoming data for correctness, e.g. are all of the fields populated with reasonable values?
4. If the proper input values are incorrect or missing, return a JSON object to the browser containing “model state errors”.
5. If the proper input values are correct, invoke the appropriate behavior (which usually involves dispatching a message).
6. Return HTTP 200 to the browser.
7. Have some client-side behavior that updates the client-side display model according to the interaction.

This approach has a few significant benefits.  First and foremost, all of my controller code is dirt simple and very clean.  Second, the user never experiences page reloading.  Instead, the browser-side view is updated with the results of the operation—much like a desktop application.  Furthermore, because the client-side views and associated behavior are completely separate, it becomes very easy to test each part of the system in isolation.  The has the effect of reducing my server-side code to something that gives back HTTP 200 or a JSON object containing input validation errors.  In many regards, ASP.NET MVC becomes overkill.  Even FubuMVC (an awesome project) is waaaay too much.  I just need something to receive input, do a little validation and business verification before dispatching a message.

All of the above has been embodied into a small Javascript library I wrote (along with a corresponding server-side ASP.NET MVC counterpart) that I call Mvc2.TaskUI.  I have been running this bit of Javascript and server-side C# code in production for several months now and it has been working great.  The main part is actually the client-side Javascript behavior that I wrote as a 116-line jQuery plugin.  It performs a kind of Ajax I call “Hijaxing”.  Interestingly enough, most of the code isn’t in hijaxing the form submit and posting it to the server.  Instead most of the code is related to error handling and displaying input errors.

Conclusion

This is definitely not a cure all.  But it does solve a lot of pain…as long as your situation fits into the prescribed model.

As a committer on NServiceBus, I’m typically running the code from the master branch head in production.  Crazy, huh?  I commit made against the master branch not too long ago affected my application code in its ability to properly handle a message.  But it didn’t cause me any long-term grief.

Why?

The answer is simple.  Guaranteed delivery.  The messages couldn’t be processed so they were forwarded to an error queue. One in the error queue, we were made aware of the problem and were able to fix it in short order.  From there, it was a simple matter of moving the messages back to the intended queue for processing and everything picked up where it left off.

Try that with RPC.

I have just released v2.0 of my CQRS EventStore project.  I have been amazed at and delighted by the number of contributors the project.  Interest continues to grow and implementations for various storage engines continues as well as other serialization strategies.

Download

Download the .NET 4.0 release here: https://github.com/downloads/joliver/EventStore/EventStore-2.0.11157.39-net40.zip

Download the .NET 3.5 release here: https://github.com/downloads/joliver/EventStore/EventStore-2.0.11157.39-net35.zip

The Roadmap

First and foremost, any volunteers to help me with the NuGet package?  Ideally we’d have one package per storage engine that contains .NET 3.5 and .NET 4.0 assemblies.

Furthermore, I’m strongly considering removing .NET 3.5 support moving forward and only supporting .NET 4.0.

For v2.1, I’m also looking to merge in the CommonDomain project.

Let me know what you guys think.