[Buildbot-devel] Should we pursue with dojo for buildbot nine UI?

[Pierre Tardy]

For those of view who still are not in buildbot's G+ community, I'd like to
share here
some of my thoughts on the last buildbot nine UI work I did:

https://plus.google.com/u/0/108698963287416136744/posts/inPxPtve348

I have been putting a lot of work those last few month on buildbot nine
on particular in the new web UI. As we are refactoring the status system,
the old web UI needed to be rewritten. This was a good time to redesign it
completely.

A lot of the performance bottleneck in buildbot 0.8 is due to the web UI
doing a lot of UI generation computation synchronously on the main server
thread. This looked like a good idea to switch to a json only REST api from
the server point of view, and have the whole UI generation delegated to the
web browser.

Generating a whole UI in the browser is still not something very common
nowadays. Most of the people doing JS are generating most of the core UI in
the server, and then using JS in order to add shiny animation, and some
"ajax" features. In this area, JQuery is the big winner, allowing to design
nice features with very few lines of JS.

However the core design of JQuery looked very bad to me in term of SW
engineering. Mostly the fact the whole api is accessed via $(<something>),
where the type of <something> will change the return value and side
effects, whether its a DOM query, plugin query, or object decoration. This
seriously bothered us, as we strongly believe, that explicit is better than
implicit (http://www.python.org/dev/peps/pep-0020/).

As a second big JS framework comes dojo.

>From a SW engineering point of view, dojo is very much designed to handle
very big modular JS project. Especially the new AMD design looks like a
very sane way of doing browser JS modules.

With this modular design in mind, dojo implements a lot of modules, as a
big JS toolbox, and is very powerful in abstracting legacy browser quirks
in a clean API.

Dojo is also designed around the ideas of async programming coming from
twisted, which are familiar to buildbot/twisted developers.

Last thing, dojo has the promise of modular UI design with its widget
system called dijit.

With all those good promises in mind, I started designing the new web UI,
and came to a point having something nice to demonstrate:
https://nine.buildbot.net/#/

By doing this, I got an idea of the not so good points of dojo.

- dojo comes with a lot of legacy, his support for old browsers like IE6
often makes it hard to understand. It looks like with the html5 move, the
new trend is to just stop support them as an activism to make a better web
(
http://fronteers.nl/congres/2012/sessions/the-web-platform-and-the-process-of-progress-alex-russell
)

- There is no real integration of template systems, the dojo parser being
solely based on custom DOM attributes.

- dijit has been very disappointed for our use cases. The widget creation
is synchronous, which prevents widgets to fetch json input data before
parsing their template. It is not helping very much in the problem of
updating the UI
when the server pushes events on the watched builders. As a result, I did
not use the lot of widgets that dijit is proposing, and I needed to make my
own custom haml widgets. There is a MVC framework that sits inside dojox
(dojox/mvc) and has the experimental status which looks to me like a
"don't-use-me" sticker, and is the reason why I did not look into it.

- The dijit widgets also are looking very ugly, given the new standards
css3, bootstrap, gmail, github, etc. are bringing-in.

- The build system is very powerful, but turns out quite complex, and comes
with big dependencies node, and java, which has generated
a lot of FUD.

- The only component I'm very happy of is the dgrid. It provides a very
elegant and powerful way of displaying tabular data, which is the most
frequent data type that we need to display.

So when last morning I read on #buildbot:

Jan 16 02:14:46 <tomprince>     Well, I want to port it to angularjs,
instead of dojo.
[..]
Jan 16 02:19:15 <tomprince>     Well, I'm not convinced dojo (hence porting
to angularjs)

After my first guts reaction to fight against it, to save the work invested
in it, I realized that a lot of time spent in my dojo UI was fighting
against the above flaws.

Rewriting my work in angularJS might not be so painful, as a lot of work
has been done also in the design on how the JS and python are working
together, and also on the pure web design (i.e html/CSS), which can be
easily translated. Still the soonest we take a decision, the less work is
wasted.

While I cannot really talk about angularJS without really dive into it, It
looks like it's really good at where I've been feeling dojo is bad. Now we
have to figure out whether angularJS is also good at where dojo is good:
- module system (AMD)
- tabular display (dgrid)

Probably one of the biggest challenge will be to find good toolbox to help
around angularjs, which really is only a MVC framework. Avoiding jquery is
something I still have in my guts, but it looks like this will be giving up
on a lot of interesting angularJS ecosystem. So I might have to work
through it.

Then how we manage all these dependencies is also a potential issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20130118/c67c5257/attachment.html>