This blog is highly personal, makes no attempt at being politically correct, will occasionaly offend your sensibility, and certainly does not represent the opinions of the people I work with or for.
JavaScript Widget Libraries

When, in 2006, I started using JavaScript for a work project I was working on, one of the things that shocked me profoundly was the lack of ready to use UI Widgets. At the time jQuery was not even born yet (I started my project few weeks before the initial release date of jQuery), and in the following two years people were just very happy with being able to do ajax without pain. It was also the moment when the Great Browsers War started to wear down a little bit, adding to the general happiness of web developers.

Within few days of learning the basics of JavaScript I started working on a library called Pleiades. It had its own run time environment, had a sophisticated class system, a broadcasting framework, ways for objects to communicate through public or private channels. My favourite part of it was special objects orchestrating the work of collection of other objects. It was, in fact, an implementation of the actor model (well before I knew what the actor model was...).

Around that time Cappuccino was born. Cappuccino was Objective-C (rebranded Objective-J), with a Obj-J to JavaScript compiler (written in JavaScript) together with a Obj-J/JavaScript implementation of most of Apple's Cocoa framework and even a reimplementation of Xcode's Interface Builder (called Atlas). Cappuccino was admittedly way ahead of its time, way, way ahead, and never really caught up.

An incorrect diagnostic of why Cappuccino didn't catch up, or why there wasn't more Pleiades around, would have been that the web devs of the time didn't want to learn something new. In fact, as I discovered later when I spent more time working with web based companies, an amazingly common workflow for making web apps is to have a graphic designer working on the wireframe / original HTML files and then, only then, deliver that to the web developers. This has at least two important side effects: (1) When the developers are junior, or come from India, they take the HTML markup and then code PHP around it. This means that more and more code and logic is added to the HTML markup (which PHP makes particularly easy to do), mutilating the original markup with *endless* control structures), until they then end up with an insane toxic goo that nobody can work with. (At which point I was often called in to try and do something about it -- but I have now retired from that business); (2) The developers' thinking and the tools they gave to themselves were often designed to work with existing markup (making it then more difficult to rebel against markup). Thinking of it, there was also another reason: a push to actually work with existing HTML markup that some people gave the fancy name "Progressive Enhancement" to. A lame attempt to make search engines, as well as the suckers turning their JavaScript down, both happy.

En passant, note that I witnessed the birth of ExtJS, before it became coorporate and unfortunately YUI is dead.

The point here is that a relatively harmless practice: having designers make the HTML markup before giving it to programmers, has had the sad effect that the notion of ready to use JavaScript UI widget is _still_ largely under developed. This is relatively surprising because in the Desktop app world, nobody would accept one minute to work at the primitive level of abstraction (or lack thereof) that what web application developers are at everyday.

What has happened over the past few years was that developers decided that they partially didn't need graphic designers and use pre-written collections of HTML code (and the css that come with them). This creates stuff like Bootstrap, or its sexier sister: Google's Material Design, which was code named "Quantum Paper" to try and hide the fact that it's still the same Gutenberg paper based thinking of the past centuries applied to graphical app development.


This morning, I decided to write my own experimental UI library. So now, you are going to say "Aren't there already easy to use ones on the internet ?" Well, not like the one I want. I need something that allows me to think abstractly about the elements without ever seeing any markup. Let me give an example. We start with the most boring HTML document ever.

Which renders like this

What I want is simple. I want that when I click on the text (note that there is no visual indication that the text is clickable) it is replaced by an text input with a commit button and then when I commit, what I have written is alerted. Let's do that in two steps. First I am going to alert when I click on the text. Easily done with

Easy, simple, no fuss. (nb: I like delegate, you can use them before $(document).ready() and also on elements which haven't yet been rendered.) And now the second part....

With this, when I click on "Pascal" the page becomes

And then you enter something, click on [Done] and it is alerted.

The crucial point here is this: when I called JavascriptUIElementsX35877E45.suite1.textInputWithSubmitButton, I passed the DOM target identifier _and_ the function that would handle the inputted text (value of the input at the moment the button is pressed). Nothing else. This is a basic behaviour corresponding to the name of the function. Note that the handling function can be used to do whatever you want (for instance, replace the original string by what you just imputed or being ajax'ed somewhere) and can itself trigger other UI elements, at the same place or somewhere else; the sky is the limit... Also, by setting other keys of the passed object you can add CSS instructions, the actual label of the button, placeholders, or anything you need to customise.

Another non trivial characteristic of this kind of library is that you can add it to any existing project (or simple web pages) and start to use it right away. I started to write it today, so it's like 0.001% done, but if you want to see it growing up, it can be found here.

As I said, it's experimental, but I have some UI work to do today, want to focus on workflows and not representations and there is no way I am going to annoy myself and waste my time with markup, This library will grow as new features are needed (but I will never break it, and it will always be backwards compatible).

Last but not least: if anybody actually got my point and can recommend a JS Widget Library which doesn't need existing markup because the widgets generate it as part of being instantiated, and also where behaviour can be passed as parameter, please let me know...

ps: What really prompted this whole business this morning is that I will be using a lot of this... (it does _exactly_ what you think it does.)

[ add a comment ]


M @ 2016-04-09 08:57:03
I was discussing this with some friends not long ago. One of them was wishing for the same kind of framework and postponing to write it for lack of time. Also he was hoping for it to be like QML. At that time we discovered this interesting project:

However I don't think it is ready for production or stable enough at the moment.