In this wonderpost, I questioned the use of jQuery in the mind of the purist MVCist. (If that’s not a word yet, it is now and I expect royalties.) Now I’ll flip it tool style and ask it from another direction: Can MVC survive without jQuery?
Here’s the situation: I have a site that I made a while back (Basically a phone friendly chat room emulator) that was kind of experiment on a couple levels, one being the use of Entity Framework and WebForms. (It’s here if you are curious… right now you have to make an account though. Never got around to allowing non logged in users.) Another part was to see if I could make a multi phone compliant page that had to be fast and work on as many phones as possible. (Anything with a browser at least) And had to be touch friendly. (No links, just buttons)
Yeah turns out what those buttons did was at the heart of my issues. You see, with WebForms, everything done on a page is meant for that page. Sure you can defer how things are handled from the page to another tier, but the action itself belongs to the page. For example, say that a user wanted to make a room a favorite, well there’s a button named favorite that he/she clicks to do so.
In webforms, the Room.aspx page would handle the Favorite button click and the current user’s favorite list would have the room removed or added depending. But the call to the add/remove would be handled by the button’s click event and then the page would be reloaded. Something we in the know call “easy”. (Like that word? Use it. It’s free because I’m such a nice guy)
Now with MVC it’s a whole new ballpark. With controllers, it becomes of question of what controller should handle this. It could go onto the room controller, but in the end it deals with a user and adding something to the user. So it’s fair to say that this is probably a job for Superman if Superman happens to be a UserController or you’ll most likely end up repeating code.
Now the issue: How is this handled? Whether link or button, something has to be posted to the user controller. Posting to the controller means that the controller, on finish, has to create a model and send it to a view. Well this kind of sucks doesn’t it? The user clicks the + Favorite button and bam is taken to a whole new page.
SURPRISE IT’S BEEN ADDED TO YOUR FAVORITES!
Not what I would call fluid. The other thought it to have a redirect, which in the end is more fluid in that it takes the user back to the original page BUT with that you have to send a lot of information back and forth. After all, in MVC a lot of the information for a given “page” is passed using get. So for instance you have a room with a roomid and a page number and a count of items to show and possibly a sort you’re looking at:
Which means all of that has to be sent to the User controller in order to save the state, has to be put in session/some kind of user cache, or you just send the entire url. In any case, something has to be tossed around for this to work. More seamless than the other way but it is a lot of work for something so simple.
When it comes to ease of UI design, jQuery/asynchronous operations are a must.
Why is this a problem? For the most part it isn’t. Most people aren’t going to try something like EyThere (Wouldn’t recommend it, it was a pain) since how many people create sites with multiple phones in mind? However, it does serve to show what seems to be a glaring annoyance with MVC. Either use asynchronous calls or just sink.