dbaranski.net

This title seems relatively understandable, but I assure you I don’t mean libraries like, JQueries, Dojo, or YUI..  Quite on the contrary. The difference between frameworks and libraries is the pivotal point.

Libraries vs Frameworks

Libraries simply provide functionality. For example, JQuery is an awesome library. It can enhance any website adding interactivity with minimalistic and efficient code. When people think of frameworks on the other hand. Things such as Django and Rails come to mind. The difference might be coming more clear now.

Most importantly, frameworks provide an MVC structure to work on. They provide a structured approach to getting to job done. Good framework will keep your code clean and actually give you less that will “just work” better.

Web application developers generally neglect the use of MVC in highly dynamic web pages when they really shouldn’t. To be specific I believe that the Model (M in MVC) is ignored quite too often.

JavaScript does have frameworks, quite a few in fact, with some of the most notable being SproutCore, Cappuccino, and JavaScriptMVC.  Far too often they are unheard of or unused.  From what I’ve seen it’s simply the complexity level and browser support (slow JavaScript) that really keeps people away.  But as those tides turn it’s time to re-think our front end strategy.

The real divide

Here’s what I suggest all good web apps should look like.  A two-tiered approach.

Front-end MVC

The part of the MVC that gets trampled the most in front-end coding has got to the the Model.  Without it, data has no form of encapsulation and becomes a big pile of variables.  It’s hard to find cohesion between data-sets and the front end becomes complicated to understand.  Models also make it easy to cache previously used data.

Views seem harder to picture but it would be the currently visible portion of the web page.  Currently active and running widgets would account for the View here as well.  Anything dealing with or CRUDing (Create, Read, Update, Delete) HTML.

If you can segregate your JavaScript into logical Models and Views then Controllers will naturally be responsible for handling the actions and events.  And JavaScript is really good with that stuff

Cleaner Code Ahead!

Always think of web applications as two separate tiers (which they are!) and you will realize that the browser deserves good object design as well.

Many people use JSON nowadays to output information. Its lightweight and awesome! So why not. But I find that people neglect to maintain an appropriate syntax, if you will, while writing JSON output.

Now, what I mean by “wrappers” is that most examples I’ve seen send back a JSON list. This list should always be wrapped with additional server information in case of internal server errors (500 errors) or the need for other clarifications (errors, total item counts, etc).

A basic example wrapper

Using this Style of wrapper I know:

• There were no problems on the server side (the status entry)
• There are 10 results in total for whatever I want (the resultCount entry)
• The results are offset by 3 (the resultOffset)
• I have 3 results to display to the end user (the resultSet entry)

Note that some of these parameters could be optional (like offset).  But make sure that whoever is writing the JavaScript knows this!  It could otherwise cause unrecoverable JavaScript errors.

Server Error handled gracefully

Here’s an example of a server 500 that, despite being completely unrecoverable, still gracefully displays JSON as to not cause execution errors in the browser.  Note that I omitted resultOffset as I am using this parameter optionally.  I do return an empty resutSet though.  JUST in case someone forgot to program any error handling in the JavaScript.

Looking Forward

This is only a simple example of what your wrapper should include, feel free to add other information like a timestamp for when it was served or other important data.  To get you started look at some examples from Google or Yahoo for ideas.