I am working on a UI lib which is written in Javascript and completely painted on HTML5 canvas. I know, crazy idea... I got rid of the incompatibilities of the browsers, I got rid of DOM: I defined my own event system, component graph, etc... This will be someting like a traditional desktop component based UI, just in javascript, in the browser. Styling will be far more advanced than CSS: you can even inject a custom paint method into a component from a stylesheet. (stylesheets will be javascript classes). Also it will have advanced dynamic layout. (min/max/preferred sizes, weights, gridpanel with colspan, rowspan, etc...)
I am doing it in my free time (at nights), because I have no funding: it is a quite huge undertaking: I am ready with 5300 lines of code, but I still need a couple of weeks just to release a very early demo. My secret aim is to make it a flash/flex killer in the long term. In the very long term:)
But won't using the canvas for this eliminate the compatability in older browsers? Which not caring for older browsers would help resolve a lot of the pains of working with the front end in browsers...
In my experience it's going to be very hard to make moving elements around performant, unless you're using multiple canvases (which is basically just using the DOM) or you use WebGL. How are you going to solve this problem?
At styling and layout I use dirty flag managment, so that branches of the component tree is restyled or layed out only if needed. This kind of dirty-management makes stuff a bit more complicated than otherwise, but this is a tradeoff. At painting I did not implement caching (painting to a memory buffer) and dirty flag management yet, but here I will also do optimizations in the future. This is a bit tricky, as painted components can have alpha/trasparency.
The most serious bottleneck will be probably painting (everything else can be addressed with algorithmic optimizations).
At the beginning of the project I've looked at canvas painting benchmarks, and I decided canvas performance is already quite good. The slowest is drawing texts, but even that is not that terribly slow. I expect that canvas performance will improve in the browsers in the future so time works for me.
Currently my samples' performance feels acceptable, although I did not do serious performance tests yet (and as I mentioned I did not implement the most agressive optimizations regarding painting yet.)
TL;DR: Making this fast is quite challenging, but not undoable I think.
Why don't you just write a Canvas backend for an existing toolkit like gtk or qt? You'll never be able to implement all the details of a sufficiently wide range of controls on a one-man (or even 10) part time basis.
The biggest fun of the project was that I was completely free to design the system from the ground up (except the canvas drawing functions).
Regarding the amount of work I have to be strategical.
I try to concentrate on a relatively small core system: get the philosophy right, tune the performance as much as possible. The components which are 'ready' right now: Window, Button, ScrollBar, ScrollPanel, GridPanel, TextEditor, StaticDoc. (StaticDoc is a read-only RichText component, kind of the original HTML.)
The other absolute necessary things needed in the near future: TabPanel, DataTable, CheckBox, ComboBox.
To go further I will certainly need outside help (either other programmers or funding or third party component creators). I cannot create a huge component lib myself. But 10 people can do lots of things I think.
I am doing it in my free time (at nights), because I have no funding: it is a quite huge undertaking: I am ready with 5300 lines of code, but I still need a couple of weeks just to release a very early demo. My secret aim is to make it a flash/flex killer in the long term. In the very long term:)