I came across a neat site called dummyimage.com that allows you to append an image size to it’s URL as so: http://dummyimage.com/300×250. However, what I didn’t like about it, is that I could not add text to the image to describe what the image is a placeholder for. I took upon myself to create my own service that does this and I plan on expanding it to do more as well.

Last night I created fpoimg.com. It works in very much the same way as dummyimage.com, only you can add text to your images. The next iteration of the site will allow you to change the colors of the background and foreground. Anyway, the way you use the site is if you want to create a basic placeholder or FPO (For Placement Only) image you simply go to http://fpoimg.com/345×480 and the image will be provided to you. You can save this image if you like, or you can refer to it directly in your code such as in an image tag:
<img src="http://fpoimg.com/345x480">

The first number is your width in pixels, the second is your height in pixels. Additionally, if you want to add some text to the image to describe it as a placeholder, you simply append that to the URL as so:
http://fpoimg.com/345×480/Advertisement

This will create the following image:

It’s really that basic! Here are some more examples:

I of course do plan on tweaking this service as needed such as caching the images and providing the ability to change their colors. If the service becomes more popular, I have a feeling I’ll need to invoke some kind of limit as well so as not to crash the server.

The book that I’ve been writing for the past nine months is finally published and available for purchase. Below are the details as posted on the companion site, startdojo.com:

Getting StartED with Dojo is finally available for purchase! About nine months ago I was approached by Apress to author a book on the Dojo toolkit. After a long journey of authoring my first book, the final phase is complete as the book is now officially published and out in the wild. While the actual publish date was December 28th, I’m sure it will be a little while before you start seeing it on the shelves of popular brick and mortar bookstore shelves such as Borders and Barnes & Noble. For now, you can certainly order it on Amazon.

Getting StartED with Dojo has fan page on Facebook:
Getting StartED with Dojo | Promote Your Page Too

You may also follow @startdojo on Twitter for up to date news and information relating to the Dojo toolkit and community.

I will mostly be using this site for updates to the book such as corrections to the code and copy. In addition, I will be posting tips and resources for learning more about the Dojo toolkit. A lot of work went into the creation of this book and I hope you enjoy it.

Every year Amazon.com has some incredible deals on some of their merchandise. This year, they’ve started even earlier to get you in the holiday shopping spirit by starting to offer their deals TODAY.

They’ve said that all of their deals are limited in quantity but will line up new items after they sell out throughout the day.

Visit Amazon.com’s Black Friday Deals

It’s been a long time since I’ve posted, I know it, but I have good excuses! The first is still an excuse as I’m still working on it, but, I was asked by Apress / Friends of ED to write a book on the Dojo JavaScript Toolkit. It’s been quite the journey to say the least. It has been a desire of mine in the past few years to publish a technical book. When Apress approached me, I couldn’t resist. It’s been a lot of work but it’s almost done. You can check it out and pre-order it on Amazon.com! Needless to say I’ve had my head in Dojo quite a bit the past few months.

With that, I’ve also been working on a very large project at work that I’m one of the technical leads on. That project is the Gap Casting Call which is a contest that Gap runs every year to find the next faces of BabyGap and GapKids. They partnered with us at Family.com to build and host the online photo contest. Enter your kids to get a chance at winning! There are a lot of great prizes and a lot of great entries!

On to my next project at work where I get to learn and use GWT. More to come in the future I’m sure. Until then, thanks for staying up to date with me, and sorry it has been so long since I’ve posted.

Reading Brian’s tweet this morning, I decided to read more about this whole OOP Debate. Unfortunately, I didn’t really have time, nor the interest to read Marc’s entire post. But I read as far to the point where he comes to the epiphany that CF is not Java and that it can’t handle the same patterns the same way that Java can…um…duh! I thought this was a known fact about ColdFusion / CFML. Rewind many years to the creation of ColdFusion–that was the whole point of coming up with ColdFusion was to have a language that did not require the sheer complexity of languages like C and CGIs to connect to databases. I think for the most part, ColdFusion has always aimed to be easy or easier and less code etc. If you want to program more along the lines of what Java supports and the patterns it uses, then use Java. Seriously. ColdFusion is not Java and it shouldn’t be. It should be what it is and do it well.

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!

Dojo is incredibly fun to use and I finally enjoy programming JavaScript, again! I’m starting this series of posts to communicate the message that anyone not programming in Dojo, is missing out on an extremely, powerful, and lightning fast toolkit. In addition, while many libraries provide only the DOM manipulation, animation, and CSS selector tools, etc. –  Dojo not only provides all of that, but so much more with it’s companion libraries, Dijit and DojoX. “a fresh new start”Dijit, which encompasses a complete library of themed, skinnable UI widgets that have full support for accessibility and localization baked right in, but also provides a full framework to build your own custom widgets in the same manner. DojoX is a library of “inventive & innovative code and widgets”. Build complex charting applications and vector drawings alongside with making your HTML applications available to users offline. DojoX is the future of JavaScript available to you today.

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.

I’ve been using Dojo a lot lately and have really gotten knee deep in development with it. Best of all, it is so easy to do so. The number one thing I’ve noticed is that the community is great–very approachable and they really know what they are talking about. These are true programmers who love what they do, and it shows in this toolkit.

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 >>
   
   

For those of you who have been asking (and I suppose those of you who haven’t) a cheat sheet is finally available, designed by yours truly but with full API generation by phiggins over at #dojo and much input from the other folks on that channel! And as a special bonus, it’s fully compatible with Dojo 1.3 (just released)!

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?

Thank you all who participated in my Developer’s Insight: JavaScript Frameworks survey. Topping out at 604 total responses in less than 2 weeks made this a huge success. It even made it to the frontpage of TheServerSide.com! The downside of this many responses is the analysis on all the data.

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!