Live data from Hacker News

Vaadin - GWT with a skinnable UI.

vaadin.com

21–30 of 31 posts

Re: Vaadin - GWT with a skinnable UI.

#21
post #3

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.

(DOM structures in) Vaadin has been designed to be easily themeable. Just look at the iTunes Mockup example:

http://demo.vaadin.com/VaadinTunesLayout/

Re: Vaadin - GWT with a skinnable UI.

#22
post #14

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.

Re: Vaadin - GWT with a skinnable UI.

#23

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.

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, ...

Re: Vaadin - GWT with a skinnable UI.

#24
post #9

Earlier quoted context omitted.

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...

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.

Re: Vaadin - GWT with a skinnable UI.

#26
post #24

Earlier quoted context omitted.

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...

Re: Vaadin - GWT with a skinnable UI.

#27
post #26
post #24

Earlier quoted context omitted.

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.

Re: Vaadin - GWT with a skinnable UI.

#28

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.

yeah, I was actually just noticing this. I would lean more towards the 100% client-side + RPC.

Re: Vaadin - GWT with a skinnable UI.

#29
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)

Re: Vaadin - GWT with a skinnable UI.

#30
post #26

Earlier quoted context omitted.

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.
Post reply on HN