GWT vs YUI
830 views
Skip to first unread message
Gene Ash
Dec 4, 2007, 6:52:27 AM12/4/07
to Google Web Toolkit
Hi,
We have been using GWT as the framework in our project for quite some
time. Now we are considering migrating the application to YUI due to
the following reasons:
1. Richness of controls available
2. Simpler skinning model (developing custom CSS to meet the project
styles)
3. More open - no complicated Java-to-JS tool to deal with, if we
really get stuck
4. flexible separation between AJAX features and server-side
templates
5. fairly good object-oriented JavaScript - using proto-types and
super-classes
But I am personally not clear as to which framework is better in the
long run. So I thought of getting your views in this regard. Please
share your views/suggestions. Thanks.
Kind Regards,
Gene
We have been using GWT as the framework in our project for quite some
time. Now we are considering migrating the application to YUI due to
the following reasons:
1. Richness of controls available
2. Simpler skinning model (developing custom CSS to meet the project
styles)
3. More open - no complicated Java-to-JS tool to deal with, if we
really get stuck
4. flexible separation between AJAX features and server-side
templates
5. fairly good object-oriented JavaScript - using proto-types and
super-classes
But I am personally not clear as to which framework is better in the
long run. So I thought of getting your views in this regard. Please
share your views/suggestions. Thanks.
Kind Regards,
Gene
Elias Balasis
Dec 4, 2007, 6:59:37 AM12/4/07
to Google-We...@googlegroups.com
I personally believe GWT is best case scenarion for people that refuse or want to avoid the quirks of HTML+JavaScript
It is my personal choice because it allows me to program a web application's UI the same way I program a standalone application (Swing like or SWT like)
Also programming with a more familiar model requires less time. Development times and related costs are thus reduced.
Extensibility is also another additional benefit. Being able to create custom components (either from scratch or from others) adds flexibility.
I would suggest creating GWT wrappers of the YUI components. I haven't done something similar (yet) but I believe it is worth the effort plus I wouldn't expect it to be very hard.
It is my personal choice because it allows me to program a web application's UI the same way I program a standalone application (Swing like or SWT like)
Also programming with a more familiar model requires less time. Development times and related costs are thus reduced.
Extensibility is also another additional benefit. Being able to create custom components (either from scratch or from others) adds flexibility.
I would suggest creating GWT wrappers of the YUI components. I haven't done something similar (yet) but I believe it is worth the effort plus I wouldn't expect it to be very hard.
obesga
Dec 4, 2007, 7:59:45 AM12/4/07
to Google Web Toolkit
GWT-Ext will help you ?
http://code.google.com/p/gwt-ext/
Oskar
On 4 dic, 12:59, "Elias Balasis" <eliasbala...@gmail.com> wrote:
> I personally believe GWT is best case scenarion for people that refuse or
> want to avoid the quirks of HTML+JavaScript
> It is my personal choice because it allows me to program a web application's
> UI the same way I program a standalone application (Swing like or SWT like)
> Also programming with a more familiar model requires less time. Development
> times and related costs are thus reduced.
> Extensibility is also another additional benefit. Being able to create
> custom components (either from scratch or from others) adds flexibility.
> I would suggest creating GWT wrappers of the YUI components. I haven't done
> something similar (yet) but I believe it is worth the effort plus I wouldn't
> expect it to be very hard.
>
http://code.google.com/p/gwt-ext/
Oskar
On 4 dic, 12:59, "Elias Balasis" <eliasbala...@gmail.com> wrote:
> I personally believe GWT is best case scenarion for people that refuse or
> want to avoid the quirks of HTML+JavaScript
> It is my personal choice because it allows me to program a web application's
> UI the same way I program a standalone application (Swing like or SWT like)
> Also programming with a more familiar model requires less time. Development
> times and related costs are thus reduced.
> Extensibility is also another additional benefit. Being able to create
> custom components (either from scratch or from others) adds flexibility.
> I would suggest creating GWT wrappers of the YUI components. I haven't done
> something similar (yet) but I believe it is worth the effort plus I wouldn't
> expect it to be very hard.
>
Elias Balasis
Dec 4, 2007, 8:14:08 AM12/4/07
to Google-We...@googlegroups.com
WOW
A complete collection of rich UI components. I wasn't aware of this.
Thanks.
A complete collection of rich UI components. I wasn't aware of this.
Thanks.
Charlie Collins
Dec 4, 2007, 11:02:13 AM12/4/07
to Google Web Toolkit
GWT and YUI are two completely different things, both are pretty good
at what it is they do, but they don't do the same thing at all.
GWT is a toolkit for building AJAX client apps starting from a
statically typed compiled language, Java. With GWT you build not only
your UI, but also your controller, your model, your entire app, and it
all "lives" on the client. Then when you need to talk to the server to
get/sync/update data ,a serialization mechanism for Java backends is
provided too (you can also "talk" to other server resources as well).
GWT gives you all the inheritance, tooling, testing and so on support
that comes with Java, and a starting point for building your entire
app in the "rich" desktop vein. When you use GWT in the canonical
fashion, you don't even care that your app ends up as JavaScript, you
never have to worry about that (you still have the freedom to get into
that level if you want, and you could quite easily, for example, wrap
a lot of the UI stuff from YUI as a GWT module using JSNI).
YUI is a pure JavaScript client library. Also impressive, but a
different approach. I suppose YUI could be used as an alternative, to
build your entire app on the client (back to controller and model
there as well, not just UI), leaving the server side up to any other
XHR setup, but that's definitely a different tack.
I am not saying one is better than the other, but I think for building
a total application GWT makes more sense in my mind. YUI seems more
appropriate to add a widget to an existing app, or as something you
might want to incorporate in various other ways, but not build
entirely from (but then again, personally, I wish to avoid directly
having to work with JavaScript when possible, thats one of the things
I like about GWT, maybe it's me). Also, I know you CAN build entirely
from YUI, or pure JavaScript, just saying, I prefer the static
approach, starting from Java and generating JavaScript, and all the
benefits that offers.
at what it is they do, but they don't do the same thing at all.
GWT is a toolkit for building AJAX client apps starting from a
statically typed compiled language, Java. With GWT you build not only
your UI, but also your controller, your model, your entire app, and it
all "lives" on the client. Then when you need to talk to the server to
get/sync/update data ,a serialization mechanism for Java backends is
provided too (you can also "talk" to other server resources as well).
GWT gives you all the inheritance, tooling, testing and so on support
that comes with Java, and a starting point for building your entire
app in the "rich" desktop vein. When you use GWT in the canonical
fashion, you don't even care that your app ends up as JavaScript, you
never have to worry about that (you still have the freedom to get into
that level if you want, and you could quite easily, for example, wrap
a lot of the UI stuff from YUI as a GWT module using JSNI).
YUI is a pure JavaScript client library. Also impressive, but a
different approach. I suppose YUI could be used as an alternative, to
build your entire app on the client (back to controller and model
there as well, not just UI), leaving the server side up to any other
XHR setup, but that's definitely a different tack.
I am not saying one is better than the other, but I think for building
a total application GWT makes more sense in my mind. YUI seems more
appropriate to add a widget to an existing app, or as something you
might want to incorporate in various other ways, but not build
entirely from (but then again, personally, I wish to avoid directly
having to work with JavaScript when possible, thats one of the things
I like about GWT, maybe it's me). Also, I know you CAN build entirely
from YUI, or pure JavaScript, just saying, I prefer the static
approach, starting from Java and generating JavaScript, and all the
benefits that offers.
Arthur Kalmenson
Dec 4, 2007, 11:36:46 AM12/4/07
to Google Web Toolkit
Wow, thanks for the link to GWT-Ext. We'll have to integrate some of
those widgets into our own project! Thanks!
those widgets into our own project! Thanks!
Thos
Dec 4, 2007, 1:00:06 PM12/4/07
to Google Web Toolkit
If "in the long run" means that your code base is going to be
continued to be developed and maintained for a number of years with a
turn over of development staff I would argue that GWT is hands down
better.
A big part of managing a code base is being able to validate that it
is bug free, that when a developer changes it that they haven't
introduced bugs. With Java a large number of bugs can be eliminated at
compile time - that is the computer tells the developer that the code
base is not in a valid state and actually points them to the place in
the code where the inconsistency is. In JavaScript this is not
possible, so the developer has to run the code and test the software
to see whether or not their changes have broken anything, sometimes
tracing what's gone wrong to the code can be very tricky. As the code
base gets larger this gets more difficult / time consuming to do. Java
has a lot of other tools to aid the detection and elimination of bugs
by both statically analyzing the code base and also through designed
test systems for unit and system testing.
Another very important part of managing a code base is knowledge
transfer, over time the people looking after a code base change as the
developers move on to other projects, get promotions or leave the
company. The tooling that Java has means that it is much easier for
new developers to come up to speed with an existing code base.
Developing in Java tends to lead developers into making their code
structured, the more ad-hoc nature of JavaScript development means
that your developers really have to be very conscientious in their
development to get a similar level of structure.
continued to be developed and maintained for a number of years with a
turn over of development staff I would argue that GWT is hands down
better.
A big part of managing a code base is being able to validate that it
is bug free, that when a developer changes it that they haven't
introduced bugs. With Java a large number of bugs can be eliminated at
compile time - that is the computer tells the developer that the code
base is not in a valid state and actually points them to the place in
the code where the inconsistency is. In JavaScript this is not
possible, so the developer has to run the code and test the software
to see whether or not their changes have broken anything, sometimes
tracing what's gone wrong to the code can be very tricky. As the code
base gets larger this gets more difficult / time consuming to do. Java
has a lot of other tools to aid the detection and elimination of bugs
by both statically analyzing the code base and also through designed
test systems for unit and system testing.
Another very important part of managing a code base is knowledge
transfer, over time the people looking after a code base change as the
developers move on to other projects, get promotions or leave the
company. The tooling that Java has means that it is much easier for
new developers to come up to speed with an existing code base.
Developing in Java tends to lead developers into making their code
structured, the more ad-hoc nature of JavaScript development means
that your developers really have to be very conscientious in their
development to get a similar level of structure.
Reinier Zwitserloot
Dec 5, 2007, 6:30:58 AM12/5/07
to Google Web Toolkit
Personal opinion, but, FWIW:
mygwt.net is a much, much cooler and less buggy widget addon for GWT
compared to GWT-Ext.
And you can style it any way you want.
mygwt.net is a much, much cooler and less buggy widget addon for GWT
compared to GWT-Ext.
And you can style it any way you want.
Ping
Dec 5, 2007, 7:00:47 AM12/5/07
to Google Web Toolkit
I tried both myGwt and gwt-ext. Gwt-ext looks incredibly cool, but the
underlying JSNI stuff all around makes it a little difficult to
quickly get the feel of the api. Maybe if one knows ext already, it's
easier. Also, gwt-ext does not integrate directly with gwt rpc, that
extra stuff is other gwt-ext package that can be bought (never bought
it, altough I guess it would be a good buy if you are looking to
quickly integrate your app instead of writing your own generators and
stuff). I think mygwt is also alot lighter than gwt-ext, probably
because of the jsni differences.
I prefer the myGwt approach, it was easier for me to familiarize with
the code (by debugging the lib in action I even found a bug), and
Darrel (I think he is one of the maintainers or even the only
maintainer) seems that is working very hard to keep the lib up to
date. The bug I submitted was corrected a day or two after the
submission.
underlying JSNI stuff all around makes it a little difficult to
quickly get the feel of the api. Maybe if one knows ext already, it's
easier. Also, gwt-ext does not integrate directly with gwt rpc, that
extra stuff is other gwt-ext package that can be bought (never bought
it, altough I guess it would be a good buy if you are looking to
quickly integrate your app instead of writing your own generators and
stuff). I think mygwt is also alot lighter than gwt-ext, probably
because of the jsni differences.
I prefer the myGwt approach, it was easier for me to familiarize with
the code (by debugging the lib in action I even found a bug), and
Darrel (I think he is one of the maintainers or even the only
maintainer) seems that is working very hard to keep the lib up to
date. The bug I submitted was corrected a day or two after the
submission.
Rob Smith
Dec 5, 2007, 11:30:59 AM12/5/07
to Google Web Toolkit
I've been using gwt-ext for about 3 months now and I disagree with
Reinier's assesment. Gwt-Ext is based on Ext's widgets that have been
tried and tested by 1000's of users and are cross browser compatible.
The fews bugs that I did come across were in the wrapper
implementation that were easily fixed. Yes, I know it isn't native,
but I don't care, as the widgets work right of the box and I don't
have to worry about cross browser compatibility.
It is also very easy to skin the app. Just have a look at the Ext
forums for a list of additional themes.
Reinier's assesment. Gwt-Ext is based on Ext's widgets that have been
tried and tested by 1000's of users and are cross browser compatible.
The fews bugs that I did come across were in the wrapper
implementation that were easily fixed. Yes, I know it isn't native,
but I don't care, as the widgets work right of the box and I don't
have to worry about cross browser compatibility.
It is also very easy to skin the app. Just have a look at the Ext
forums for a list of additional themes.
Reinier Zwitserloot
Dec 6, 2007, 5:24:57 AM12/6/07
to Google Web Toolkit
You do realize that MyGWT is also based on gwt-ext right, Rob? It's
just a better version.
just a better version.
sarikan
Dec 6, 2007, 5:56:25 AM12/6/07
to Google Web Toolkit
I can not say that I'm very experienced in both of the frameworks,
I've been reimplementing a small application of mine using GWT, and I
can tell you that in my opinion it is going to be a very popular
framework in the future. I'm not going to compare it to other "hot"
tools and approaches in web development, to avoid a flamewar, but
being away from relatively inefficient development practices of html
+javascript is priceless for me.
The only and only thing that I am not happy with GWT is that even if
the docs say that it is meant to be integrated into existing apps
easily, I have not seen many best practices, docs, tutorials etc. on
this. This is where YUI seems to do relatively better/easier. But
maybe it is my fault, and GWT can be easily integrated into existing
solutions. Other than this, especially tool support and a potential
easier hibernate integration (in 1.5 maybe?) would make GWT a killer
"framework" which is something more than a library (what YUI is to
me) .
All the best
Seref Arikan
I've been reimplementing a small application of mine using GWT, and I
can tell you that in my opinion it is going to be a very popular
framework in the future. I'm not going to compare it to other "hot"
tools and approaches in web development, to avoid a flamewar, but
being away from relatively inefficient development practices of html
+javascript is priceless for me.
The only and only thing that I am not happy with GWT is that even if
the docs say that it is meant to be integrated into existing apps
easily, I have not seen many best practices, docs, tutorials etc. on
this. This is where YUI seems to do relatively better/easier. But
maybe it is my fault, and GWT can be easily integrated into existing
solutions. Other than this, especially tool support and a potential
easier hibernate integration (in 1.5 maybe?) would make GWT a killer
"framework" which is something more than a library (what YUI is to
me) .
All the best
Seref Arikan
Denis Haskin
Dec 6, 2007, 8:36:04 AM12/6/07
to Google-We...@googlegroups.com
Can you clarify how it's
"better"? I'm not saying it's not, I'm just interested in the details.
Thanks...
dwh
Thanks...
dwh
Peter Blazejewicz
Dec 6, 2007, 3:31:53 PM12/6/07
to Google Web Toolkit
hi Gene,
> long run
I hope you had included mobile convergance in your decision making
points,
have you tested (or even estimated) how long it will take you to
update javascript libraries to support small/medium devices?
( hope you know what I mean: last time I've been reading such data
1.500.000 iPhones were already sold - number didn't included support
for iTouch, that was more then month ago),
you can re-write completly your current application in GWT to support
different media in couple of hours/days (depends on UI complex)
and even write custom componets from scratch (to limit cpu, make it
robust, etc),
don't think the same will work for YUI,
http://timepedia.blogspot.com/2007/11/gwt-and-android-marriage-made-in-heaven.html
> 2. Simpler skinning model (developing custom CSS to meet the project
styles)
I don't take that, for example I've simply took .css developed by Joe
Hewitt for iPhone and write gwt UI elements implementation which fit
pre-ritten css 100%. I don't have even to touch original .css at all,
the problem is that you have used default toolkit UI widget in your
decisions - while UI widgets are not real part of toolkit itself,
> 3. More open - no complicated Java-to-JS tool to deal with, if we
really get stuck
I don't know javascript at all (never learned it, I can *read* it
because I know Actionscript 2/3).
when I want javascript I'm usign GWT JSIO (javascript interop) project
regards,
Peter
> long run
I hope you had included mobile convergance in your decision making
points,
have you tested (or even estimated) how long it will take you to
update javascript libraries to support small/medium devices?
( hope you know what I mean: last time I've been reading such data
1.500.000 iPhones were already sold - number didn't included support
for iTouch, that was more then month ago),
you can re-write completly your current application in GWT to support
different media in couple of hours/days (depends on UI complex)
and even write custom componets from scratch (to limit cpu, make it
robust, etc),
don't think the same will work for YUI,
http://timepedia.blogspot.com/2007/11/gwt-and-android-marriage-made-in-heaven.html
> 2. Simpler skinning model (developing custom CSS to meet the project
styles)
Hewitt for iPhone and write gwt UI elements implementation which fit
pre-ritten css 100%. I don't have even to touch original .css at all,
the problem is that you have used default toolkit UI widget in your
decisions - while UI widgets are not real part of toolkit itself,
> 3. More open - no complicated Java-to-JS tool to deal with, if we
really get stuck
because I know Actionscript 2/3).
when I want javascript I'm usign GWT JSIO (javascript interop) project
regards,
Peter
mP
Dec 6, 2007, 4:38:16 PM12/6/07
to Google Web Toolkit
On Dec 4, 10:52 pm, Gene Ash <janes...@gmail.com> wrote:
> Hi,
>
> We have been using GWT as the framework in our project for quite some
> time. Now we are considering migrating the application to YUI due to
> the following reasons:
>
> 1. Richness of controls available
> 2. Simpler skinning model (developing custom CSS to meet the project
> styles)
> 3. More open - no complicated Java-to-JS tool to deal with, if we
> really get stuck
a much more productive, maintainable development platform.
> 4. flexible separation between AJAX features and server-side
> templates
> 5. fairly good object-oriented JavaScript - using proto-types and
> super-classes
Do you have code completion in javascript ?
Can you compare your js authoring tools against java ones, which one
is quicker to develop with ?
Sebastián Gurin
Aug 8, 2012, 4:05:12 PM8/8/12
to google-we...@googlegroups.com, Google-We...@googlegroups.com
I'm doing a YUI 3 GWT Java API on code.google.com/p/yuigwt/
Reply all
Reply to author
Forward
0 new messages