For the Love of Vaadin: RIAs Done Right
Java web frameworks are legion. A sampling includes Spring/Struts/Play/Wicket/Pivot/Tapestry/Stripes/JavaFX/Flex/GWT and there are literally dozens more.
They all seem pretty alien to a guy coming from desktop UI development a la Swing or SWT.
Recent frameworks are heavily influenced by Ruby on Rails, which is fine to some degree. All of them tend to solve the nuts and bolts problems: things like session management, security, etcetera — stuff that has to work every time. That’s what servlets and containers and such are for. Some frameworks have historical warts that will never leave. Most use Java on the server (obviously) and various HTML/XML/client-side definitions to stitch together incredibly scalable deployments. In fact, a lot of the emphasis is on a use case that I suspect is not actually the common one: millions of users, a la Twitter or Facebook.
The NoSQL folks get exercised about how incredibly their stuff scales compared to RDBMS’s; that’s true as far as it goes. Sometimes. But very few people actually build web apps/servers that need to scale to that degree. More likely, you are building an app for internal deployment to a few hundred users, or even smaller. The Client/Server revolution took place in the nineties without the web, inside IT departments. Remember tools like PowerBuilder? Client/Server is not new; Client/Server using a bog-standard web browser as the client is new. A lot more apps get deployed inside companies than outside. But I digress.
In my particular case I had been looking at replacing some portion of our company’s database admin tool with a web-based one instead of the Swing-based one we have now. Just as an technical exercise; our customers seem to like the admin tool as it stands. Then, for some contract work, I had to build a one-off web-based query interface to our database server. Personnel changes meant I had to do it personally; I couldn’t farm it out to our resident web developer/Phillies Phan. Had to be done in two weeks. Joy.
I hate XML in all its many, many, pernicious forms. Least readable human-readable format ever. Hate writing it, parsing it, looking at it. I’m not a big CSS/HTML guy mainly because I don’t use it enough for the knowledge to stick; I am forever having to relearn bits. I’m server-side Java guy who has a decent knowledge of Swing and values UI tools for they can do, not for their eye-candy. So when I started looking around at how to build this thing, I swam into some unfamiliar territory.
First, I went through the traditional flow, playing with Stripes and Tapestry and Spring. But the framework-friction level is high, as a newbie. Lots of jargon to know. Lots of gotchas trying to bridge from a toy ‘Hello World’ to something that actually does something. And … it is just not pretty. So I swam on.
Next up was a quick look at JavaFx. It is … alright I guess. Produces reasonable GUIs. But it isn’t actually a web app, to my way of thinking — you need the JRE installed on the client machine to make it work. And it adds another language which compiles to the JVM. I could learn JavaFX Script, but then I would leave the trail of another language to learn for whoever might have to support this thing later in life. There are costs to polyglot programming when you have a small team. Blech.
Pivot is kind of nifty — it’s now an Apache project, quick to pick up, looks nice. But again you need a JRE, and the UI elements somehow feel not terribly responsive. I have no good reason why it just didn’t move me, but it didn’t.
Wicket seems to have a lot of enthusiasm, and the demos are purty, if not terribly well organized. Interestingly, it is also in the arms of Apache — how many Java-based RIA frameworks does Apache plan to support? But again you are in a split-source situation. A little HTML, a little CSS, a lot of very fine control over the placement of elements via the HTML. I can see the attraction of Wicket, but I was hoping to ignore HTML altogether if I could. Move along, move along…
Last up (and what I thought would be the winner when I started) was Google Web Toolkit, which has some advantages and some disadvantages. It’s well supported, has a big community, dog-fooded to beat the band, and you can cheerfully ignore HTML if you want to. Plus, it has a nice Eclipse plugin, which for me is a must. Eclipse is my defacto operating system; I spend so much time in it that I can forget what platform I am on very easily.
I needed a real table component, complete with lazy loading, paging, sorting, column re-arranging, etc. I found various half-complete ones around the web, some even from Google, but none were out of the box solutions. Some were downright scary in terms of their half-built state. Such are the vagaries of code on the web. So, in the end, GWT was almost what I wanted — but in my questing for better components for GWT I came across the jewel: Vaadin.
Vaadin, to be succinct, is a magiuc pill for Swing desktop guys. It isthe bees knees. Da bomb. Vaadin uses GWT as a presentation layer for the UI components in the web browser, but all your programming is in Java on the server side. You build up UI’s with layout managers, just like in Swing. (There is an experimental visual builder, but I was not interested.) There is a pretty large chunk of components available; the demo page is large enough that I spent several hours just banging away at the demos! And the demos are useful; for every demo (and every component is demoed!) the source code is available right from the demo. That should be required on every web demo site. Very good for a learn-by-example guy like me.
And they have a great table component! And an Eclipse plugin! ZOMG!
It took me three days to finish my first prototype complete with multiple queries in separate tabs, a login page, query entry forms built on-the-fly with data type sensitive form elements, and the query results displayed in a lovely table which was happy to handle 100k rows. At least half that was spent farting around setting up Jetty and playing with toy examples to ensure it would do what I wanted. Sweet.
Now, you can get all into the HTML/CSS in Vaadin if you want to, but I don’t want to. I want it to be good enough visually out of the box that I can build tools that work. I find I am seldom interested in winning a UI design award — I need the default UI to be usable. And out of the box Vaadin is great at this.
And, the cherry on top: fabulous documentation and a genial forum membership. Honestly, I kept trying to ask a question, but I kept finding the answers already in the forum or in the aptly-titled ‘Book of Vaadin’. I have yet to ask a question of the forum, but that is a testament to how well the tool-chain is documented and how prolific the forum members are in answering questions.
Users report good success under concurrent load; that wasn’t what I needed. I used Jetty 7 as my target, and created an app that is a drop in web-replacement for a similar Swing app. And it was so easy!
Vaadin. Damn good stuff.