Survey: Which JavaScript Framework Should Codestore Examples Use?

A quiet spell on this site can mean one of two things — either I have nothing to talk about or I have too much to talk about and I can't decide where to start.

The latter seems to be the case at the moment. There's so much I want to get on here, but I just don't know where to start.

Most of what I want to talk about is either AJAX or (less specifically) JavaScript based. The trouble is I can't decide which framework to base my demos on. In the past I've used a mix of Prototype, jQuery and Mootools. Personally, I prefer Prototype, but have used the others merely for my own exposure to them and because they appear lighter.

What matters though is that the demos I produce can be used "off the shelf" by as many of you as possible. To do that I need to know which framework to target. Which is where you come in. Please either use the form below or open the survey and place your vote there.

Which framework should Codestore Downloads Use?

Should be framework independent
Don't really care
None of the above

As far as I can tell there's no obvious winner. Maybe Dojo seems the obvious candidate as it will soon be a part of development toolbox, whether we like it or not. Maybe it should be the one the most of you use. I just don't know.

What I'd really like to do is mimic the Ext toolkit, which provides an "adapter" for each of the other frameworks.

Realistically we only ever use a couple of functions out of any given framework. Normally the $() function and an Ajax() function and maybe a few others, such as show() and hide() etc. What it's possible to do is map your own functions to these, based on the framework used.

For example: Ext has a function called Ext.get(), which simply returns the result of a call to YUI's Dom.get() function or Prototype's $() - depending on which you're using as the base framework.

All you have to do is make sure you change to using the right adapter. That to me seems like the ideal choice. It does however mean an extra level of code and complexity. Before I go down that route I'd like to see whether there's any majority vote on the above poll.


    • avatar
    • Richard Shergold
    • Tue 4 Mar 2008 05:01 AM

    I think Dojo, as IBM are taking us down that route anyway.

    • avatar
    • Jake Howlett
    • Tue 4 Mar 2008 05:09 AM

    Is that a good enough reason though Richard?

    I'm curious to see how it will be "included" in Domino.

    Something tells me it will be in such a way that we'll never have the latest build and will just end up using our own choice of framework instead. Even if that happens to be a more up-to-date version of Dojo.

    Will it be included in the same way Java is included?

  1. My preference:

    For complex demos, Ext.

    For simpler demos, Mootools.

    Dojo may be THE framework after some IBM treatment, but currently, I'm in favour of Ext for Rich Internet Applications.

  2. There's a good article comparing the major toolkits on Infoworld this week;


    • avatar
    • Jake Howlett
    • Tue 4 Mar 2008 06:08 AM

    Thanks for the link Ed. I'll give it a proper read later on. I skipped to the last paragraph for now, which says this about picking a tollkit:

    "Oh, just close your eyes, push your finger toward the screen and choose the name that's closest to where your finger lands. They're all good."

    This kind of sums up how I feel about the choice really.

    What I wanted to do though is choose the one most of you are using already. Hopefully this will make it easier for a majority of you to use demos without having to port them.

    I'm always afraid that people might write-off some demo I've spent ages working on merely because it uses Mootools and they always use Prototype (or whatever) which would be a shame.

    If I could write an adapter so that all you had to do was specify the toolkit in use that would be ideal. If not I'll just go with the majority vote.

  3. Jake,

    I'm working / suffering right now with dojo.

    It's IBM's choice. So that means, plenty of notes developers working on it. It should imply plenty of examples to be used directly with Domino. ????

    On the other hand, there's a lack of documentation and it's really tricky and plenty of undocumented features.

    Rocky {Link} made a nice presentation in LotusSphere. It shows many features you can get with dojo and Domino working together, but when you dig in the code, wow!, are necessary so many tricks to make it work ? It's not a direct approach to develop an application.

    And about YUI, the other day someone asked loudly, what's going to happen to YUI library if MS buys Yahoo ?

    Miguel Angel

    • avatar
    • Jake Howlett
    • Tue 4 Mar 2008 06:45 AM

    Hi Miguel,

    That's what I've found with Dojo in my limited experience of it. In fact that's why my experience is limited -- because I just can't get anywhere with it.

    My preference still is prototype, which has a lead in the survey right now. It's just works and has great documentation, plenty of demos and other stuff built on it.

    • avatar
    • Alastair Grant
    • Tue 4 Mar 2008 07:07 AM

    I've been using Prototype and Scriptaculous, then recently been looking at JQuery.. primarily for the Domready functions.. ExtJS for full web applications (as opposed to webpages) is nice. MooTools have some nice graphical functions (accordian) but would go prototype/jquery over that for day-to-day functions. DoJo.. too fat, too complex, over engineered?

    So my view is that the race is between prototype and JQuery..

    • avatar
    • Steve Smillie
    • Tue 4 Mar 2008 08:13 AM

    I have been using playing with Ext since the documentation is far better than Dojo. I also find the Domino specific Ext.ND extensions to be interesting, time will tell if they truly become useful.

    I think many Domino Developers will end up using Dojo since it will be "built-in" but I agree that included versions will be an issue.

    For me I will continue with EXT for most things.

    • avatar
    • Jason
    • Tue 4 Mar 2008 08:16 AM

    At the beginning of this thread I would have just said IBM adopts Dojo so probably that's the one to look at. However by the end I'm less sure and perhaps more persuaded by the idea of, for now, having an additional layer of abstraction (Ext).

    At the moment I'm getting up to speed and doing some real world work with Dojo but as soon as I reach a certain comfort level (i.e. the application is really working) I'll be looking around at the other frameworks to see if they'd work better/be lighter.

  4. I still have a problem with the size of most frameworks especially since it is so hard to enable gzip compression on Domino servers (promised for Domino 7, still not in Domino 8). For test purposes I have installed Prototype, JQuery and Dojo on my machines.

    • avatar
    • Brian Miller
    • Tue 4 Mar 2008 08:50 AM

    I'd have preferred to be able to vote for "Not Prototype, ever!", and as a second choice for both jQuery and YUI. But, in the absence of that, I voted jQuery.

    As for IBM "forcing" Dojo, I can tell you that while it will be there, it will be easily ignorable. I'm probably not divulging too much when I say that the only place where it will be "forced" is when the domino server itself is generating the code. It's not going to force developers to use it for anything in their custom JS. So, don't vote for it just because it's inevitable. In fact, I'd recommend not voting for it until it's unbroken and actually documented.

    Personally, Jake, I don't think that you should limit yourself. Use whichever toolkit is the best choice for solving the problem at hand. Failing that, use what you're comfortable with. It's your site. :)

  5. jquery is fantastic, it's tiny, it's so easy to integrate, it's based on css styled calls. the ajax is simple to use.

    • avatar
    • Jake Howlett
    • Tue 4 Mar 2008 09:42 AM

    "Not Prototype, ever!"

    You not going to elaborate on that Brian?

  6. My favorite is Prototype (+ Scriptaculous) because I know it best. But I cannot vote because your vote script only allows one person of my approx. 30k colleagues to vote because you check the IP of our proxy that is visible to the outside world :-(

  7. i think you ought to go with whatever piques your own curiosity.

    "It is written: "The first virtue is curiosity." Curiosity is one reason to seek truth, and it may not be the only one, but it has a special and admirable purity. If your motive is curiosity, you will assign priority to questions according to how the questions, themselves, tickle your personal aesthetic sense. A trickier challenge, with a greater probability of failure, may be worth more effort than a simpler one, just because it is more fun."




  8. This came up in conversation a while back at work. I voted it should be framework independent. I think, as do some other n-tier minded folks, it is a mistake for IBM to continue the broken pattern of having Domino automatically bake anything in at any time. Dojo is a good example of a bad way to do a web server. As good as the toolkit may be, why would you ever assume one size fits all?

    A better practice would be to make your own Interface, Jake. Something that you simply instantiate with the name of the toolkit you want to use which will then translate any call you make through to the proper framework and pass the result back. That way, you always code the same way and can swap out toolkits as you see fit.

    Yes, this means more overhead with the current form of each framework, but with ubiquitous broadband, the size is pretty trivial and there are plenty of compression options. Answering that fault (size) is more one of packaging - something some frameworks handle better than others. My thought there is that you should never have one massive include for the entire framework. Your Interface should only include the items it needs and the frameworks themselves should be broken into class based files like the java SDK.

    Personal preference is Prototype first and MooTools second. Each of these I like for size and documentation / ease of use. Whenever I'm not using them, I almost always write the $ function straight away into my code.

  9. I agree with John Vaughan. Pick the framework that interests you. I wouldn't just choose to base your examples on dojo because most domino developers and IBM are. I think that there is value in showing how other tool kits can be used. It would be somewhat boring if everyone talked about the same toolkit. Personally I don't care which one you use.

    I like the quote from {Link}

    'Prototype is more of a Porsche, whereas Dojo is more like a Hummer'.

    Which, I guess, is why IBM decided on dojo.


    • avatar
    • Scott
    • Tue 4 Mar 2008 06:20 PM

    Someone (probably wiser than me) said whatever you do .. just pick one and stick with it. And I'd tend to agree. Its fine picking up a function here or there but if you really want to get the benefits of the frameworks you need to stick with one and learn it ... and as the article mentioned points out the options are all pretty much the same. So does it really matter..?

    I think Jake, whatever you pick will leave never keep everyone happy.

    • avatar
    • Steve
    • Tue 4 Mar 2008 10:07 PM


    I voted "Should be framework independent", but I would have preferred "jake.js", if that was an option. You have enough knowledge and experience to build your own, so why rely on someone else to add stuff to it? Make your own huge library! =8D

    My 2 cents...

    Steve in NYC

  10. Of course you would always have an older version of Dojo on the Domino server than what is currently available.

    According to Bob Balaban at Lotusphere, you should be able to have multiple versions of Dojo libraries on the Domino server; just stick your own version in its own directory (maybe like Dojo_V101) - which gets me thinking: if you have to deploy the libraries yourself again, you might as well pick whatever you're comfortable with. Looks like versioning is always going to be a headache except if the library is small enough that you don't have to deploy it directly on the Domino server.

  11. Jake, my personal experience vote for JQuery. One js file to add to the Domino db resources (if I recall correctly) to have the basic functionality in place. In terms of Domino development (R6 ...) the biggest issue with ajax frameworks was to import the framework itself; you already demonstrated in older articles how to do that. I found at the time JQuery was the easiest to maintain. Not sure how things have changed past 2 years, but I think they didn't, as 8.5 designer is going to be THE next Domino Designer.

  12. Hey Jake

    Interesting question. Shame really that your vote question was just the one - might've ben better with "what are you using now", and "what do you think should be used!"

    I use prototype all the time. Some apps I use scripaculous on top (with protoculous.jz.gz)

    I've used prototype.js for years but I have spent many months recently looking for something better - it was funny, exactly what you use in prototype is the same for myself! And I have to suffer over 100KB uncompressed for a few array, ajax, and some other cross-browser functions? That seems mad!

    I want tab panels easily. Popup calendars. Scrolling areas. Draggable portal stuff. Form validation.

    All of this has to be found out on the web to run on top of prototype. I've found plenty and love most of them, but they all need maintaining separately, and I'm constantly re-engineering them in the next project to make them better and beter.

    I want it all now in an easy framework, but I don't want to choose something that locks me in so tight I can't breathe.

    And then how do I go about changing all my apps over from prototype.js to something else?

    And then my "feeling" is that semantics and structure is best in prototype.js ...

    I'm going through the same trials and tribulations at the moment.

    I'm leaning towards jquery, followed by Ext as an alternative, but not got time to look at either for a number of months.

    Hmmm, that helps doesn't it!!

    I think you ought to put out a questionnaire to the masses and try and collate all the data you get back :-) You have a big enough audience to generate some valued results.

    • avatar
    • Jake Howlett
    • Wed 5 Mar 2008 05:43 AM

    Ironic how Mootools has 2% of the vote and that's what the survey database is based on ;o)

    I'm not sure picking the one I prefer is the best idea. Let's say I prefer Mootools and only 2% of you want that. That means only 2% of you can use the demos I produce without having the hassle of porting them!

    Much better to use what the masses prefer. Even if I don't like it. That said Dojo is taking the lead and I don't particularly like it.

    It makes me wonder why the interest in Dojo all of a sudden? Are people voting for it merely because they feel it is an inevitable part of their future with Domino? I don't think that's a good enough reason to.

  13. Frankly, I voted for Dojo just because it is in every IBM product that uses Ajax (Portal, Quickr, Connections, Domino 8.5, ...). But I voted before reading the comments here, and I've never used Dojo myself.

    The comments here don't really make me want to use Dojo.....

    • avatar
    • Richard Shergold
    • Wed 5 Mar 2008 09:53 AM

    Gerald, I feel the same! :-)

  14. One should keep in mind that there are fundamental differences between these frameworks. Specifically, that some are low level frameworks that do not give you the extra UI elements to work with.

    Dojo seems to get more clumsy with each release, and the documentation never seems to keep up. I actually worry that allowing a big organization to have a hand in the mix, will only make it worse.

    Ext has my vote. YUI had my vote last year.

  15. Jake: DOJO to provide your core demo material. You can always step off to something else, where there are unique benefits. It doesn't really matter to me if I were to take a snapshot of technical maturity, because DOJO is getting the larger share of support. So, in the long run, it's inevitable for DOJO (after all, I think IBM waited until as long as possible to announce their favored choice).

    If you are writing for the ubergeeks, then by all means try out all the choices. If you are hoping to be a candle in the dark for those groping for some AJAX coherence with Domino, then I'm putting my hand in the air for DOJO. Not the best, but the most supported.

    • avatar
    • Alastair Grant
    • Thu 6 Mar 2008 05:53 AM

    sounds like the computer wars of the 1980's...

    Dojo is the BBC Micro, Prototype the Spectrum 48k/128k, Ext the Commodore 64, mooTools is the Lynx and JQuery the Atari...

  16. On my current project, it's mainly based around jQuery as the selector engine.

    I started off with YUI, but those elements have been replaced over time by different libraries.

    I've also got some Mootools in there, and Ext for the UI stuff. There's also elements from jQuery's Interface and UI libraries (so fragmented, but that's often the case in open source projects). I was pleasantly surprised how well the libraries mix together.

    For me, jQuery really stands out. Things that were tedious to code in Javascript become ridiculously simple. I think it's no exaggeration to say that you can sometimes replace a pageful of Javascript code with a single line of jQuery, because that's happened in my app several times.

    The Plugin culture makes it indispensable to me, in the same way as Firefox. If you need to get around a problem quickly, someone always seems to have written a plugin to do it. Accelerates the development process no end. I'd really recommend going to the jQuery home page, and looking at the Plugins section to see how many are just so damn useful!

  17. Looks like I'm a little late to the party, but Ext all the way. Never reinvent the wheel, I say. (Unless the wheel is square and doesn't roll, but that's a different story entirely.)

  18. Well, I'm biased I guess since it probably isn't any secret that I've been spending all of my time with Ext and Ext.nd since last year. Not sure if everyone knows it or not but Ext.nd started off as the result of 3 separate Domino+Ext projects merging together: Domino YUI from Rich Waters, Domino Web Tools from me, and DExt from Jake. It would be great if we could get you back helping out on Ext.nd and then using your blog to write demos on using Ext and Ext.nd. We get a lot of requests asking to see more demos on how to use Ext.nd and Ext with Domino. Our best bet however, maybe to have a dedicated website/blog about Ext.nd like Lance has with dojomino.com.

    For your blog, Jake, I would think having demos that touched on all of the frameworks is fine. Since you are an independent consultant, it is probably best for you to stay up to date with all of them anyway so that in cases where you have clients that have a js framework preference, you'll already have experience with it. And for those that don't have a preference, you'll be able to recommend the right one for the job at hand.

    Bottom line however is this: No matter what you decide, you know we'll all still read your blog...because when Jake speaks...the lotus blogosphere listens. :)

    • avatar
    • Simmi
    • Fri 12 Jun 2009 02:25 PM

    Hi Jack,

    Would you mind sharing Survey dtabase code?



    • avatar
    • Jake Howlett
    • Sun 14 Jun 2009 04:04 PM

    It's in the DEXT db which you can get from the Sandbox tab above.

    • avatar
    • Jason
    • Wed 17 Jun 2009 12:03 AM

    Get rid of the bloat. Use JQuery

Your Comments


About This Page

Written by Jake Howlett on Tue 4 Mar 2008

Share This Page

# ( ) '


The most recent comments added:

Skip to the comments or add your own.

You can subscribe to an individual RSS feed of comments on this entry.

Let's Get Social

About This Website

CodeStore is all about web development. Concentrating on Lotus Domino, ASP.NET, Flex, SharePoint and all things internet.

Your host is Jake Howlett who runs his own web development company called Rockall Design and is always on the lookout for new and interesting work to do.

You can find me on Twitter and on Linked In.

Read more about this site »

More Content