On Mon, Aug 9, 2010 at 10:34 PM, Jörg von Frantzius
<[email protected]> wrote:
> For example, with Vaadin any custom click-listener has to be executed on the
> server, right?

Wrong.

And also what do you mean by that in general? If you click on a button
in a GWT, it triggers Google-RPC, then transfers some JSON to the
server, then does the thing, talks back and you got a result through
all this Rube Goldberg. So what kind of "click-listener" you're
talking about other, if not only working with a components? If yes,
then components are plain GWT and will run your JavaScript stuff right
in your browser as same as ExtJS or SmartGWT or GWT... You can also
define fields non-immediate and then minimize calls to the server.

> That likely means a lot more requests will be sent during typical
> interaction, and so performance depends highly on the network connection.

For the status update yes: if you change some value somewhere, the
server should know and update the status. You're gonna do exactly the
same with GWT. *Manually*.

> Even given a good network connection, there always is a latency of a couple
> of milliseconds, which will always prevent a Vaadin UI from reaching the
> subjective "snappiness" of a GWT UI.

I am not sure you're right here. If you want to preserve all the bits
in your app in order to stay exactly where you've been right after
page refresh or history change (and that's should be this way, by the
way), then you need to save to the session all your GUI bits in GWT as
well. It is not any snappy, when you have 5 windows opened, certain
tabs selected and certain values entered, but then one single refresh
kills everything.

Personally I think that all this HTML stuff is not the answer, even
HTML5, WebSocket blablabla. GUI should be something like Java Swing
(not working properly as well) and stay standalone. Java Swing
actually IS the answer, but it works good only on strictly controlled
networks, i.e. somewhere at Enterprise LAN. Outside in the wild
internet forest — basically not the best at all.

> Personally I find this a disappointing outlook, after having worked a fair
> bit with GWT in Magnolia 4.3, and with absolutely great results.

We using Vaadin a lot for... uhm... Liferay. :) And people loving it.
Developers also loving it, because plain GWT is total crap actually:
it does not supports all Java, it requires you to make lots of type
conversions, mess up with RPC, have intermediate objects, have a hell
to include something new, do a lot of manual things etc. So things
that should be easy, in GWT are very difficult to do. Also that ugly
re-compilation... Vaadin comes with pre-compiled stuff, while in GWT
you have to wait one minute (or more) to let it bake a .war file for
you, which is fatty (especially if it is Isomorphic SmartGWT).

In fact, the best API ever among all GWT-based stuff is Vaadin. The
most simple, clear and sophisticated. You code just like a Swing. The
most ugly among them is actually Isomorphic SmartGWT. I literally hate
that library and all its guts, but have to deal due some projects
(still) using it. I am not talking about a sack of bugs it has, but I
am talking about the process of development.

> GWT would give Magnolia an
> absolutely great competitive edge.

Vaadin *is* GWT. The only thing that it does more than just UI
rendering. While this everything else is totally automated, in a pure
GWT you should do it yourself, so I think it sucks, time wise. That's
why Vaadin wins here.

> With Google having bought Instantiations' GWTDesigner (as somebody on this
> list already noted), IDE support is likely to become just great for free as
> well.

GWTDesigner is still quite poor in my opinion. This one is better at
least because it is free:
http://bootdiskrevolution.com/gwtlab-1.0.2/Gwtlab.html :-)

-- 
Kind regards, BM

Things, that are stupid at the beginning, rarely ends up wisely.

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------

Reply via email to