Hi Bogdan,
please see my comments below...
On 13.08.2010 10:22, BM wrote:
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.
Hm, maybe not entirely wrong. As an example, if you look at the Vaadin
table demo <http://demo.vaadin.com/sampler#TableColumnHeaders> and
simply change the selection (click on items), you'll see one request per
change of selection in firebug, probably for redrawing the status
message showing the current selection. The same goes for practically
anything you can click on in the demo (trees, checkboxes, radio buttons,
selection lists, dropdowns, menus, tabs), it's one request per click
everywhere. The only exception to this rule I found was the displaying
of context menus.
You'll also notice that redraw of the selection in the table happens
with a noticeable time-lag (maybe unless you live in Norway near the
server), same in the tree demo. I've been told that the selection is in
fact redrawn before the request is issued, but then I wonder where the
time-lag comes from if it's not due to the request.
This all may be due to the Vaadin online demo not having been optimized
properly yet, though, I don't know.
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?
Suppose you want UI behaviour that at least I'd expect from a UI with
good usability, such as:
* enabling certain buttons only if something is selected in a list
(and disabling them again once selection is empty)
* update status messages, such as "x items selected", or having more
elaborate status messages that Vaadin cannot provide out of the
box, e.g. "5 items selected (2 yellow items, 3 green items)"
* functionalities like "select all" (in a list), or "select all
green items"
* displaying details of the current selection in a paging table; no
problem in GWT to completely cache those 50 items being displayed,
so details can be rendered without further requests to the sever
It's easy or even natural to do these custom event handlers in GWT
without incurring any server requests. With current Vaadin, they all
seem to require server requests. If Vaadin wants to shift these things
to the client, they'll need to provide generic abstractions of these
use-cases and implement them in their GWT code. Even if they do,
there'll always be that new requirement that does not fit in there.
Now imagine the users of a CMS sitting behind a slow connection, or one
with high latency at least (which is the case with globally operating
companies). Each time they click in a list to see details, or select
items for further processing, they'll have to wait for the server to
respond before the UI gets updated. As a potential user I'd find that
very, unpleasant, because selecting items in lists is a highly frequent
user interaction.
In effect, with slow network connections, Vaadin without further
optimization in GWT code seems to be a no-go. But then maybe Vaadin is
just starting to optimize these things, so eventually use-cases like
this will in the not so distant future require less requests. I do hope so.
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*.
The server doesn't really need to know which item the user has selected
in the list, until she invokes some action to trigger further processing
of that item. If I got you right here.
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.
From my experience, the last one hasn't been a common requirement from
clients. I your client has advanced requirements like that, then maybe
some advanced approach like http://www.sencha.com/examples/desktop.html
would be the right answer (he simply shouldn't hit F5 in there, though :)
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,
From my experience, GWT RPC works efficiently, transparently and
reliably. We also used gilead to serialize our JPA entities through
Google RPC, so no intermediate objects here.
Of course GWT is not like plain Java, but then it's so much better than
hand-writing Javascript. And to me it looks like one will have to deal
with GWT in Vaadin as well when it comes to optimization of use-cases
for slow network connections.
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
To be honest, Java Swing was one of the most horrible programming
experiences I made back in the late 90ies ;-)
But then I know what you mean, and I'd see SWT as a good example here.
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 :-)
Regards,
Jörg
--
Dipl. inf. Jörg von Frantzius, System Architect
Email mailto:[email protected]
Phone +49 30 283921-318
Fax +49 30 283921-29
Aperto AG - In der Pianofabrik
Chausseestraße 5, D-10115 Berlin-Mitte
Web http://www.aperto.de
HRB 77049, AG Berlin Charlottenburg
Vorstand: Dirk Buddensiek
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
