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.

GWT works by cross-compiling a subset of Java into Javascript; this means it works with current browsers, takes care of browser incompatibilities, and just plain works out of the box. UI design in GWT/Java was familiar enough coming from Swing, so I had a prototype very quickly. But …

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!

You get (from my admittedly skewed preference for programmatically-built GUIs) the best of both worlds: pure Javascript on the client side, straightforward Java on the server side. You can damn near ignore that it is a web app at all; it feels like writing a dedicated desktop app. Very cool.

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.

Explore posts in the same categories: Software, Tech

Tags: , , ,

You can comment below, or link to this permanent URL from your own site.

90 Comments on “For the Love of Vaadin: RIAs Done Right”

  1. Jacek Says:

    You really should have stepped back and look at Python Django. Seriously.

    We are a hard-core Java/Spring/Hibernate/Maven shop. We were planning to do everything in JSF2 or something like that.

    But after I seriously played with Django for a week (built a real app with lots of CRUD screens and customizations) I could not imagine going back.

    Going back to JSF2 was like being forced to crawl after you had discovered how to run.

    The Django admin interface is phenomenal. And their ORM is brandead simple to use. Couple that with the very good PyDev plugin for Eclipse and you’re ready to go. Any Java developer that’s decent should be able to pick up Python in 2-3 days.

    As such we are standardizing on Java for all of our server-side apps and on Django for all user portals.

    And yes, I am an old Powerbuilder guro so Django reminded me of that massive productivity I used to have back in those days.

    • designbygravity Says:

      Django is nice, but with a small team, polyglot programming is dangerous; I’m hard over that we stick to Java if possible.

    • hezamu Says:

      I’m a Vaadin team member that had a crush with Django a year or two back. While the ORM stuff is nice I don’t much care for needing so many different things to get the job done. With Django I need know URL patterns, page templates with custom tag syntax, request/view API to build the UI. All of these things are decently done in Django, but with Vaadin I work with 100% Java and that’s it.

      Besides, when I looked at it Django really didn’t do RIA, at least without significant effort. Not sure what’s the current state of things, but Vaadin UI’s are fully RIA’d with zero effort required from the developer.

      Not saying that Vaadin is the best tool for any job, but if you do business apps with Java you really should at least evaluate Vaadin. It’s very easy to get started.

    • YeahOk Says:

      No one is a hardcore hibernate/maven shop – those are two broken tools that people are usually forced to use. I’m not surprised you would consider randomly jumping to another platform.

      • designbygravity Says:

        OK, that’s funny! Reminds of a draft post I have somewhere pointing out that Ant is improvement over make only because improving on make is such a low bar…

    • FoX Says:

      Take a look at the play framework; looks a lot like django but it’s Java all the way.

  2. AllanC Says:

    Good article. I’m leaning towards GWT+SmartGWT. The latter gives really, really good table support, complete with data sources, lazy loading, the works.

    • Joonas Says:

      SmartGWT builds on SmartClient JS framework. This has two implications:

      1) Client-side size. A quick comparison between the Vaadin and SmartGWT client-side weight:

      Vaadin loads total of 159kb of JS and HTML. Size of the client side stays static when your application grows. The size is related to the number of widgets included. You can easily cut down from that 159kb – which includes all widget from the standard widgetset – if you do not need them all.

      SmartGWT Showcase loads total of 825kb of JS and HTML. The size will grow when your application grows.

      2) Extensions. You can easily add custom widgets to Vaadin as they are just normal GWT widgets with one extra method. In SmartGWT it is not as simple as the widgets should work together with SmartClient Js library.

      • AllanC Says:

        Very good points worth considering. One of the tradeoffs is probably higher traffic between the client and server in processing events.

        • Joonas Says:

          Yes. Because in GWT you are developing on client-side you have 100% control over when, how and what to communicate with server. So you can optimize the traffic, but also must implement everything yourself and be careful not to open any security holes while doing it.

          Vaadin on the other hand handles all client-side communications automatically. Thus it is a tradeoff between easier programming model (Vaadin) and minimal server traffic (GWT).

          In practice Vaadin passes really small messages between client and server and thus it requires lot less bandwidth than traditional web application that sends large web pages over the wire to update state on the client.

      • Sanjiv Jivan Says:

        The SmartGWT demo has around 280 samples, many of which are quite large or complex. SmartGWT is extremely feature rich and has the most powerful ListGrid and TreeGrid widget available in any other RIA library that I know of like automatic databinding, row expansion and nested widgets, filter builder, grouping, frozen columns, virtual scrolling, adaptive sort / filtering, editable multicolum trees, databound dependent selects in editable grids etc – most of which do not appear to be supported by Vaadin. The list of features is too long to mention here but you can have a look at the Smart GWT showcase demo yourself :

        I had a look at the Vaadin sampler and see that it has 99 samples, out of which there are only 16 samples of tables and trees and a vast majority of the remaining samples are rather simplistic which might explain the smaller size. A lot of rather basic Grid and Tree features required by most Enterprise apps also do not appear in the demo. For example an editable Grid or Tree. The SmartGWT demo has 120 samples of tables and trees alone demonstrating various supported features. Smart GWT also has support for TileGrid, Millier Columns, Calendar, Portal etc – all part of the free LGPL offering and demonstrated in the SmartGWT Showcase.

        When evaluating a framework you have to consider the features that are baked into a library itself version having to write and maintain “plugins” or “extensions” yourself. The cost of trying to build a complex feature that is not supported by the framework itself should not be underestimated.

        This is one of advantages of Smart GWT – pretty much all the features that any enterprise may need is based into the framework and when you do need to incorporate a new functionality it is also possible since Smart GWT and SmartClient are open source. The

        Finally I’d like to emphasize that Smart GWT lends to a lot cleaner user code due to the inbuilt DataBinding capabilities. I describe this in detail in a blog I had written a while ago.

        • Joonas Says:

          The main point here was that in GWT (and SmartGWT) the size of the client-side grows when the application grows. In Vaadin client-side size is static and lean even for huge applications.

          The strategy for less used widgets and features is different in SmartGWT and Vaadin. In SmartGWT bundles the features to the product “core” and Vaadin provides add-on architecture where you can easily drop in extra widgets and functionality as jar-files. Add-ons contain both the client- and the server-side in one “drop-it-in-and-it-just-works” package, which makes the approach unique. A directory of such add-ons will be opened tomorrow at, but there is already almost 100 add-ons available.

  3. florin Says:

    I got a big problem with it. Really big. There is no programmatic control over component style. A new class item needs to be introduced for any variation of a component. The result is css files thousands of lines long. Heck!

    So after spending hours and hours customizing a freaking panel, I gave up.

    You know what? I want control over what I do – it is called freedom. You take freedom away, get lost.

    • Joonas Says:

      Styling Vaadin widgets requires CSS, but it should be fairly easy as DOM structures are tuned to make styling easy.

      Granted – you must say mycomponent.setStyleName(“myCustomStyle”) and add a line to CSS instead of being able to say something like mycomponent.injectCSS(“text-color: red”); Good think is that this keeps looks and ui logic well separated.

    • designbygravity Says:

      Well, perhaps you’re after a really different UI experience than I am; like I said, I want something looks presentable, out of the box, from off the shelf components. To me, no programmatic control is a *plus*; it makes it a little harder for devs to while away hours and hours testing different pixel widths.

      On the other hand it looked pretty easily themed; I got curious one afternoon and went through the theme HTML and it is pretty well laid out, and very well documented.

      So .. I guess we disagree. That’s ok.

  4. […] 23, 2010 · Leave a Comment For the Love of Vaadin: RIAs Done Right It’s a very strong endorsement and the demos do look pretty […]

  5. sedwards Says:

    How does it compare to Play? They sound like they have similar objectives.

    • designbygravity Says:

      Play seems more concerned with exposing and optimizing the traditional web app framework; stuff that built to be servlet-modeled from the ground up. It *feels* like a web app, not a desktop app. Plus, Groovy as a templating lingo. Meh.

      Vaadin feels like your developing a desktop app most of the time. For me, that is a plus.

      IMHO, of course.

  6. Rafael Cintra Says:

    I’ve been trying to use Vaadin for a personal project in the last weeks. The funny thing is that your post praises so much the Table component and actually it was exactly the motive for me to give up on Vaadin. The fact that you can’t use keyboard to interact with the component and also the poor support for multi selecting items was a deal breaker for me.

    Since you come from AWT/Swing background (like me) I recommend you giving another try in the Apache Pivot. Despite it supports you to declare the UI using XML you can just ignore it and use just plain java code as I do.

    I have been using it for the last days and I am very happy with it so far.


    • designbygravity Says:

      Pivot is pretty, but client side Java is a no-go for my purposes.

      I didn’t need keystrokes or multi-selecting, so experiences vary.

    • Joonas Says:

      Regrettably Table does not have keyboard navigation. I hope that this will change soon:

      Multiple selections in Table is as easy as table.setMultiSelect(true)

    • Marc Says:

      Some more on this:

      We actually have a list of usability improvements that we’re going to do, many related to keyboard navigation, and the most urgent is Table. It’s not going to make it into 6.3, though.

      It unclear what you mean by “poor support for multi selecting items”, but I assume you know about setMultiSelect() and mean shift/ctrl-selections and perhaps dragging to select?
      Shift/ctrl-selections can easily be done with an ItemClickListener (example on the forum), but the functionality should really integrated. Drag-multi-select requires changes to the client-side component, so that functionality should definitely be added as well.

      Is this what you meant, or did you have some other multi-select needs?

      (For those of you who have not tried: out of the box, Table multi-selection is currently click-to-toggle; this is the most requested mode, a must for many, because ctrl/shift/drag -selections are not familiar on the web. Times are changing though, and different applications have different requirements.)

      Best Regards,

      • Rafael Cintra Says:

        Hey Marc, thanks for you reply.

        I did mean the shift/ctrl selections. I was not aware of the “workaround” of using ItemClickListener to accomplish this. This solves the problem. But I have one question regarding these selections: every time you make a new item selection, does the client communicates with the server to render the highlighted item?

        Just one more question: the keyboard navigation feature in Tables will allow the configuration of the keys used for the navigation? For example, besides the arrow keys, will it be possible to define other keys to navigate such as “j” for “down” and “k” for go “up”?

        Thanks in advance.


        • Marc Says:

          That’s right: if you use the ItemClickListener solution, it does a server roundtrip – which is why it should be built-in functionality.

          Regarding configurable navigation keys, I updated the ticket to specifically mention this (the usability report might mention that, I can’t remember, but the ticket did not).

  7. florin Says:

    CSS and style.

    It is not that I need to ‘inject’ a color. It is about component layout. Picking up vaadin is a no brainer. I really appreciate the event model and even the data binding is cleaner than wicket’s. So after I read the tutorial, and already built a CRUD app, I tried to see if I could work with the layout. I spent hours modifying the tab component where dozens and dozens of css classes had to be altered – it worked. It took me two days, I did it and then I said I had to start with the next component? I gave up.

    One of the biggest problems with ‘RIA’ is the desktop app look. The browser is different and really I prefer it to the desktop. There is so much room to layout stuff and keep a clean screen.

    So, if I want three style of tab components what do I do? It’s daunting how long those css files are.

    In spite of that, vaadin does a great job of building a good looking component set with swappable themes. I felt sorry I could not use it.

    It’s work in progress and I trust that they listen to the community. It’s better than most already. Good luck.

    • Marc Says:

      Yeah, we’re working on it! This kind of feedback is very valuable to us – feel free to join in by commenting on the forum or on UserVoice 🙂

      About the theming issue: the default Reindeer theme uses a lot of CSS to achieve that look on all browsers, and when you want to customize, a lot of work is spent ‘removing’ those styles. In your case you might have been better of starting with the bare-bones base theme. Another possibility is to take the Reindeer sources, rip out everything that has to do with the particular component you want to style, and re-apply selectively.

      Also note that many components are very easy to style, while others (TabSheet, Table, …) are more complicated.

      Anyway, we’re looking at ways to make this easier.

      Best Regards,

    • I admit those words cling true to my ears, unfortunately. Having written almost every line of the core Vaadin themes’ CSS, I can say, too, that some of the components are way too complex and hard to style. (Did you try styling Buttons? Not fun.)

      Did you try to override the default Reindeer theme, or did you use the Base theme as a starting point? Just pointing out, that there’s a huge difference in what theme you start with, since Reindeer is a monster in its complexity compared to the minimal Base. With Base, you pretty much get a blank canvas to work with.

      But I agree, making multiple styles for a single component/widget is a pain since you end up overriding loads of properties just to achieve simple things. I’ll make a promise, even if it would just be for myself, to improve on particular area.

      And I wish the widget HTML-structure was a bit leaner, too. It has gotten to this point when several team members have added new features and fixed bugs without anyone keeping the overall view of the component’s theme/styling in tact, so the result is sub-optimal. But at least it is flexible, when there’s an abundance of elements and classes to work with 🙂

      Not having any experience with other similar web frameworks (no time to play with them) I’m more than eager to hear how they’ve made styling work? Is it pure CSS like in Vaadin, or do they have some sort of builders for the styles? How easy is it to change the ExtJS or SproutCore styles for example?

      But anyway, thanks for the valuable comments! And as you said, Vaadin is a work in progress, and I’m always eager to hear the community’s comments and suggestions, so keep it coming.

  8. Setya Says:

    If you’re familiar with Eclipse RCP & SWT you should feel at home with Eclipse RAP.

  9. Yama Says:

    How about the comparison with ZK?
    ZK seems more mature and more complete.

    • Joonas Says:

      Quick comparison:

      – Vaadin uses GWT for the rendering, ZK uses proprietary client-side. This makes it a lot easier to add more widgets to Vaadin – it can be done in pure Java and there are a lots of good books about Google Web Toolkit that help.

      – ZK embraces XML for user interface declarations. Although you can use pure Java in both frameworks to define user interfaces, Vaadin is designed from scratch to be programmed in 100% Java.

      – Vaadin community is much more active in contributing add-ons to the framework. Today these add-ons are scattered around forums and svn, but starting from Mar 30. has a good directory where you can just drag and drop new widgets, datasources and other add-ons to your project. In launch there will be about 100 add-ons next week to choose from.

      – Vaadin is released under Apache 2.0 license. ZK has two versions – limited community edition under LGPL 3.0 and full version released under commercial license.

      • George Clark Says:

        Disclaimer: I am a fan of ZK, use ZK in many projects while only evaluating Vaadin to see if our choice is correct.

        — Vaadin uses GWT but it has different lifecycle. For example, you can’t use GWT builtin components directly. In additions, Vaadin requires to load all JS code no matter a component is used or not. On the other hand, ZK, while running on of jQuery, has its own OO mechanism in JS, which is easy to develop (and ‘accurate’ to debug with Firefox). The downside is that you need to know JS.

        — Many UI of my projects are done in pure Java with the so-called ZK richlets. I’m glad to have the choice to use markup or pure Java.

        — Go to and search ZK and you’ll find how many projects depend on ZK. Not just widgets.

        — It will be great if ZK is licensed under Apache, but the community edition is much much better than Vaadin. For instance, I were surprised Vaadin does not support Drag&Drop which shall be ready many years ago.

        — ZK has very strong integration with Java technology, from Spring, JPA, MVC… and up to the recent CDI. I don’t see much support in Vaadin.

        — ZK has very powerful components, such as calendar and spreadsheet, that cannot be found in Vaadin (including their roadmap)

        — Vaadin’s Ajax update is too coarse grained — it tends to invalidate the whole widget if what we need is to change an attribute.

        — The strongest point of Vaadin is everything in Java. But, while GWT is a client-side solution, developers, ironically, can’t access the client directly with Vaadin. Every request has to go back the server.

        • Joonas Says:

          Quick comments:

          ” Vaadin uses GWT but it has different lifecycle. For example, you can’t use GWT builtin components directly.”. True – you must implement one additional method to widget to use it in Vaadin (updateFromUIDL()). Still – IMO – this is a lot better than having to write JavaScript in order to extend the framework.

          “Vaadin requires to load all JS code no matter a component is used or not.” Not true. You can select to only include widgets you use on the client-side.

          In practice including all Vaadin standard widgets required 159kb of HTML+JS to be loaded. This is all needed to run Vaadin Sampler demo for example. Starting up ZK Explorer demo loads 158kb of HTML+JS initially when demo is started. While using demo, total amount of HTML+JS grows to 346kb (this does not include any third party integrations like Google Maps or Simile).

          From this I would say that Vaadin is considerably leaner on client-side.

          “I were surprised Vaadin does not support Drag&Drop which shall be ready many years ago.” – Vaadin 6.3 includes comprehensive Drag and Drop support. This includes component to component drags, reordering of components, client and server-side drag handlers, HTML5 support for dragging resources from the Desktop. You can use 6.3 today (just download a nightly build) and 6.3.0 RC will be released this week.

          “ZK has very strong integration with Java technology, from Spring, JPA, MVC… and up to the recent CDI. I don’t see much support in Vaadin”. You should look harder. There are several application stack examples on Spring integration, several JPA integrations, OSGi integrations, etc. Just type your choice of integration to the search field on 🙂

          “ZK has very powerful components, such as calendar and spreadsheet, that cannot be found in Vaadin (including their roadmap)”. Full featured Vaadin Calendar will be released in couple of weeks, but here is no spreadsheet component for Vaadin. On the other hand there are lots of components for vaadin not available for ZK – for example a proper lazy loading timeline component:

          “Vaadin’s Ajax update is too coarse grained — it tends to invalidate the whole widget if what we need is to change an attribute.” Not true – this is decided on widget by widget basis. In most widgets only the changed attribute is updated.

          “The strongest point of Vaadin is everything in Java. But, while GWT is a client-side solution, developers, ironically, can’t access the client directly with Vaadin. Every request has to go back the server.”. The idea here is to do everything in Java on the server-side. Client-side only comes to picture when you want to extend the framework by adding new widgets. Then being able to use Java on the client-side is a really strong point.

          • Stone Says:

            It sounds to me: the only benefit of using GWT in Vaadin is to simplify the development of widgets (for Java programmers).

            But, I don’t develop Swing widgets when developing a Swing application!

            • One thing that I always like to think as a big benefit of Vaadin is that you don’t need to worry about any RPC, data-serialization or client-server-communication yourself, it’s all done for you.

            • Joonas Says:

              You are kind of right. If you are not interested in extending the framework, client side (including GWT) is irrelevant to you. Still – even in this case the knowledge that you CAN easily extend the framework IF you need to is probably a good thing.

              (In larger applications it is not that uncommon to add some esoteric rich dynamic application specific graphs to the application what just doesn’t exist in any framework)

          • George Clark Says:

            I like the concept of server+client fusion proposed by ZK: writing 99% of code at server side, while optimizing 1% at the client. However, ZK requires JavaScript at the client. Thus, if Vaadin enables me to write client code in Java and collaborate with my server-side code, it will be a very big plus to me.

            • designbygravity Says:

              Have you specifically found something that is slow when doing it server-side in Vaadin? Because their comm protocol seems mighty efficient.

            • Joonas Says:

              “if Vaadin enables me to write client code in Java and collaborate with my server-side code, it will be a very big plus to me.”

              It allows exactly that. The client-side code will be packaged as “UI components”. These components can be as large compositions as one view and thus you can easily implement parts of you application 100% in client-side – if you really want to.

              In a way – Vaadin gives you best of Server-side RIA as well as best of Client-side RIA (GWT).

          • kCai Says:

            If user want to navigate throw the browser using backward or forward button, can the server-side control also?
            So far I cannot figure out how to use browser button to navigate.

          • Olly Says:

            re: timeline.

            This is pretty slow compared to what is out there. eg Google Finance :


  10. Peter Says:

    You pretty much hit the nail right on the head with this post and have given all the reason why I, too, love Vaadin.
    If you’ve ever programmed Swing, you feel right at home. The interfaces are clean and (almost) never confusing.
    The developers give great support (and are kind when correcting errors, such as the one I made about serialization requirements last week 🙂 )
    Personally, I haven’t really used the Eclipse plugin too much, but apparently I should.

  11. Luciano Says:

    I’ve evaluated Vaadin about six months ago, I saw a great potential but for my project I decided to stay with pure GWT. IMHO the fact that Vaadin is based on GWT is a big strong point, as big as being free to do everything in Java.

    GWT offers great freedom on the client, while Vaadin provides excellent components out of the box. Being able to integrate both is the best possible scenario.

    I’m sure that Vaadin will gain a big reputation in Java RIAs, and please stop comparing it to Wicket and similar, since they have different targets.

    The only point where I’d like to see improvements in the number of available themes, plus ease in custom theme creation. Themes is where we as developers need help from designers, and designers must be able to express their skills.

    • I can promise some light at the end of the tunnel for you: next week there’ll be a new theme available, which is color-customizable using a wysiwyg editor. You can see a demo at

      The theme will be available as a Vaadin add-on in the Directory next week.

      I’ve toyed with the idea of a full-blown theme editor, but nothing concrete on that area to show. I’m happy to hear wishes and suggestion for that, too.

      • Luciano Says:


        that’s great news. I don’t think that you need to create a full-blown theme editor, those tools are always limited, see the jQuery UI one or the Telerik one.

        Having the chance to let a designer free to create a theme with CSS is enough for me, I never tried it with Vaadin, I just hope that the generated HTML is designer friendly and that the CSS hooks are the right ones.

  12. Vaadin is really well balanced product – you get a wonderful (did not see better ever!) documentation, great and attractive initial look and feel, excellent and easy API and more than a friendly team and community. We switched to it and running in the production for a year+ now with the several projects and I could say there are no regret. We’re able to make both web-style and swing-style apps easily, have standards, any designed understandable css files and pure java logic code, so what else to wish to have a happy work time ? 🙂

    The only thing is really not so big set of built-in widgets. But I think this should be compensated by the upcoming directory with a great content inside.

    • George Clark Says:

      I won’t call it well balanced unless Vaadin allows developers to write some application code in GWT (and running at the client). It looks like GWT is only a widget development tool for Vaadin.

      The only one thing I complain about ExtGWT is I cannot access the widget at the server. Unfortunately, with Vaadin, I cannot write the client code; every request has to come back to server for processing. It will be great if Vaadin can solve this out and bring us a true balanced solution.

      • designbygravity Says:

        I don’t know; Vaadin seems to be aiming to solve the RIA problem specifically by doing everything on the server side. The only useful argument for giving client-side access is if there is something you simply cannot do server-side. There have been lots of assumptions to that effect in various comments, but precious few tested assumptions.

      • But actually you can write your client-only code in GWT, isn’t it ? Vaadin does not stop you from creating a client-side widget where you can reduce number of server-side roundtrips.

        But for most apps it is not 100% required part, which saves a huge amount of time on extra GWT translation process and some debugging and RPC stuff. However if you plan some non-standrad UI control – you have the choice of server-side composition of standard elements or pure client-side code creation.

      • Marc Says:

        There are already some applications with some very specific requirements that have certain widgets communicating on the client side w/o contacting the server; it’s all GWT, so you can certainly do that. However, it requires your to understand when and what to sync with the server. We are probably going to be looking at ways of making this easier in the future, but it has not been very high on the list yet – making sure there is no need to do that kind of thing has been our main priority.

  13. […] For the Love of Vaadin: RIAs Done Right Yes! RIAs done right! […]

  14. […] For the Love of Vaadin: RIAs Done Right « Design By Gravity […]

  15. Jani Laakso Says:

    Here’s why I use Vaadin.

    For me it’s about creating Applications, not Web pages. I love to use pure Java because then I can use all the object oriented concepts for my UI codebase too. XHTML or XML is great for more static stuff such as Web pages, but when you start adding application kind of logic to your “web pages” you end up mixing declarative languages with procedural and lose many benefits such as composition, inheritance, code refactoring + other nice stuff that modern IDEs offer. These benefits are hard to accomplish for your XML files wouldn’t you agree?.

    After you have committed months or years of development time to your application, I feel the design is more beautiful and code maintainable when you have created UI code using Java and kept declarative files (XML) out of the equation. For me, this means less stress for the application developer team and better ROI for the project. Java and modern IDEs FTW 🙂

    On the other hand, I would not recommend Vaadin for more static web page styled projects.

  16. Bubak Says:

    I am die hard Swing fan, but this looks very reasonable. Will give it shot.

  17. Indra Dutta Says:

    Vaadin looks promising. I found the demo slow on IE7 but worked well on Chrome. It was not clear to me how to access server side features knowing that it is based on GWT.

    For people coming from swing background and trying to develop web applications, I will highly recommend the echo3 framework. It has both client side and pure server-side java development. I have used it in the past with great performance and functionality. Look at the demo app at Echo3 has good documentation and an active community.

    – Indra

    • Joonas Says:

      All of the code you see on sampler examples is running in the server-side. Thus the programming model is almost the same as in echo3.

      GWT is used only for extending the framework by adding new widgets to it. Thus the difference to echo3 is that in Vaadin you can extend the client-side in Java (or in JavaScript if you really want to) – in Echo3 you must use JavaScript to extend the client-side.

  18. Bob Says:

    Just another thumbs up for Vaadin. We are using it and love it.

    It’s just so liberating to be free from the mess of (x)html and javascript.

  19. soudmaijer Says:

    Basically, you like Swing and you like Eclipse. Thats bad for starters. How serious should we take your Vaadin post? 😉

    • Chris Says:

      Well, I *do* like eclipse, and tolerate Swing. But in both cases I know how to get things done with them, quickly with a minimum of fuss.

      Everyone likes to complain about Swing, but it does let you get decent UIs built in a hurry.

  20. […] For the Love of Vaadin: RIAs Done Right « Design By Gravity – 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. […]

  21. Janjeev Says:

    Vaadin is not really free any more.

    How come Joonas (Vaadin CEO) critized other soltion’s dual licensing model while Vaadin is doing the same thing (commercial license)?

    • Joonas Says:

      Janjeev. Please read the forum thread you linked to. It answers to this exact question. Short brief is: Vaadin is and stays under Apache license and is not dual-licensed.

  22. Rishi Says:

    Vaadin will not be complete free.

    It would be a big concern that some important widgets or features will be commercial addons. Just like Joonas critized other Ajax solutions with limited features in community edition.

    • Joonas Says:

      “Vaadin will not be complete free.” -> Quite the contrary. Vaadin is and remains free. If IT Mill or any other company (or an individual) releases commercial components that complement Vaadin – it doesn’t make it less free. Please read the forum thread you linked to even though it is quite long.

      You are probably referring to an add-on called JPAContainer? Did you notice that there are already two independently developed apache licensed free alternative JPA integration implementations available on Vaadin Directory?

  23. james smith Says:

    very informative..thanks a lot..james

  24. nmatrix9 Says:

    I’ve just started learning GWT, but something tells me I’m gonna be using Vaadin for some very hardcore development of some apps I have in mind.

  25. PowerBuilder Says:

    Hi dude,
    I read your blog,This is a wonderful blog.I was able to get the
    information that I had been looking for. Thanks once again.
    PowerBuilder development company

  26. mkindika Says:

    Vaadin is great frame work. And it is open source.

  27. mkindika Says:

    I have used to use richfaces and primefaces.They have large components libraries. I am learning vaadin now.

  28. bat Says:

    Just like you I prefer to programatically create my UI, and leave HTML and CSS out of the equation.

    I’ve been using GWT with GWT-Ext for a couple of years and I find it to be extremely effective, and it was very very easy to get up to speed. But it has one flaw: you must do things in Java, can’t use another JVM language.

    I’m sick of Java’s verbosity and constraints, and now trying to find a framework that can be as efficient as GWT but where I can code in Scala.

    I’ve defined a simple app and now experimenting to code it in several frameworks. After some time trying to do it in Lift, I’ve gave up. I found it terribly difficult to get up to speed, the documentation is poor, the methods are cryptic, it is certainly powerful, but it’s very hard to figure out HOW to use it effectively.

    After that I’ve implemented almost the whole app with GWT in just one evening, which was refreshing after the Lift pains.

    The two candidates that now appear to be promising are Zk and Vaadin.
    What would be the pros and cons of both these frameworks if I want to use them with Scala and not Java?

    • My experiences on using Vaadin with Scala have been very positive. I haven’t encountered any problems regarding Vaadin, and the development model is identical with Java.

  29. Olly Says:

    I reviewed Vaadin against a few other techs on my website :

    I thought it was great, but i couldn’t find any example of an editable table cell.

  30. Johan Smolders Says:

    Which Framework did you use to connect to the database?

    • designbygravity Says:

      This was an internal project with my company’s deductive database product, so the framework was custom. Of course, I know the API pretty well. 🙂

  31. techstu Says:

    thanks for a great blog. ok so here is what i gather correct me if i am wrong. if i am working on a web app i go with vaadin. if i am working on a web app with slick look and feel either i use vaadin and work hard on css + html or i use other client side techs. Right or am i still missing something. hey i like vaadin its just that i am working something out for fashion industry and a magazine where gloss is important with all the functionality packed in. might use Magnolia for the mag. i want it both great back & great front 😉

  32. Jet Says:

    great blog… all questions and issues has been properly addressed. Im a Swing developer so I will try Vaadin. ^_^

  33. Jet Says:

    can we record an audio/video in Vaadin? with preview and upload feature.

    • Joonas Says:

      For that you would need add-on components. Take a look at the There are components for at least video camera and screenshots, but I have not tried them out. Vaadin has built in HTM5 controls for video and audio output.

  34. Alihan uygun Says:

    To me the code to create the ui is meaningless and boilerplate. You spend considerable amount of time to create buttons labels etc. Imagine coding Html in java createLabel createButton createThis that blah blah blah. Any code not related to your core domain should be minimized. Vaadin is on the contrary maximizing this.

    • Vaadin is certainly not suited for everyone. If you want to write the HTML by hand, do the asynchronous RPC yourself using JavaScript, mess with lazy loading, handle browser compatibility issues and so forth should probably use something else.

      The point of Vaadin is to give all those things to you for zero effort. Vaadin is aimed at those who are not interested in these things, and would instead like create their UI using Java (or Scala etc) in the same server environment that the business logic is running on.

      Have you tried Vaadin yourself? It’s very easy to get started.

  35. nice blog very helpfull, alot of questions that i wanted to raise where answered above.
    To me it seems that vaadin solves the ‘webapp’ problem very nicely.

    The only problem i see is the pricing of a few core components i.e the jpa container (299$ is quite a lot).

    In my opinion its better to monetize components that are more exotic like they do with “Touchkit”…

    • Joonas Says:

      There are several free alternatives for JPA Container in That said – we hope that the value JPA Container and other commercial add-ons to Vaadin are worth their price.

  36. Hello there! This post couldn’t be written any better! Reading through this post reminds me of my previous roommate! He continually kept talking about this. I am going to forward this post to him. Fairly certain he’s going to have a good read.
    Many thanks for sharing!

  37. radyo dinle Says:

    Hi there i am kavin, its my first occasion to
    commenting anywhere, when i read this paragraph i thought i could also create comment due to this sensible article.

  38. novotronik Says:

    I’m working with Vaadin daily. It has only beautifull demo elements, no more. Sorry but:
    * GUI Elements are not finished(ex. how play with table? in ‘generic’ era you use a lot of object arrays! Realy sucks! did you see any other GUI frameworks ever (instead of SWING and AWT)?). Did you seen last trends in GUI frameworks? Almost each component is need to redo or customize and have a lot of same components in your project.
    * Architecture design sucks. A lot of constants!!! A lot of internal classes. Did you ever seen S.O.L.I.D. principle or something like that?
    * Untestable (just their custom components for testing)
    * Did you ever tried to do faulty project? How is thinked that is so much serialization? Did you ever tried to restore a real session? How much you have to **** with it to be possible to save/restore session?
    * In real projects Vaadin realy sucks. Maybe something will be changed in version 8 < XXX.
    * Too heavy final pages.

  39. […] I started searching for a good Web-UI framework and I happened to come across and read the blog For the Love of Vaadin: RIAs Done Right. It's like a light from the end of the tunnel as I have tried several java frameworks but designing […]

  40. […] I started searching for a good Web-UI framework and I happened to come across and read the blog For the Love of Vaadin: RIAs Done Right . It’s like a light from the end of the tunnel as I have tried several java frameworks but […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: