30 comments

[ 7.2 ms ] story [ 149 ms ] thread
It seems like the 'Cappuccino' of the GWT.

Edit: It even has a multi-platform 'nib2cib': "WYSIWYG user interface editor under Eclipse"

This looks great. So far I have used ext-gwt, but I stopped because they changed a year ago their license. Felt like a bait and switch. This sort of product is badly needed on GWT to completely kick ass. Also take a look at SmartGwt.
Ext-GWT is a hell when it comes to widget customization. Also the API prevents it to be extensible.

From my personal experience (very very tiny data point), most of these "beautiful" GWT frameworks are good only if you want to wipe out something fast and don't mind with the default look.

It looks good, but I don't see any demos that involve graphics. How usable is Vaadin for graphics?
According to this example: http://demo.vaadin.com/Coverflow/ It seems like you can add custom widgets easily. In this app they started using a Flash Widget for custom graphics.

I'm not a GWT developer, does anyone have any experience adding custom GWT/Vaadin widgets to your applications?

Book of Vaadin http://vaadin.com/book has a whole chapter on this. Also the Vaadin Eclipse Plugin makes getting started with adding new widgets trivial (just "Add New Widget" and it creates a widget stub for you)
Because of the server-driven architecture, you can use graphing libraries like JFreeChart easily.
Be aware that the paradigm of Vaadin (known as IT Mill Toolkit) is leaning toward server-side. GWT is 100% client-side (plus RPC).

My guess is that Vaadin did a bit of UI rendering (prep-ing the HTML) on server-side then send it to client.

That was my impressin too. Are they trying to erase the boundary between the server and the client? If that's the case it's a terribly misguided thing to do...
Indeed. I'd love to use my Java knowledge to write pretty interfaces, but on the server side I'm better off using Python.
Agreed, I definitely feel most comfortable with my Python on server-side, but the UI ability on this thing is beautiful. Too bad... I wish I was at JavaOne so I could ask these guys some questions regarding how easy it is to separate the two components.
Vaadin keeps the application state on the server, but the presentation (HTML) is 100% generated on the client side. Changes in server-side state are serialized and sent to client in compact User Interface Definition Language (UIDL). This is obviously a more secure approach to writing web apps, since the state is safe on the server. So no pre-rendering of UI on the server..
Yeah. Every component has a server side and a client side. Client side has all the rendering stuff in it while the server side has the business logic. That way the functionality can't be hacked as the client side is just responsible of sending input to the server, where all the hard work is done.
You can ask all the questions on your mind on our forums (http://vaadin.com/forum/). You don't need to attend JavaOne to get the hard questions answered.
Yeah I am trying to find out. They are here at javaone - doing too much UI on the server side does seem like a real mistake for a tool like this. One of the nice things of things like this (and cappaccino) is that the server side becomes freed from worrying about what the client is doing/has open etc...
This is a matter of taste - benefits of the server-driven architecture are: no limits from the server, no GWT recompilation, direct access to server-side API and resources, better security, full Java virtual machine, full tooling and debugging support. Downsides are: more client-server traffic, more data to store in HttpSession.
I think the most impmortnat problem is trying to hide the netowrk under an inhenrelty leaky abstraction: http://www.erlang.org/pipermail/erlang-questions/2008-May/03...
yes that is what worries me - I like network stuff to be explicit.
There are multiple levels of control: 1) for each UI component you can select to send events immediately to server or alongside the next "packet" sent to server. 2) as we are building on top of GWT - you have the full GWT-based RPC also if you want to do the communication manually.
Greetings from the company developing Vaadin :)

Yes, Vaadin is a server-side framework. Server-side is not for everyone, but there surely is a place for Vaadin. For example issues with trusting the code that's executed on the client are greatly relieved this way.

You could think of Vaadin as the Swing / SWT for web applications. Sitting in between JavaFX (plugin required) and Java Server Faces (html required). Vaadin is great for desktop-like applications in the webbrowser, but doesn't really fit the RESTful type of applications.

If you have questions, just visit our forums at http://vaadin.com/forum and ask away! There are plenty of experts waiting for challenging questions ;)

Vaadin is actually sending only small JSON snippets to client-side. These are instructions to browser on what to draw. Like: "add a button to layout", "change the contents of a label to say hello", etc. All rendering is done in client (using GWT). So the client defines what the button looks like, how it behaves, ...
yeah, I was actually just noticing this. I would lean more towards the 100% client-side + RPC.
Between this and GWT (and the Google Wave app they are going to open source), I'm getting pretty interested in Java and using tools like GWT to just generate all of the javascript etc. It almost sounds like it will be /easier/ than Ruby on Rails.

Is that crazy?

No I don't think so ... I actually found this library as I was watching the GoogleIO Wave Keynote. When I saw what the wave team did with GWT, compiling Java => Javascript became a viable option in my mind. Before the demo, it had always been a mystery to me as to why anyone would want to use such an absurd amount of abstraction.
In Vaadin you do not have to compile Java to JavaScript. Instead you are using native Java on server-side. GWT is used only for compiling "client-side thinclient". This is only needed when you want to add more widets to Vaadin - if you are happy with the default widgets you do not have to worry about GWT/browsers/compilation.
Guys, please check out the server-side features too, Vaadin is not just client-side GWT on stereoids. Having server-side framework too means that building applications is easier than with plain GWT.
One thing that I like about the company. It is very clear that the framework is free. (Apache License). But they offer some interesting services (Theme Design, Usability Design, Solution Sprint, Proof of Concept, Project KickStart, Quality Assurance) http://vaadin.com/services

I think it make a lot of sense for a company to hire these services because some of these areas require a level of specialization that is very difficult to find. For example a traditional web designer needs to understand the tool paradigm to use it effectively.

On the other hand if you are small company you still can use the framework. (The only thing I am not convinced is about the server-side idea)