Home » Eclipse Projects » Remote Application Platform (RAP) » Comparison RAP vs GWT-EXT
| Comparison RAP vs GWT-EXT [message #85674] |
Wed, 30 April 2008 15:26  |
 Arpit Desai
Messages: 25
Registered: July 2009 |
Junior Member |
|
|
Hey folks,
I am just throwing out this discussion to see the views of people
working with RAP, understand better the positives of RAP / Eclipse
development from people who have already encountered challenges.
The point of discussion is RAP vs GWT-EXT (for those who do not know
this please visit http://gwt-ext.com/ for more info). Let's start with
some positives of gwt-ext libraries:
1) excellent looking and behaving widgets on user's browser. this is
because of the matured extjs libraries that it uses to render the UI
2) quick response times, since JS is running on client side (event
processing is done of client side)
3) Clean APIs to work with chucked Data loading, auto-completion of
text, drag-drop, etc. This is thanks to GWT mainly who have written the
APIs specific to web2.0 use cases. People on the new websites expect
unusual things like dynamic help, intuitive text suggestion, etc. The
GWT libraries do a great job at understanding these use case and
providing right UI components with right APIs to provide your
implementation.
And many more, please feel free to Add. Now let's talk about RAP. One of
the main questions I have is
1) Why does RAP do the event-processing on Server-side ? Is it because
RAP is tightly coupled with Eclipse framework and making remote calls to
eclipse bundles/runtimes was not intended?
2) Why does RAP tie-up with qx on the front-end library? Honestly, no
matter how smart/cool the technology is, if it does not present well to
the end-user, the whole purpose gets defeated. Qx may do the job as a
proof of concept but RAP should have been designed in a way to make it
easy to choose own client side JS libraries. As a simple business-case
you would win a lot more users. Any one agrees with me ? Differs, please
explain?
3) RAP allows single sourcing with RCP. Excellent job and thats its edge
among its competitors. However, if we are to take RAP to the next
level, as in an industry leader than it needs to compete well with the
other Ajax (purely Web domain) technologies. So, let's say for a small
business owner if the primary UI is web and he/she wants to upgrade it
to web 2.0 for the customers/partners and wants to use RAP. He should be
able to do this and come up with UI which blows the customer away. The
reason to pick RAP here would be to have the flexibility to use the same
UI code and prepare an RCP for other set of users. Something which GWT
or others do not offer.
Please throw in your comments and suggestions. Also, bear in mind I am
still very much in awe with RAP :)
Thanks,
Arpit
|
|
|
| Re: Comparison RAP vs GWT-EXT [message #85690 is a reply to message #85674] |
Thu, 01 May 2008 07:21  |
Eclipse User |
|
|
|
Originally posted by: anupgokhale.rediffmail.com
>
> 2) Why does RAP tie-up with qx on the front-end library? Honestly, no
> matter how smart/cool the technology is, if it does not present well to
> the end-user, the whole purpose gets defeated. Qx may do the job as a
> proof of concept but RAP should have been designed in a way to make it
> easy to choose own client side JS libraries. As a simple business-case
> you would win a lot more users. Any one agrees with me ? Differs, please
> explain?
>
I fully agree with this point. But I am given to understand that in the
Ganymede release RAP will provide a functionality to allow to hook up
with other libraries and not be tied to just QX. But my gut feeling is
that this functionality wont be supported out-of-the-box and will
require the programmer to do some heavy weight coding. Any any RAP
project team members throw light on this?
Regards,
Anup
|
|
|
| Re: Comparison RAP vs GWT-EXT [message #85719 is a reply to message #85674] |
Thu, 01 May 2008 09:26 |
Benjamin Muskalla
Messages: 237
Registered: July 2009 |
Senior Member |
|
|
Hi Arpit,
these are some good points. Let me try to lighten up some things here.
See comments inline.
Arpit Desai wrote:
> Hey folks,
>
<snip>
>
> 1) Why does RAP do the event-processing on Server-side ? Is it because
> RAP is tightly coupled with Eclipse framework and making remote calls to
> eclipse bundles/runtimes was not intended?
I don't really get your last statement but anyway. One of the advantages
of RAP is that you can use everything what you already know or what's
available in the java space. Think of 3rd party librarys like BIRT
(reporting), Hibernate (ORM) or other things. When doing
cross-compilation like GWT does you are limited to the things GWT can
translate into javascript (think of simple Java Runtime Features).
Another advantage is the reuse of UI code. While in GWT or other
frameworks you need to learn another UI library/widget api in RAP you
can use the same widgets and the same API every RCP developer knows
already. This is also one of the big advantages that you can reuse your
knowledge.
>
> 2) Why does RAP tie-up with qx on the front-end library? Honestly, no
> matter how smart/cool the technology is, if it does not present well to
> the end-user, the whole purpose gets defeated. Qx may do the job as a
> proof of concept but RAP should have been designed in a way to make it
> easy to choose own client side JS libraries. As a simple business-case
> you would win a lot more users. Any one agrees with me ? Differs, please
> explain?
The tie-up happend to concentrate on the fact the we need to run big
applications on top of RAP without problems. As we saw the need from the
community to use other client-side technologies (other JS Framework,
Flash/Flex, Silverlight, etc) we decided to split up the server-side
implementation from the client side. This resulted in a host bundle
(rwt) while the qooxdoo implementation is now a fragment. This split
will be available in the next milestone (M4) next week. This split
implies that everyone is now (technically) able to provide their own
client-side implementation to plug into RAP. The biggest problems in
this area are: time and resouces. The RAP team in it's current formation
is just to able to deal with different implementations while still care
about the core. This means that it's the turn for the community to come
up with other implementations. Just to pick up your example: it's
possible to write an client-side representation which uses ExtJS instead
of Qooxdoo. While there may be licence-related problems in hosting this
on eclipse.org (maybe Jochen can clearify this) nobody keeps you back to
open a new project on sf.net or Google code to do so. The RAP team would
be happy to help in any form (eg. to soften the boundaries of the
current split). I think an alternative implementation would find many
adopters if you're willing to spend time on such an implementation. Take
care is it looks easier then it is as you need to follow the SWT specs
in a 100% compatible way to get the workbench run on top of it.
>
> 3) RAP allows single sourcing with RCP. Excellent job and thats its edge
> among its competitors. However, if we are to take RAP to the next
> level, as in an industry leader than it needs to compete well with the
> other Ajax (purely Web domain) technologies. So, let's say for a small
> business owner if the primary UI is web and he/she wants to upgrade it
> to web 2.0 for the customers/partners and wants to use RAP. He should be
> able to do this and come up with UI which blows the customer away. The
> reason to pick RAP here would be to have the flexibility to use the same
> UI code and prepare an RCP for other set of users. Something which GWT
> or others do not offer.
I don't really see the questions here :) But regarding "UI to blow the
customer away", just take a look at
http://rapblog.innoopract.com/2008/03/would-you-believe-this -is-browser-based.html
>
> Please throw in your comments and suggestions. Also, bear in mind I am
> still very much in awe with RAP :)
Thanks for the comments. I hope i could clearify most of your problems :)
Greets
Benny
>
> Thanks,
>
> Arpit
|
|
|
| Re: Comparison RAP vs GWT-EXT [message #85866 is a reply to message #85674] |
Sat, 03 May 2008 08:53 |
| Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi,
see answers below.
Ciao
Frank
-----Ursprüngliche Nachricht-----
Von: Arpit Desai [mailto:arpitdesai23@gmail.com]
Bereitgestellt: Mittwoch, 30. April 2008 17:26
Bereitgestellt in: eclipse.technology.rap
Unterhaltung: Comparison RAP vs GWT-EXT
Betreff: Comparison RAP vs GWT-EXT
1) Why does RAP do the event-processing on Server-side ? Is it because
RAP is tightly coupled with Eclipse framework and making remote calls to
eclipse bundles/runtimes was not intended?
RAP was created to provide RCP developers a possibility to bring (at
least parts of) their RCP applications to the web without the need to
step deep into the low-level web-technologies. The reason for this is
cost reduction by reuse of knowlege and code. Therefore we have chosen
the technical approach that provides the highest possible reusability -
a thin client with a rich widget set and a stateful serverside on top of
OSGi, reusing the eclipse workbench paradigm. If you want/need to have a
more client-centric approach you may have a look into the e4 mailinglist
where other approaches of 'bringing eclipse to the web' should be
discussed.
2) Why does RAP tie-up with qx on the front-end library? Honestly, no
matter how smart/cool the technology is, if it does not present well to
the end-user, the whole purpose gets defeated. Qx may do the job as a
proof of concept but RAP should have been designed in a way to make it
easy to choose own client side JS libraries. As a simple business-case
you would win a lot more users. Any one agrees with me ? Differs, please
explain?
Maybe there is a misunderstanding of the RAP architecture here. Qooxdoo
is a powerfull standalone clientside javascript widget library that was
chosen by RAP as client side representation. I don't think that RAP
would have been possible without having qooxdoo as clientside solution
by the time when we've started. Naturally going the first steps RWT did
not seperate the code from the low-level stuff in a clean manner. So
currently we are in the process of moving code that is coupled to the
client-side library into a fragment. If we are finished with this
different fragments may provide different client-side solutions (in the
future there may be a mechanism that can choose the best fitting
one...). But to avoid any misunderstanding, we are completly satisfied
with qooxdoo as javascript solution - our efforts are focused on non
javascript solutions like flash, silverlight etc.
3) RAP allows single sourcing with RCP. Excellent job and thats its edge
among its competitors. However, if we are to take RAP to the next
level, as in an industry leader than it needs to compete well with the
other Ajax (purely Web domain) technologies. So, let's say for a small
business owner if the primary UI is web and he/she wants to upgrade it
to web 2.0 for the customers/partners and wants to use RAP. He should be
able to do this and come up with UI which blows the customer away. The
reason to pick RAP here would be to have the flexibility to use the same
UI code and prepare an RCP for other set of users. Something which GWT
or others do not offer.
This should be mostly covered by my answer to 1). Just one addition: RAP
is part of e4, so it won't be a doubled-tracked web-development stream
in eclipse - the solutions which are about to be developed there should
not compete with RAP they should integrate. Unfortunately we are
currently too busy to do a lot for this discussion, since we are
adopting to the 3.4 codebase - which is a really lot of work to do. We
hardly can keep our own lists going, but this will change soon, as the
3.4 codebase now seems to run :-)
Please throw in your comments and suggestions. Also, bear in mind I am
still very much in awe with RAP :)
Thanks,
Arpit
|
|
|
| Re: Comparison RAP vs GWT-EXT [message #85910 is a reply to message #85719] |
Sun, 04 May 2008 15:46 |
| Eclipse User |
|
|
|
Originally posted by: juergen.schlierf.eu
I saw these very impressive screenshots on http://rapblog.innoopract.com/2008/03/would-you-believe-this -is-browser-based.html. I'm looking forward to see the first online demo of teamCRM.
But I guess that some widgets like collapsible buttons, a calendar supporting drag & drop or the nice ribbons are written by CAS and will not be part of RAP 1.1 or qooxdoo 0.8. Are there plans to contribute these widgets to RAP?
Regards,
Jürgen
Benjamin Muskalla schrieb:
> Hi Arpit,
>
> these are some good points. Let me try to lighten up some things here.
> See comments inline.
>
>
> Arpit Desai wrote:
>> Hey folks,
>>
> <snip>
>>
>> 1) Why does RAP do the event-processing on Server-side ? Is it because
>> RAP is tightly coupled with Eclipse framework and making remote calls
>> to eclipse bundles/runtimes was not intended?
> I don't really get your last statement but anyway. One of the advantages
> of RAP is that you can use everything what you already know or what's
> available in the java space. Think of 3rd party librarys like BIRT
> (reporting), Hibernate (ORM) or other things. When doing
> cross-compilation like GWT does you are limited to the things GWT can
> translate into javascript (think of simple Java Runtime Features).
> Another advantage is the reuse of UI code. While in GWT or other
> frameworks you need to learn another UI library/widget api in RAP you
> can use the same widgets and the same API every RCP developer knows
> already. This is also one of the big advantages that you can reuse your
> knowledge.
>>
>> 2) Why does RAP tie-up with qx on the front-end library? Honestly, no
>> matter how smart/cool the technology is, if it does not present well
>> to the end-user, the whole purpose gets defeated. Qx may do the job as
>> a proof of concept but RAP should have been designed in a way to make
>> it easy to choose own client side JS libraries. As a simple
>> business-case you would win a lot more users. Any one agrees with me ?
>> Differs, please explain?
> The tie-up happend to concentrate on the fact the we need to run big
> applications on top of RAP without problems. As we saw the need from the
> community to use other client-side technologies (other JS Framework,
> Flash/Flex, Silverlight, etc) we decided to split up the server-side
> implementation from the client side. This resulted in a host bundle
> (rwt) while the qooxdoo implementation is now a fragment. This split
> will be available in the next milestone (M4) next week. This split
> implies that everyone is now (technically) able to provide their own
> client-side implementation to plug into RAP. The biggest problems in
> this area are: time and resouces. The RAP team in it's current formation
> is just to able to deal with different implementations while still care
> about the core. This means that it's the turn for the community to come
> up with other implementations. Just to pick up your example: it's
> possible to write an client-side representation which uses ExtJS instead
> of Qooxdoo. While there may be licence-related problems in hosting this
> on eclipse.org (maybe Jochen can clearify this) nobody keeps you back to
> open a new project on sf.net or Google code to do so. The RAP team would
> be happy to help in any form (eg. to soften the boundaries of the
> current split). I think an alternative implementation would find many
> adopters if you're willing to spend time on such an implementation. Take
> care is it looks easier then it is as you need to follow the SWT specs
> in a 100% compatible way to get the workbench run on top of it.
>
>>
>> 3) RAP allows single sourcing with RCP. Excellent job and thats its
>> edge among its competitors. However, if we are to take RAP to the
>> next level, as in an industry leader than it needs to compete well
>> with the other Ajax (purely Web domain) technologies. So, let's say
>> for a small business owner if the primary UI is web and he/she wants
>> to upgrade it to web 2.0 for the customers/partners and wants to use
>> RAP. He should be able to do this and come up with UI which blows the
>> customer away. The reason to pick RAP here would be to have the
>> flexibility to use the same UI code and prepare an RCP for other set
>> of users. Something which GWT or others do not offer.
> I don't really see the questions here :) But regarding "UI to blow the
> customer away", just take a look at
> http://rapblog.innoopract.com/2008/03/would-you-believe-this -is-browser-based.html
>
>
>>
>> Please throw in your comments and suggestions. Also, bear in mind I am
>> still very much in awe with RAP :)
> Thanks for the comments. I hope i could clearify most of your problems :)
>
> Greets
> Benny
>>
>> Thanks,
>>
>> Arpit
|
|
|
| Re: Comparison RAP vs GWT-EXT [message #86000 is a reply to message #85910] |
Mon, 05 May 2008 16:20 |
| Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi,
as far as I know it's planned to commit custom widgets like the ribbon
bar for example to the sandbox in the RAP CVS.
Ciao
Frank
-----Ursprüngliche Nachricht-----
Von: Jürgen Schlierf [mailto:juergen@schlierf.eu]
Bereitgestellt: Sonntag, 4. Mai 2008 17:46
Bereitgestellt in: eclipse.technology.rap
Unterhaltung: Comparison RAP vs GWT-EXT
Betreff: Re: Comparison RAP vs GWT-EXT
I saw these very impressive screenshots on
http://rapblog.innoopract.com/2008/03/would-you-believe-this -is-browser-
based.html. I'm looking forward to see the first online demo of teamCRM.
But I guess that some widgets like collapsible buttons, a calendar
supporting drag & drop or the nice ribbons are written by CAS and will
not be part of RAP 1.1 or qooxdoo 0.8. Are there plans to contribute
these widgets to RAP?
Regards,
Jürgen
Benjamin Muskalla schrieb:
> Hi Arpit,
>
> these are some good points. Let me try to lighten up some things here.
> See comments inline.
>
>
> Arpit Desai wrote:
>> Hey folks,
>>
> <snip>
>>
>> 1) Why does RAP do the event-processing on Server-side ? Is it
>> because RAP is tightly coupled with Eclipse framework and making
>> remote calls to eclipse bundles/runtimes was not intended?
> I don't really get your last statement but anyway. One of the
> advantages of RAP is that you can use everything what you already know
> or what's available in the java space. Think of 3rd party librarys
> like BIRT (reporting), Hibernate (ORM) or other things. When doing
> cross-compilation like GWT does you are limited to the things GWT can
> translate into javascript (think of simple Java Runtime Features).
> Another advantage is the reuse of UI code. While in GWT or other
> frameworks you need to learn another UI library/widget api in RAP you
> can use the same widgets and the same API every RCP developer knows
> already. This is also one of the big advantages that you can reuse
> your knowledge.
>>
>> 2) Why does RAP tie-up with qx on the front-end library? Honestly, no
>> matter how smart/cool the technology is, if it does not present well
>> to the end-user, the whole purpose gets defeated. Qx may do the job
>> as a proof of concept but RAP should have been designed in a way to
>> make it easy to choose own client side JS libraries. As a simple
>> business-case you would win a lot more users. Any one agrees with me
?
>> Differs, please explain?
> The tie-up happend to concentrate on the fact the we need to run big
> applications on top of RAP without problems. As we saw the need from
> the community to use other client-side technologies (other JS
> Framework, Flash/Flex, Silverlight, etc) we decided to split up the
> server-side implementation from the client side. This resulted in a
> host bundle
> (rwt) while the qooxdoo implementation is now a fragment. This split
> will be available in the next milestone (M4) next week. This split
> implies that everyone is now (technically) able to provide their own
> client-side implementation to plug into RAP. The biggest problems in
> this area are: time and resouces. The RAP team in it's current
> formation is just to able to deal with different implementations while
> still care about the core. This means that it's the turn for the
> community to come up with other implementations. Just to pick up your
> example: it's possible to write an client-side representation which
> uses ExtJS instead of Qooxdoo. While there may be licence-related
> problems in hosting this on eclipse.org (maybe Jochen can clearify
> this) nobody keeps you back to open a new project on sf.net or Google
> code to do so. The RAP team would be happy to help in any form (eg. to
> soften the boundaries of the current split). I think an alternative
> implementation would find many adopters if you're willing to spend
> time on such an implementation. Take care is it looks easier then it
> is as you need to follow the SWT specs in a 100% compatible way to get
the workbench run on top of it.
>
>>
>> 3) RAP allows single sourcing with RCP. Excellent job and thats its
>> edge among its competitors. However, if we are to take RAP to the
>> next level, as in an industry leader than it needs to compete well
>> with the other Ajax (purely Web domain) technologies. So, let's say
>> for a small business owner if the primary UI is web and he/she wants
>> to upgrade it to web 2.0 for the customers/partners and wants to use
>> RAP. He should be able to do this and come up with UI which blows the
>> customer away. The reason to pick RAP here would be to have the
>> flexibility to use the same UI code and prepare an RCP for other set
>> of users. Something which GWT or others do not offer.
> I don't really see the questions here :) But regarding "UI to blow the
> customer away", just take a look at
> http://rapblog.innoopract.com/2008/03/would-you-believe-this -is-browse
> r-based.html
>
>
>>
>> Please throw in your comments and suggestions. Also, bear in mind I
>> am still very much in awe with RAP :)
> Thanks for the comments. I hope i could clearify most of your problems
> :)
>
> Greets
> Benny
>>
>> Thanks,
>>
>> Arpit
|
|
|
Goto Forum:
Current Time: Sat Jul 13 02:37:08 GMT 2024
Powered by FUDForum. Page generated in 0.04609 seconds |
] 
Search
Help
Register
Login
Home
