Wednesday, November 12th, 2008

JxLib: New Browser UI Toolkit

Category: MooTools, Toolkit

To the ranks of Ext JS, jQuery UI, Dijit, and others comes JxLib, a new browser-based UI toolkit built on top of MooTools. Jason Fournier from the team passed the announcement to us:

JxLib includes layout managers, buttons, tabs, toolbars, dialogs, panels, trees and a basic
grid control all designed to work together. It is heavily based on
using CSS for presentation and includes two separate ‘themes’ that you
can easily switch between. New themes can be constructed by modifying
the existing themes…

JxLib has evolved out of a generic web-based UI toolkit…
for building web-mapping applications. It has been distributed under an MIT license for a couple of years, but this is the first time we have actively attempted to build an open
source community around it. We are excited to share this project with
others, and invite users and developers to join the project.

The Examples page, available off the main project’s page, showcases many of the built-in components and features. The source is hosted on Google Code and there’s a JxLib Google Group as well. After playing with the examples, JxLib seems quite polished and a welcome addition to the crowd. A year ago some folks may have counted MooTools out of the game, but with at least one major release this year, a revamped website, steps towards a plug-in community, and a now a quality UI toolkit, MooTools is in the game.

Posted by Ben Galbraith at 7:00 am

4.1 rating from 61 votes


Comments feed TrackBack URI

Very polished and aesthetically pleasing for a first release UI Toolkit, I must say. It’s almost on par with ExtJS from the initial looks of it.

Comment by Jordan1 — November 12, 2008

Unfortunately it appears to suffer in IE as all MooTools (and prototype) stuff does. The way MooTools extends elements in IE (mass copying of functions to the element) instead of wrapping the element (as JQuery and ExtJS do) is really naive and will always make it painfully slow in IE. I wouldn’t use it on anything larger than a simple website.

Comment by FredroLewis3rd — November 12, 2008

is it me or is this already better than jquery ui?

Comment by ilazarte — November 12, 2008

ah, just saw that note fred. good to know.

Comment by ilazarte — November 12, 2008

Looks very professional. All the UI components look really polished.

Now the downside. The number of DOM elements used for some of the components such as Dialogs seems very high. I think, all the toolkit developers should focus on DOM usage, since any reasonably complex UI is going to have a lot of components and sooner or later, the page will be unusable. We use Dijit in our framework and recently we started rewriting some of the Dijit components keeping DOM usage in mind. There are some interesting concepts like “sliding door technique” (, “stretching background image technique” ( etc., that can be effectively used to minimize the number of DOM elements used. For example, we use the sliding door technique for buttons, tabs, etc. with very minimal DOM and image usage. The 2nd technique is used for dialogs and floating panes, where a single image is used for the rounded corners, title bar and drop shadows.

Fred’s observation on copying functions to the elements is also a source for concern. If you navigate the DOM tree, you will see tons of functions at every DOM element, which is kind of scary.

While it is nice to see more UI libraries, there is still room for at least one more, which is built with performance in mind.

Comment by ragjunk — November 12, 2008

Hey ragjunk can you show us a dialog in digit

Comment by matthew49 — November 12, 2008

@Jordan1: I thought so as well at first glance, however I cannot say I’m convinced. It works much slower (I.e. click on a button, wait, see result) than ExtJS. Also the number of widgets is way less. Finally, I was very disapointed to not see gridsorting whatsoever. To me it seems there still needs to be done a lot of work.

Comment by PieturP — November 12, 2008

The default Dijit controls can be explored at:

The Dialog, in particular is available at:

PS: I don’t work for Dojo.

Comment by ragjunk — November 12, 2008

Seems to be a feature full lightweight UI Toolkit too me. :) Very impressive.

Comment by matthew49 — November 12, 2008

@ragjunk: I agree there should be a concern on the number of DOM elements for these different components. But people like “polished and sexy looking” components and that = more dom elements. Thats why extjs this one YUI all have a lot of dom elements.

Comment by matthew49 — November 12, 2008

The graphics are better than I thought they would be. Kudus! I like how the combo element’s hover and the button’s pressed states, for example…

Comment by sroussey — November 12, 2008

Thanks for the comments so far. I would like to respond to a couple of the concerns raised above. First FredroLewis3rd raises a good point about the technical difference libraries that modify the native prototypes (mootools, prototype) and those that don’t (jquery et al) – I would note that there are pros and cons to both approaches and we happened to choose mootools, but fortunately if you are not a fan of this approach there are lots of alternates :) Second, ragjunk raises some good issues too. We have made a deliberate effort to keep DOM usage small but have had to compromise in several areas to achieve a level of functionality and cross-browser compatibility that we wanted. We do make extensive use of CSS techniques including sliding doors (in all buttons and button-based objects), a modified sliding doors for dialog and other chrome, and CSS sprites for icons. We also attempt to use the browser’s ability to do as much as possible, like using a tags and css :hover to get the mouse over effects on buttons. I would welcome the opportunity to discuss these and other issues in more depth on our mailing list :)

Comment by pagameba — November 12, 2008

For the LOVE OF GOD, another toolkit that doesn’t even do BUTTONS correctly.

Sorry to vent, but the feel of most javascript UI components are simply awful. Have the framework developers ever bothered to play around with real components (any modern os since 95, really)?

Buttons shouldn’t stay selected if you hold down the mouse button, mouse off of them, and release the button. And they certainly shouldn’t drag the contents off if you move the mouse while clicking on them.

Come on, people. That’s the easiest component out there. If you can’t get that right, do you expect me to use anything else your library offers?

Comment by dubious — November 12, 2008

>>Buttons shouldn’t stay selected if you hold down the mouse button, mouse off of them, and release the button.
Yeah, I noticed that one, too.
This library needs a couple of weeks with some really good, mean testers abusing it.

Comment by Nosredna — November 12, 2008

dubious: thanks for the (passionate) feedback, I’ve filed this as an issue and we’ll see what can be done about it
Nosredna: that’s what we are hoping will happen … developers are way too easy on their own stuff …

Comment by pagameba — November 13, 2008

Sorry to vent. It’s frustrating, though – well written JS UI libraries are clearly a win in my book – especially since you don’t have to deal with the underlying cross-browser madness, and the provide a higher level of abstraction than pure dom / css manipulation. But very few of them yet are really at point where they’re mature.

I look forward to improvements to JxLib. :)

Comment by dubious — November 13, 2008

@dubious: Please have a look at qooxdoo example here. Do you think this Button is working correctly?

Comment by wpbasti — November 13, 2008

Unfortunately, Qooxdoo’s Button has problems as well. Click on the button, continue to hold the mouse down, and move the cursor off the button. At first, it appears to work (sort of)….the button pops back up after you mouse off of it. But as you move around, you can get the button to pop back up and down again seemingly randomly. Try by moving the cursor straight down slowly, you’ll see the button pop up and back down again.

It doesn’t look like Qooxdoo deals with focus properly, either (which is important for keyboard accessibility).

It’s pretty easy to compare examples to components in your native OS. Windows, OS/X, and even Java applications (although they tend to be a bit worse) have pretty much exactly the same behavior for the common UI components, which is what component authors should emulate.

Comment by dubious — November 14, 2008

Following up for dubious, we are now actively working on making the buttons behave more rationally, including focus tracking and keyboard accessibility (tabbing and ‘enter’ to activate). The next beta will include these improvements.

Comment by pagameba — November 19, 2008

What an excellently programmed library, nomenclature just as I’d use. I agree with some comments about Mootools slowing down with large apps but with a well clean/clear the critical bits can be reprogrammed from the time saved elsewhere.

Comment by olliemaitland — January 6, 2009

I love it. Mootools based, simple, elegant. I’ll be using it the first opportunity I get. Mootools needs more of these types of frameworks. Is it just me or does every piece of code that uses mootools just start out leaps and bounds above the rest? Must be that extend function… :P

Comment by slajax — January 13, 2009

Leave a comment

You must be logged in to post a comment.