javascript ui-toolkit ideas

Introduction

This post is preparation for some work I'd like to try. It's about one week I tested many javascript ui-libraries available, but none impressed me! The good question is 'why'? Notice that I'm a qooxdoo user, but currently I'm working on project where I can't use it, because qooxdoo is too heavy for classic web-pages (called multi-page applications from here). I have also one personal project where I can't use qooxdoo for performance reasons (slow to load, slow to work with).

Choosing javascript library for web-development is not an easy task. There are some factors you must be aware of to make good decision. Here is a small list of the most important items for me.

• Good and extensible object-oriented API - Working with well-written library is rage.
• Performance - We are in 2010, don't forget to mobile devices with limited power and memory.
• Small - This is related to performance, bigger library, bigger memory footprint and slower load.
• Use modern technology - IE6 is dead, IE9 is coming with canvas and CSS3 support, this is the future!
• Nice UI - This is really not important to me, but users love it and this is only thing which managers understand;)

I can continue listing other items, but these are the most important for me and there is the point. There is no javascript ui toolkit where I can check all items and say "I found it". Simply because each point has its cost and there are libraries developed many years ago which contains support for archaic browsers.

List of Javascript toolkits (aka toolkit survey)

Before I start describing what I'd like to see, try the list of available javascript ui-toolkits. Please don't look only at speed or UI, look at the API! From developer point of view the API is thing you will talk with.

dhtmlx:

• API-Design: Not so good, many standalone components.
• API-Size: Large, 800KB (compiled by YUI-Compressor).
• GUI-Builder: None.
• IDE-Support: ?
• Performance: Medium.
• Look'n'feel: CSS based theming, good default theme.
• Demos: Good, Demo.
• Documentation: Good - API.
• License: GPL, commercial.
• Target: Single-page and multi-page applications.
• Tooling: None.

Licensing problem: GPL or commercial.

ExtJS:

• API-Design: Good, JSON-like programming style.
• API-Size: Medium, 600KB (compiled).
• GUI-Builder: Designer (commercial).
• IDE-Support: Aptana, ?
• Performance: Fast.
• Look'n'feel: CSS based theming, excellent default theme.
• Demos: Examples.
• Documentation: Good, API.
• License: GPL (was LGPL in history!), commercial.
• Target: Single-page and multi-page applications.
• Tooling: None.

Licensing problem: GPL or commercial.

jsLinb:

• API-Design: Good.
• API-Size: Medium, 500KB (compiled by YUI-Compressor).
• GUI-Builder: Yes, VisualJS.
• IDE-Support: ?
• Performance: Fast.
• Look'n'feel: CSS based theming, good default theme.
• Demos: Good, Code-Snippets.
• Documentation: Good - API.
• License: Open-Source LGPL, commercial-support.
• Target: Single-page applications.
• Tooling: jsLinb internally uses YUI-Compressor to compress their files.

Qooxdoo:

• API-Design: Excellent, but classic programming style (new button, set property, ...)
• API-Size: Heavy, more than 1MB (QxBuild is 1.3MB).
• GUI-Builder: None.
• IDE-Support: Eclipse/Aptana SPKET.
• Performance: Slow (the slowest toolkit).
• Look'n'feel: JS based theming.
• Demos: Excellent, Demo-Browser, Playground.
• Documentation: Excellent - API.
• License: Open-Source LGPL/EPL.
• Target: Single-page applications.
• Tooling: Complicated build tool called 'generator', incompatible with everything else.

Qooxdoo is statically designed. There is no concept like packages or group of classes, instead there is tool called 'generator' which is able to create optimal one big ".js" file that you have to add to your web-application (web-page). I'm using Qooxdoo all-in-one aka QxBuild package which helped me to build our plugin-based application.

Note 1: Qooxdoo contains packages, but this is not I'm talking about. There are javascript libraries where you have for example JsLib-Core, JsLib-UI-Core, JsLib-UI-Grid packages. These packages contain functionality and dependencies to other packages. The design is usually very simple so the developer doesn't need complicated build tools like Qooxdoo-Generator.

Note 2: I'm a big Qooxdoo fan, but this not means that I'm unable to see its weakness. Qooxdoo is the library I'm the most experienced with.

Smartclient:

• API-Design: Good.
• API-Size: ?
• GUI-Builder: None.
• IDE-Support: ?
• Performance: Medium (not fast as others, but reasonable).
• Look'n'feel: Looks good, but I don't know if theming is JS or CSS based.
• Demos: Excellent, Demo-Browser.
• Documentation: Excellent - API.
• License: Open-Source LGPL, commercial.
• Target: Single-page applications.
• Tooling: ?

Never tried, I don't want to register. But I must say that their demo-browser is faster than two-years ago, this can be browser related or they worked on optimizations;-) Also their examples are quite good, data-binding related.

UKI:

• API-Design: Not satisfied, jQuery programming-style.
• API-Size: Lightweight, about 120KB (compiled using tool written in Ruby).
• GUI-Builder: None.
• IDE-Support: ?.
• Performance: Fast.
• Look'n'feel: JS based theming, too big focus indicators.
• Demos: Code samples.
• Documentation: Very brief - API.
• License: Open-Source MIT.
• Target: Single-page and multi-page applications.
• Tooling: None.

You can't assign a context to callback functions.

YahooUI:

• API-Design: Not satisfied.
• API-Size: Depends to features.
• GUI-Builder: None.
• IDE-Support: ?.
• Performance: Fast.
• Look'n'feel: CSS based theming.
• Demos: YUI2, YUI3.
• Documentation: Good, YUI2, YUI3.
• License: Open-Source BSD.
• Target: Multi-page applications.
• Tooling: None.

This is first library (YUI2) I tried in the past, but I didn't choose it. The library contains many useful widgets for multi-page (classic web-based) applications, but I hasn't been satisfied with the YUI object-model. YUI3 is definitely not for me, because it's mainly specialized for multi-page applications.

Others:

Other UI libraries:

• LivePipe - Prototype based.
• jQueryUI - jQuery based.
• MochaUI - Mootools based.

I don't like jQuery style programming and I don't like libraries which modifies native javascript objects (I'm talking about prototype and mootools). All toolkits based on such libraries are non-interesting to me, without exception;-).

Javascript UI libraries conclusion

If you read the UI survey carefully then you should noticed some things. Each good library is here some time (5 to 10 years). In web development one decade is a lot of time to add new features (HTML5, CSS3), to improve javascript performance, dom access performance, etc... Many listed libraries suffer from the old, archaic design. They were designed for old browsers which contained slow javascript engine, memory leaks (IE), etc... Also the backwards compatibility is needed, because javascript is dynamic language and nobody wants to have some bug in deployed application.

In addition, each good library is quite big. The smallest is probably ExtJS, but it contains huge CSS file, so many libraries are coming near to 1MB (compressed .js code). The biggest is qooxdoo compiled by QxBuild (about 1.3MB). I tried to minimize size of qooxdoo by excluding some classes I don't need, but I can't make smaller library than 1.2MB.

And the last thing I'd like to highlight is that many javascript frameworks are not using new HTML5/CSS3 features for backward compatibility. I'm asking yourself, it is really needed to support the biggest crap in the history of web development (I'm talking about IE6)? Each framework contains zillion of stupid image transitions, shadows, filled rounded rectangles, etc... Many people are compressing their javascript files, but they include tens of image transitions in the resulting web-page.

HTML5, Canvas and CSS3 is the future

It's 2010 - All modern browsers contain support for CSS3 and Canvas, IE9 with announced CSS3/canvas support is coming. So why not to use these features for new toolkit? It's not easy to write ui-toolkit in javascript, but it's easier than before - better debugging tools, faster execution and improved features.

Links to some interesting CSS3 features:

• CSS3 Features Preview.
• CSS3 Gradient Buttons.
• CSS3 Gradient Generator.
• CSS3 Text Shadows.
• Or just use Google.

New UI Toolkit proposal

From now I'd like to talk about the design goals of new javascript based UI toolkit. I think that theming should be based strictly on CSS3 features, virtual component eco-system (model & view architecture) should be default and API should be lightweight, but strong. Maybe I'm totally wrong, but why not to try it;)

Library design goals:

• [ ] - Object-oriented model based on similar mechanism like Qooxdoo. I wrote one library called BLite before. It's very lightweight library that implements object-oriented design similar to qooxdoo and few utility classes for DOM manipulation. Currently the library was refactorized and SVN is not updated (I renamed BLite simply to Lib). Some another work is needed to make it finished. Link to BLite. This library is candidate for core object-oriented model implementation.
• [ ] - API should be JSON-based. I found very comfortable using declarative approach instead of classic 'new', 'add' and 'set-property' based one when designing UI. But I'm not saying that classic syntax shouldn't be possible (declarative syntax will be build on top of the classic one).
• [ ] - API for data-models and data-binding (lists and trees are important data structures that should be supported).
• [ ] - UI toolkit totally under control of layout manager. Minimum work with DOM from developer perspective.
  • [ ] - Each container is exactly one or two DOM elements, never more. One element will be used for outset and second may be used to store child widgets (child DOM elements). Second element can be shared with first element if it's not needed. The reason to include second DOM element is that some widgets contain child area. but also other controls (table header and footer, etc...).
  • [ ] - Virtual form-based controls (text-field, button, check-box), normally rendered as DOM elements, but with possibility to use these controls in virtual widgets. I'd like just to separate the UI state with DOM state so the engine can take DOM element and reuse it for something else when needed.
  • [ ] - Virtual list and tree widgets. I think that it's really confusing to have list, virtual-list + tree and virtual-tree (Qooxdoo). The virtual widget ecosystem should be core for all data-view components. Only problem here is that I don't know how to write such thing;-)
  • [ ] - Declarative theming based on CSS3.

Library design notes:

• [ ] - Minimizing count of DOM elements will make library faster. Virtual architecture is slower than pure DOM based architecture, but on the other side it's very flexible. Imagine ten thousands of text-fields in grid control that behaves like the standard text-field!
• [ ] - Using CSS3 is faster than replacing it by nested DOM elements and stupid transition images. IE9 is going to support them.
• [ ] - Performance of virtual widgets can be increased when using canvas. We don't need DOM nodes to make square red or black (search for red black trees if you are interested why I choose these two colors:-).

Conclusion

This post is preliminary. I wrote it to summarize design goals and possible implementation. I'm quite good at javascript programming and I think that I'm able to write such toolkit, but only question is how much time such thing can eat. I must eat too and writing open-source code is not I'm paid for (and to be honest I'm working on open-source C++ project with higher priority).

If you like the ideas, if you found mistakes in toolkit comparisons just leave a comment. I'd like to improve this post.

QxET - Second try

Intro

It's few days I published small article about the QxET theme for qooxdoo. I wrote that theme is currently not balanced and that some time is needed to make it better. Today I played with the theme a lot and I'm finishing! I'm bringing here new screenshot and working application where you can play with qooxdoo themes and QxET.

QxET - Second try screenshot

Links to testing applications

• Qooxdoo-Modern
• Qooxdoo-Classic
• QxET-Light

Update: All qooxdoo bugs related to the QxEt theme were fixed. The first version with QxEt may be used is qooxdoo 1.2 or current trunk.

QxET - Qooxdoo extended themes package

Intro

Qooxdoo toolkit contains only two default themes and there are no other themes available on the internet. Some time ago I released theme that I'm using in our applications - QxET. The purpose of this is to create themes compatible to qooxdoo that will use different concepts.

My motivation to create this package was that I don't like Modern theme and Classic theme looks really crazy to me (I have biggest problem with blinking border backgrounds and button focus). Also I noticed that these qooxdoo themes are really slow so I experimented by creating theme based on the Classic one, but without using shadows and fixing the things I don't like.

Screenshots

To measure themes I wrote simple theme test application that will create one page full of various widgets.

Qooxdoo-Modern theme:

Qooxdoo-Classic theme:

QxET-Light theme:

Speed

I grabbed also speed information reported by qooxdoo using firebug (firefox debugging tool). I think that these values are not accurate, but they shows that each theme has different rendering complexity. The modern theme is slowest while the qxet theme is fastest.

Qooxdoo-Modern theme:

000184 qx.core.Init: Load runtime: 183ms
001584 qx.core.Init: Main runtime: 1398ms
002788 qx.core.Init: Finalize runtime: 1202ms

Qooxdoo-Classic theme:

000101 qx.core.Init: Load runtime: 101ms
001101 qx.core.Init: Main runtime: 998ms
002101 qx.core.Init: Finalize runtime: 998ms

QxET-Light theme:

000094 qx.core.Init: Load runtime: 94ms
000699 qx.core.Init: Main runtime: 603ms
001697 qx.core.Init: Finalize runtime: 996ms

Conclusion

As you see the QxET theme is not complete, but I think that I can compete with default qooxdoo themes in the future. I think that QxET theme is not balanced - there are sometimes different colors in selections (orange vs blue), it's too gray and there are only few color transitions. But on the other hand I want to keep theme lightweight and simple (I don't want rounded corners, slow grid decorators and other things used in qooxdoo Modern theme).

Note that the TabView widget is broken using QxET theme, the problem is probably in qooxdoo v1.0.