Question about Vaadin from a Flex user

Hello Vaadin forum members.

I have a question about Vaadin coming from a Flex developer’s perspective.

I found Flex an incredible development platform for building rich applications with high quality and visualization. A lot of the IDE features such as unit testing, debugging, code completion etc were some of the reasons I enjoyed coding in flex.

I am looking to broaden my knowledge into a new platform and have been heavily researching GWT.

I found GWT has some of the same issues that I found Flex had:

  1. A Single URL space to work in unless you build separate components/modules, but then state management becomes an issue.
  2. The applications can turn into giant monolithic applications that become hard to break up and componentize (e.g. if we want to put a piece of the console into a customers portal)
  3. Localization challenges in GWT (run time localization isn’t very elegant) Flex handles it better with some libraries I wrote.
  4. Customer customization (add an additional tab with an iframe to an internal URL passing an ID value to see some more additional information on what you are looking at)
  5. With flex being ‘on top’ integrating additional existing HTML UI’s was a nightmare. (floating iframe nastyness)

This list could go on for a bit, but basically I found GWT and Flex have a lot of similarities in large application architecture as well as the issues that go along with them.

I then came across Vaadin and am greatly interested in what it has to offer.

My observations and questions are:

  1. Localization seems to be all done run time/dynamic, unlike core GWT which compiles an app in the languages defined. This is key for us as we will have language packs that will be applied to our core app after product delivery. So am I correct that this is all runtime/dynamic so if I add a new message bundle and it exists, once I get the browser locale it will use it?

  2. It seems that Vaadin is meant to be componentized (a URL per UI component) much easier and more elegant than GWT, is this correct?

  3. If #2 is correct, than it seems the issue of monolithic apps goes away.

Anything else that I should be concerned about or look into for using Vaadin, or any advice for a Flex developer looking into this? Are any of my observations wrong?

Hi Steve,

basically, your observations are correct. There are some distinct differences between GWT and Vaadin even though Vaadin is based on GWT.

That’s correct, with Vaadin you can use the same localization mechanisms as with any other Java application. You’re free to use standard message bundles which are resolved during runtime. There’s no need to compile specific localized versions of your app as you had to do with GWT. Personally, I don’t think this is a big issue with GWT, as you could easily update your GWT deployment with new localizations during runtime. But granted, this involves a separate compilation step. With Vaadin you’d only have to provide additional message bundles.

I’m not quite sure what you mean by that. GWT and Vaadin are quite similar in that you can either write a single page application running under the same URL or a multi-page application where a page flow is faked using the URI fragment. Browser history support is provided by both technologies (or more specifically, Vaadin’s browser history support is based on GWT’s). By that, you can write rich applications that feel like traditional web applications with both frameworks.

It depends on what exactly you mean by monolithic in this respect. GWT applications are monolithic in the sense that you have all or nothing. You compile your GWT app into one piece (which could be split up into several split points making it a little less monolithic w.r.t download times) and that’s it (at least as far as I know).

One of the interesting parts about Vaadin is that you have a lot more options for modularization as with GWT, especially if you need dynamic behaviour during runtime. As Vaadin is a server-side technology you have the full feature set of the Java language at your disposal, e.g. reflection. Very interesting in this direction is the idea to combine OSGi with Vaadin which would allow for writing feature or component bundles which dynamically add GUI components and functionality to a running Vaadin application. There’s an article about that in the Vaadin Wiki.

Well, as cool as Vaadin is, you have to consider the downsides of the framework which arise from the fact that Vaadin is a server-side technology. Since every user action is handled by the Vaadin server backend, a Vaadin application naturally creates more network traffic and with that higher latency. A Vaadin app cannot be as “snappy” as a client-side GWT application. In addition to that, a Vaadin app has to keep more data in the HTTP session as it needs to build up a component tree of all GUI components internally. As Joonas Lehtinen put it, you don’t want to write the next Google Mail with Vaadin. In the end, your technology decision depends on what exactly you want to achieve in your project.

Thank you for the wonderful response. The application we are writing will not have a lot of simultaneous users connecting to is so the ‘chattiness’ of vaadin may not be an issue but definitely a consideration.

Regarding URL’s I wasn’t referring to the hashtag approach, I meant more something like

Where the admin URL is the general admin page, when I click to edit a user, i get directed to the useradmin page with a passed user id. The thought is that url is a reusable component which could be integrated in other applications if needed, basically it is a landing page for the user property screen for a given uuid. With flex, this really isn’t doable, with GWT it seems doable, but it seems like it is more doable with vaadin.

http://server/myapp/admin
http://server/myapp/useradmin?userid=[insert uuid here]

Due to a security limitation in web browsers to prevent websites from hiding their real identity, changing the URL is not possible without reloading the whole page from the URL every time it is modified.
HTML5 has added some support for partial URL rewrite, but as long as most browsers don’t support it, it is not so useful.

If reloading the whole page is not a problem for you, then it is not difficult to set.

But for most AJAX type of web application, those loading, flashing the page to white are not desirable. That’s why they are using the fragment part of the URL. The fragment can be changed without forcing a page load, it appears in history and can be bookmarked.

Fragments can be used as simple markers (like in Gmail “#inbox”, …) or as more complex structures (like Vaadin sampler “https://vaadin.com/directory#addon/sessionguard”) you can even use ? and & in the fragment so you could have :
http://server/myapp#admin
http://server/myapp#useradmin?userid=[insert uuid here]

Mathias;
Fair enough and all valid points. I am curious though, in my use with hashtags in flex, they don’t survive a 302 redirect. I could be wrong, but this was an issue when we were having people email or bookmark links like that and they got routed to a logon page, it would lose the hashtag and everything after it.

That’s right, HTTP redirects are more in line with the classic HTTP request/response model which does not fit very well with rich client applications. So here you’d have the same problems as described by Mathias. Use redirects without hashtag URI fragments and you get that nasty flashing white page effect. Use redirects with hashtags and the URI fragments are dropped from your URL (depending on the browser). But as with the page flow issue, one should think outside the box when it comes to redirects to user login pages in rich clients. You actually don’t need them here. If an anonymous user requests a secured “page” (i.e. part of an application identified by some #uri/fragment) this can be intercepted by the application itself and handled accordingly. For example by opening a modal login sub-window; just as you would do in a desktop application. Another option would be to remember the original URI fragment parameter and swap it with a fragment pointing to a login page, such as #login. This would feel like a redirect for the user only without involving a real 302.