Results tagged “frameworks” from Interface_

Since Paul wrote some posts on JavaScript frameworks before (part 1, part 2), I thought I’d mention something about CSS frameworks. I’ve begun using them on several projects and have found them to be a huge help. I find that laying out the page is easier, the most common styles are already set and browser bugs are few and far between.

What the heck is a CSS framework?

It’s pretty much a library of pre-built styles that help with designing a Web site. The goal of using a CSS framework is the same as other programming frameworks — to speed up development and ease collaboration between developers. A List Apart wrote a good article on the subject.

Usually, when beginning to style an XHTML page, I’d start with a few basic styles to override some of the browser’s defaults. Then I’d throw in a few other styles for hidden “skip-to” links and basic typography style. This would save me a load of time and without realizing it, I was using a CSS framework!

Other designers used similar methods and one of the first to become widely adopted was Eric Meyer’s “reset styles.” It was a set of styles that would override a browser’s default styles and give the designer a blank canvas eliminating a lot of browser testing.

CSS frameworks have taken this one step further and have included styles for typography, forms, browser bugs and layout grid systems. The methods in which styles are applied have structure so one designer doesn’t have to decipher another’s naming conventions.

It seems that the Ext team has updated it’s licensing terms to a more restrictive license. Paul Duncan has an excellent review of what changed and what it means to developers who are considering using it.

What this means for us on campus is that if you are going to use the Ext framework, be sure that you read the license fully before you begin your project, and make sure that your project wont conflict with Ext’s new licensing.

In my previous post, I explained what a Javascript Framework is and the criteria by which I used to determine which one I chose. In this post, I’ll talk about which framework I ended up going with, and how it did, and some cases, didnt, meet that criteria.

Before I begin, I need to point out one downside to using a framework that I didn’t mention previously. That is, the code you write for one framework, will most likely NOT work for a different framework. In other words, if/when you decide to switch frameworks, you’re going to end up having to either rewrite your code, or continue supporting the “old” framework even though you might not be using it anymore.

I played with Ext, prototype (mostly because of scriptaculous), dojo, and motools, and ended up choosing mootools. The one that I didn’t try out that I am still planning on evaluating is jQuery.

So why mootools?

1. Does it add code bloat to the user’s download?

One of the great thing about Mootools is you can customize the framework to only include the components that you need. This allows you to customize the mootools javascript file to be as small as possible. Even with every possible component added, the framework (compressed using the YUI compressor) is only 64KB in size. That isn’t to say that other frameworks are larger. For example, jQuery is only 29KB (compressed).

2. Will it work with all browsers?

MooTools is compatible and fully tested with Safari, Internet Explorer 6 and 7, Firefox (and its mozilla friends), Opera and Camino.

3. Does it have solid documentation?

This was one of the deciding factors for me. Mootools has excellent documentation. While it is not 100% complete (for example, there seems to be no documentation on the bind() function), the documentation is easy to navigate, at a glance you know what the function expects (arguments), what it should return and contains a sample of the function in use. In my opinion, it has the best documentation of any of the javascript frameworks (though Dojo comes in at a close second). In addition, Mootools has an incredibly thorough tutorial.

4. Does it support code reuse (is it extensible)?

Not only does it support code reuse, it is a primary focus of the Mootools framework. The whole framework is class-based and modular (which is why you dont need to download every available component). It has been designed to assist Javascript developers to more easily build reusable code. Because of this, there is a multitude of plugins/extensions available for Mootools.

5. Is it unobtrusive and will it support graceful degradation?

This was also one of the deciding factors for me. Mootools contains a custom event called domready that executes a function when the dom tree is loaded, without waiting for images. What does this mean to you as a developer? When combined with the various selector methods, It means that you can keep ALL of your javascript in the head (or in a separate javascript file) and not have to litter the html with javascript snippets, or worry about “element does not exist” error messages (because you tried to access the element before it loaded). It also means that you (or your web designers) can more easily design the page such that, if the user doesnt have javascript available, they wont see any difference.

For example, on the RJI site where we first used the MU Story Gallery rotator, the page is designed statically to display one story, headline, and teaser text. If you do not have javascript, or have it disabled, this is exactly what you will get. But if you have javascript enabled, on domready, the script will take over this section and create the rotating story gallery.

6. Does it have an active community?

In a word, yes. Announcements are regularly made regarding updates to the framework (v1.2 is close to being released) and answers to my questions in the forums are usually answered within the same day.

7. Does it play nice with others?

Yes, and no. Mootools (and Prototype ) both make heavy use of altering the prototype of native objects (String, Array, Function). Contrast this with JQuery and Dojo which are highly name spaced. What does this mean? This means that JQuery and Dojo will (usually) place nice in situations where you either don’t control the other javascript present on a page, or where you want/need to use more than one framework or javascript collection. Mootools, because of the way it alters the native objects, when used with other javascript libraries, can sometimes cause conflicts. So if you use another framework or library that alters the native Array object to include an .each() function, you’re going to have problems. Of course, this is no different than having a library that has a function named foobar() and then try to use another library on the same page that also has a function named foobar().

As I mentioned earlier, Mootools may or may not be the right framework for you. In fact, I plan on giving jQuery a try in a future project just to see if I might like it more. I strongly encourage you to download two or three different frameworks, and try them out. See which one “fits” you best. But no matter which one you end up going with, you will be AMAZED at how much more efficient your JavaScript development will be.