With that, here is my comment to Brian’s response to this debate:

I agree with you, Brian, in that his post may have been partly about the aspect you allude to. However, I also feel there is a real frustration in what he is really expressing with OO and CF. I noticed this same type of demeanor with some folks over the years when I strongly worked with CF. I myself have a Java background and as such tried to make CF follow the patterns and paradigms in the way that Java did. At the same time, I also recognized where CF fell short and thus worked with CF in it’s capacity as opposed to trying to get it to fit into the same context that Java is in.

With that, I encouraged other folks who worked with me to learn the better structured concepts of OO and MVC patterns and using the right mix of frameworks, such as a MVC, ORM, and IOC framework. The problem is, if you don’t understand these concepts from a fundamental level from the beginning without ever mixing CF in, they can be very overwhelming and start to crush the positive attitude that a CFML programmer may have.

Much of the time I also felt that parts of the community were pushing the use of so many patterns it was ridiculous and I think this is the storm that perhaps Marc was feeling.

To reiterate, I do feel that what you mentioned could be an underlying tone and perhaps fueling of anger and frustration, but at the same time I know from other CFML developers that I used to work with, his feelings at that show on the surface are valid and understood.

I think that most of the expert CFML developers in the community know and understand the limitations of the technology. Keep in mind, however, limitations is defined by what the requirements of a project are. Projects’ requirements should be written around the technology being used. Perhaps ColdFusion doesn’t have limitations in the sense of the word when it comes to “industry standard patterns”. From it’s beginning, it has always defined it’s own set of patterns that work for the CFML workflow. Developer’s need to understand to not try to redefine something that doens’t need to be redefined. If they have different needs in a project that are strong enough to fully set the project’s scope outside the circle of ColdFusion, then they need to choose a different technology.

CF continues to have a strong closely-knit community, something I have always enjoyed about it. Embrace the community, but don’t forget that at the end of the day, it’s up to you how you want to program your applications. And yes patterns are good, but don’t overdo it. Allow yourself to focus on the tasks at hand as well as having good design at the same time. True, not EVERYTHING needs to be “OO”.

Finally, change rarely comes at the perfect time. As web developers, the past 5 years or so have been changing very rapidly with new languages, patterns, frameworks, libraries coming out every day it seems. Don’t focus on being up to date on every single one and figure out how you can use each of them in your next project. Pick and choose what you want to learn and learn it well. In a time such as now, stick with what you know cause you need to hold on for a little bit longer, there are some rough winds up ahead.

I’m serious when I say don’t redefine something that is not meant to be that in the first place. I always uphold innovation in it’s highest regards, but there is innovation and then there is redefinition. They are NOT the same thing, so stop!

I want this series to be eye-opening for all the JavaScript developers who think Dojo died a few years back with it’s pre 0.9 days. The 0.9 release of Dojo brought fourth a fresh new start that provided huge increases in speed and stability. Since then, Dojo has blossomed into a full-fledged enterprise ready toolkit that is backed by an awesome community. If the last time you looked at Dojo was back in the pre 0.9 days (early 2007 and before), stop and check it out. Follow this series of posts to see for yourself the power that you can harness in your websites and applications.“these top quality developers know the ins and outs of JavaScript”

Dojo’s community is a special one. Drop by the #dojo IRC channel at irc.freenode.net to be greeted by a group of people who are there to welcome you and answer any questions you have. The best part is, they really know what they are talking about. These top quality developers know the ins and outs of JavaScript incredibly well and prove it when approached with questions. They are quick to provide examples, offer advice, and never talk down to anybody that drops by, seeking help. The developers of the toolkit are often on the channel to provide direct support but everyone else is also excellent and will help you out anyway they can.

In the coming weeks as this series progresses, you’ll see so many more aspects that make Dojo an excellent choice when considering your JavaScript library / toolkit of choice. This is only the beginning.

The Dojo Campus provides a wealth of documentation, tutorials for all levels, Dojo Cookies (kind of like recipes), and demos of cool features.

Below are just a handful of tutorials that are available to beginners in Dojo that really help you get started.

1. Dojo and Air, a fancy file uploader
   How many times have you had trouble uploading files to your favorite CMS? How many times did a client say “I am not happy with uploading one file at a time”? And last but not least, how many times did you implement a third party plugin/software/piece of magic to implement efficient file uploading?
   View tutorial >>
   
2. Fancy Rounded Corners
   Make great looking rounded corners on your elements using only a single image.
   View tutorial >>
   
3. Easily listen for events
   Custom events and Dom Events are all well and good for method-to-method functionality. It is a really common use case to connect some event happening to call another function, but when you get into really ambiguous, large applications, you need some mechanism to just say “hey, something has happened, act accordingly” … dojo.publish and dojo.subscribe provide just that mechanism.
   View tutorial >>
4. Rounded tabs with themes
   Everybody likes rounded buttons, rounded page elements and last but not least, rounded tabs. Fortunately dijit comes with great theming possibilities, so I will show you how you can make your own fancy rounded tabs using a simple image sprite and a couple of CSS classes.
   View tutorial >>
5. Separating Content from Presentation
   One of the cool things about Dojo is the dojo.xhrGet() function. It’s powerful because it makes transparent the browser dependent transports that make AJAX possible. In this cookie, we’re going to explore a simple use case in Dojo to separate content from the presentation of a page.
   View tutorial >>
   
   

Download your copy today and distribute it to all your friends!

Introduction

Initially when I started this survey, I had a half and half desire to test out Google’s Spreadsheet Form capabilities but to also get an inkling of what other developer’s thought about the JavaScript framework / toolkit they use. When I launched the survey and blogged, tweeted and emailed it to some folks, my best hope was to get about 100 submissions. I was delightfully surprised that when I closed it two weeks later, I had just a little over 600 submissions!

Read on…

This was a great learning experience for me in so many ways. First off, I never planned on this being a professional survey that would give me extremely valuable data. I knew that because of the methods I was using to gain submissions were going to be skewed based on the communities I sent it to. In addition, I provided no incentive for people to take the survey. I had to lure them in on the notion that it would be anonymous, very short, and I would be sharing the results later on.

As I watched the results come in the first week and I started to read some of the comments and suggestions, folks suggested a couple of ideas for the survey. With that, I added those changes immediately. Obviously, that is going to change my results slightly and I also won’t get quite as valuable of data had a left it alone from the beginning. But the suggestions were good enough that I implemented them. Also, any changes to the survey were made before it had reached a 200 response level. The majority of the respondents were submitting the final draft of the survey.

Another key point that I learned through this process was that I may not have been comparing apples to apples. A few respondents wrote in their notes that the “frameworks” I had put in the list were not all the same type of JavaScript frameworks. One respondent replied with the following:

IMHO it doesn’t make much sense to compare JavaScript libraries with such a different focus and feature set:

1. “JavaScript Libraries”
Prototype, jQuery and MooTools are merely cross-browser abstraction layers for DOM-oriented low-level tasks, e.g. for enhancing a traditional website.

2. “RIA Frameworks”
YUI, Dojo and qooxdoo are much more comprehensive, include widgets, a GUI toolkit and come with development tools like code compressors.

Once I read this, I realized this individual was completely correct. YUI, Dojo, and qooxdoo are quite a bit more expansive in their size, functionality, and overall support for building a “framework” for JavaScript. Right now is a good point to mention my underlying reason for conducting this survey. At work, I’ve been tasked to restructure the JavaScript architecture for the family of websites we operate. These are fairly large sites and are becoming very frontend heavy as we move to a static model employing RESTful requests to pull in dynamic data; our dependance on JavaScript will be increasing quite a bit over the coming months.

The main requirements I was looking for to implement in the new architecture was a faster executing JavaScript library (we currently use YUI), integrated test-driven development, JavaScript templating, lazy-loading of JavaScript source files, and the library needs to be namespaced to reduce conflict in our existing code.

Analysis

The first question that I get asked about the survey is which library was most popular. The answer there is jQuery. jQuery has been gaining quite a bit of steam lately and has generated a lot of buzz as well. However, just because it appears to be the most popular doesn’t mean it is the best and I don’t want folks to read the below results in that manner. Each individual developer needs to research and understand the different components of every library and framework they are interested in, to understand which components are going to be most useful in their projects. In fact, some projects may be require one library, and other projects may be best suited for a different library.

Many folks that read my blog are from the ColdFusion community and I felt that most of the respondents would be swayed towards jQuery. With that, I submitted the survey to a Django forum, a Ruby on Rails forum, a very large PHP forum, and TheServerSide.com (namely a large following of Java folks). I wanted to get as wide of an audience as possible.

Keep in mind when you read the responses below that the questions were all aimed at the developer’s feeling of the framework they used. While most responses are going to be biased, some developer’s were on the framework because they had adopted it early on and couldn’t switch or were forced to use it because of the project that they came on to.

Library Preference

The chart below illustrates the “Which JavaScript framework do you use the most in your projects?” question:

As I mentioned earlier, jQuery clearly dominated this question. My opinion on why is that jQuery is insanely easy to implement into your projects, it’s fast, it’s easy to pick up, and it is seems to be a buzzword among blogs. For a lot of developers, it is the clear choice as it does everything they need it to do.

Quality of Documentation

I felt that this question provided the most accurate results as documentation is something that developers have to be in tune with on a daily basis when working with a particular library. If the documentation consistently performs poorly then a developer is likely to stick with that toolkit.


The chart below illustrates the following question, “In regards to the framework you chose above, rate the quality of the documentation provided by the creators.”:

As someone who has worked with YUI in the past year, I would also agree that it has excellent documentation compared to other libraries I have worked with in the past.

Quality of Community Support

This was an interesting question. I am basically asking the developer to rate how they feel about the overall quality of the community support for the library. This can be just about anything such as a forum, newsgroup, IRC channel, blog, etc. While qooxdoo did rank the highest, it also has a very small following, hence the data is not as sparse as it would be for one of the large libraries such as jQuery and Prototype. However, it is still good to note that those who do use qooxdoo seem to be a passionate group.

The chart below illustrates the following question, “Rate the quality of support provided by the community.”:

Light-Duty / Heavy-Duty Performance

If I were to do conduct this survey again, I would leave these two questions out. Looking back, I realized that the information provided was pretty much useless for a few reasons. First of all, the question asks to the user to report how they feel the libraries perform under certain conditions, but I gave no specific cases in which for them to test these observations. Second of all, there is already much more valuable statistics available from SlickSpeed.

Ease of Implementation

In questioning about the ease of implementation, I was asking the developer to describe how easy they felt it was to not only install the framework into their page (whether the code was hosted on Google/Yahoo/AOL or whether they had to download it) but also to integrate the library functions into existing code/functions.

Again, it does not surprise me that jQuery sits on top for this one but I think it is due to it’s overwhelming popularity and the buzzword case I mentioned earlier. The problem with this question is that I am not asking the developer to compare the ease of implementation to their chosen library versus another one. The data has no relativity and is also pretty much useless. That data represented could contain many developer’s who have only ever tried jQuery and the installation + integration was easy! But perhaps if they had tried something like Dojo or YUI, they may have found those even easier and rated jQuery lower. It’s hard to determine from the data provided what exactly the developer is communicating for their chosen rating.

Perceived Popularity

This may sound like a funny question and that’s true, it is kind of a funny question. My motive for this question was to extract if the developer was using a framework like YUI, if they personally knew that it was not a very popular framework? And if so, it’s clear that they are going against the flow in using it. Most likely in this case, the developer’s using the “less popular” libraries are likely using them because they prefer the organizations that back them up, prefer the functionality, or are forced to use them. Nonetheless, I was very surprised to find the ZK framework come in 2nd for this. However, this goes back to the fact that a very small sample of the ZK community was captured in this survey.

The chart below illustrates the following question, “Rate how popular you feel your chosen framework is above similar JavaScript frameworks”:

3rd Party Plugin Quality

Plugins may or may not be important to developers. In my opinion, they should be very important. As a busy developer, you should always be on the lookout for the opportunity to use pre-written code to speed up your development. Granted, you should always inspect the code if you can and test it to make sure it will not only suit your needs, but it is implemented the way you would do it and that it is well-designed. The latter is what I was trying to get at. I wanted to know how developer’s felt about any of the plugins that were not included along with the library itself.

While a lot folks like the jQuery library, I’ve also heard many say what they don’t like about it is how quickly their page can grow in size by pulling in more plugins. This definitely makes sense as when the user loads a page, their browser has to download all those external JavaScript files slowing down the page quite a bit. It would be different if the library contained a dynamic loading method that allowed the plugins only to be actually downloaded when they were being used such as the dojo.require() method provided by the Dojo Toolkit.

The chart below illustrates the following question, “If your framework supports 3rd party plugins, rate the average quality of those plugins in terms of documentation, stability, quality, and implementation”:

Conclusion

I felt that this was a great learning experience for me in a few ways. One, I learned that developing a survey needs to take some more time to come up with questions that are going to more accurately provide the type of data you are looking for. Two, broad results are difficult to achieve on your own. Three, Google Docs is pretty darn good at creating an easy solution for forms and data entry/input! Four, comments and suggestions entry boxes on surveys are one of the most useful questions. So often I don’t fill these out because I am too lazy, but I received the most valuable input in that question.

When choosing a JavaScript library / toolkit / framework, do not choose the one that is most popular for the sake of it. Really dig deep and spend some time on it to find out the strengths and weakness of each one to ensure you choose the right tool for the right job.

I hope the information above was useful if not just generally interesting. As promised, here is the raw results from Google Spreadsheets.

In addition, please leave comments on what you thought about this experiment. Would you like to see another one focusing on different aspects and getting more comparisons in?

Rest assured, I will begin looking at the data this week. I hope to have a summary post in the next two weeks along with a link to the raw data.

Hang tight and thanks for your patience!

I would be very grateful for you to take this survey and to pass it on to others if you would be so kind.

I understand that the data that I receive from this will most likely be skewed and extremely inaccurate on a broader level, nevertheless I am quite curious about the topic. In addition, I will most likely be spreading the word on the results of this survey. In addition, I’m also aware of the existing posts available in regards to the measured speed of these frameworks.

Thanks!

Please take this short survey on JavaScript Frameworks

Alternatively you can fill out the form here:

Stores that are planning to close after Christmas are still selling the cards through the holidays even though the cards will be worthless January 1.
There is no law preventing them from doing this. On the contrary, it is referred to as ‘Bankruptcy Planning.’ Below is a partial list of stores that you need to be cautious about.

It seems Amazon.com gift cards are probably the safest bet.

• Circuit City (filed Chapter 11)
• Ann Taylor 117 stores nationwide closing
• Lane Bryant, Fashion Bug and Catherine’s to close 150 stores nationwide
• Eddie Bauer to close stores 27 stores and more after January
• Cache will close all stores
• Talbots closing down specialty stores
• J. Jill closing all stores (owned by Talbots)
Pacific Sunwear (also owned by Talbots)
• GAP closing 85 stores
• Footlocker closing 140 stores more to close after January
• Wickes Furniture closing down
• Levitz closing down remaining stores
• Bombay closing remaining stores
• Acorn closing down remaining 36 stores (owned by Christopher & Banks / C.J. Banks)
• Zales closing down 82 stores and 105 after January
• Whitehall closing all stores
• Piercing Pagoda closing all stores
• Disney closing 98 stores and will close more after January
• Home Depot closing 15 stores
• Macys to close 9 stores after January
• Linens and Things closing all stores
• Movie Galley Closing all stores
• Pep Boys Closing 33 stores
• Sprint/Nextel closing 133 stores
• JC Penney closing a number of stores after January
• Ethan Allen closing down 12 stores
• Wilson Leather closing down all stores
• Sharper Image closing down all stores
• K B Toys closing 356 stores
• Lowe’s to close down some stores
• Dillard’s to close some stores

If you are familiar with Spry, than the above makes complete sense. I came across a problem this evening, however, when using very similar code as a filter mechanism for a separate dataset. The problem with the above code is that once it is populated, the select box will by default choose the first value as selected. If you are filtering data, you want the initial/reset state to be blank and not have any values.

Since I am using spry:repeatchildren to repeat my option tags, I cannot simply drop in a blank option tag above the current one because than it would also repeat for all the other rows in the dataset.

Thanks to the built in variables for each dataset, we can get special information during the loop of the dataset rows. This is valuable information since we technically need to drop the blank option just above the first row of the dataset.

We modify the above code to be the following instead:

The spry:if simply checks if the loop is on row number 0 and if it is, it will drop in that option tag. Otherwise, it gets left out on all of the other rows.