I ditched quite a bit of some complicated server side state management / screen workflow around the MVC framework today in favor of just a little bit of client side code with the jQuery.Form component. The lesson learned today for me, and not for the first time, is to keep your MVC framework usage and the server side views as simple as possible. Take all that time you saved on fancy server side work and apply it to serious jQuery-fu. I would have positioned our design so much better upfront if I’d just taken the freakin’ jQuery in Action book home over the weekend early on our project instead of doing so many deep dives into the MVC code.
Of course, since we’re doing so much more jQuery coding on the client, it’s making it more and more important to test the UI in multiple browsers. I hit one of those cases today where something worked perfectly in Firefox (what I think all of us use day to day) but not in IE. We already use QUnit quite a bit for unit testing client side Javascript, but it’s only running in IE during the CI build. We also have end to end tests with Watin, but again, that’s IE only. I think we’ll make the minor move to write a QUnit/Firefox runner for CI, and I think I’m going to go take a much longer look at Selenium RC which supports multiple browsers for the end to end testing.