From Java Swing to JavaFX - ...to RISC-HTML

CaptainCasa Enterprise Client is a rich client framework for enterprise applications.

Founded in 2007 we were quite exotic ones, having chosen Java Swing as UI technology those days. The main reason for NOT having chosen HTML was: our framework users develop operationally used business applications with long lasting life cycles - and they do not want to afford a rewrite of their UI every 5 years - as it was (and still is) common in HTML environment.

Somewhere around 2011 when JavaFX 2.0 came up, we added a JavaFX implementation of our client. Luckily our rich client framework is following the architecture of "server side interaction processing", so our UI-client is a generic rendering engine, rendering XML forms coming from the server side. Still we explained people, that JavaFX is an adequate technology for the type of  "heavy" business applications they develop - and still the core argument was: independence from "browser volatility" and from browser compatibility issues.

And then, all of the sudden, we were hit by some new idea, how to deal with HTML and browsers so that we can overcome the typical problems that are associated with browser based frontends. We called the idea "RISC-HTML" - and managed to rewrite our complete Java Swing / JavaFX client so that is is running now in a 100% HTML way.

The idea behind RISC-HTML is: we asked ourselves "Which are the basic elements, that a UI technology must provide in order to build some UI framework on top?". The result is: if a UI technology supports "rectangular areas" and "input fields", and if it supports just the ability to absolutely position these elements - then this is sufficient to build up all the business controls that we internally use.

So we did not think the traditional way: "How can we set a framework layer on top of HTML, in order to simplify HTML and to equalize browser incompatibilites?" - because with this approach you are always bound to the known HTML limits. - We went the other way: "How do we build a UI framework on top of primitive elements?" and then checked how to transfer this thinking to HTML.

The result is something which - from the beginning of development work on - pushed and pushes our adrenaline level! It's the first time that we are working within the Browser/Javascript environment, without suffering from it! Just the opposite: we see, that our expectations are fulfilled:

1. no issues with browser compatibility anymore - because of using only two types of elements and because of having encapsulated them inside some "Microkernel" JavaScript library.
2. no problems with any layouting strategy anymore - layouting is done via JavaScript controls on top of the "Microkernel". The browser's role is to "execute the rendering", i.e. to draw rectangles at the right position. The decision, where and why to draw the rectangles is in the hands of the corresponding (JavaScript) control
3. and the most exciting experience for us: RISC-HTML is ...fast!!! Well, this mirrors the increase of speed of browser processing in general - and the increase of JIT-compilation-quality within the JavaScript interpreters.

These ones of you who remember the CISC/RISC processor discussion of  the 90s will clearly see the analogies: the idea of RISC processors is to let the processor only do the core tasks and to arrange the logic "in front of the processor". - It's the same what we do with browsers: we reduce the browser's role to basic rendering processing - and push the logic out of the browser into some program/JavaScript control layer.

Result: RISC-HTML is clearly the future of our rich client framework! It's the combination out of "zero installation" for the end user and at the same time "zero maintenance" on the developers' side. Well, the word "zero" is maybe a bit too aggressive... - but it's fair to say that maintenance effort is drastically decreased.

Check out the information at http://www.CaptainCasa.org and test drive the RISC-HTML based demo environment: http://captaincasa.org/online-demo-server