Hope that those arguments would not make the difference when you will have
to decide. Please see my following responses inline :

On Tue, Oct 20, 2009 at 9:24 AM, David <[email protected]> wrote:


> GWT is being pushed as THE tool for AJAX development. The RPC part is
> fundamental to the AJAX experience yet it does not scale very well
> beyond a Hello World or Twitter client.


This is a subjective feeling. We build every day mission critical and ERP
applications that use GWT and the RPC API without any scalability problem.
Just don't flood your server with large payload requests.


> And for the Twitter client one
> could argue that you really need a standard implementation for push
> messaging instead.
>

You can use Comet, there are tons of XMPP implementation (Emite), etc ...
GWT could not support natively all the particularities of every single
messaging protocol in the world. If the objective is to cover the scope of
the JDK Framework, it won't make it.
gwt-user should stay small and efficient (although I would love to see
something like RX Framework
http://themechanicalbride.blogspot.com/2009/07/introducing-rx-linq-to-events.html).




> RPC is really bad with object graphs. If you have a tree or linked
> list you don't need a lot of nodes to see it crash with a stack
> overflow. Sending larger payloads is also the best way to make the app
> stall.
>

Do you have any precise use case or failed test case ? Have you send any
issue ?
We all repeat all the day long that RPC is not RMI and the client side is
Javascript. One should avoid to send large payload.
This is an unfair argument (although  many things can be done in terms of
lightweight collections).


> The current RPC is just fundamentally broken in the implementation
> that maybe it does not deserve to be in GWT 2.0 either.
>

Disagree with that.


>
> I do not see any need to move my code to GWT 2.0 if the RPC is not
> fixed. The new UI features are nice to have but not critical to the
> applications. The JS optimisations do not make a lot of difference
> since our UI's are not really CPU bound. The new widgets or declartive
> UI part is nice, but we can do without - a faster table/tree
> implementation in the trunk would be very usefull (the incubator seems
> to be dead ?) since it is the main reason why people select ExtGWT or
> other GWT widget sets (which do not really use GWT the way they
> should).
>

Now you are complaining about GWT in general. All the features you point out
are huge enhancements.
CodeSplitting is a great evolution toward better scalability and
performance.
GWT has so many things to do that they must prioritize.
Taking into account the foundation (compiler optims, runAsync, performances,
browser support, ...)  before creating sexy and flashy widgets framework is
just about good sense.


>
> The only thing that is really missing in GWT is a decent RPC that can
> be trusted to just work.
>

What is for you a "decent RPC" ?


> David

--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---

Reply via email to