I am on searching special features of GWT which are present only in GWT and not in other web framework. I am a student and I am not well acquainted to the many web frameworks on the market, so if u can help me increasing my list of special GWT features, it would be a great help. Some which i know are:
1. GWT allows using java to program
web. (only, it also allows merging
javascript through JSNI of course)
2. The developer does not have to be a guru in browser incompatibilities
to develop web sites which works on
a variety of browsers because
incompatibilities are handled by GWT
through differed bindind
3. GWT allows easy integration of popular Java Tools such as ,
hibernate through gilead
4. GWT enables server implementation not only in java but also other
languages such as php
5. GWT enables code splitting which improves application interactivity
by allowing javaScript file to
download only when required
6. In essence GWT is toolkit, it does not force a way to program,
other layers can be placed on top of
it to program such as placing MVP or
MVC framework on top of GWT and then
develop app
7. GWT MVP is great because first it allows collaborative working, faster
testing with JUnit and the event bus
allows many updates in client side
application by placing event on the
event bus
8. GWT compiled java files to obfuscated mode which is first small
and make the application safer
because bots fails on the javascript
generated during the obfuscated mode
In case in the 8 points, i've mention something which not special to GWT, then let me know.
There's also 'perfect caching', which is the term used to describe the way that GWT optimises JavaScript for each browser.
Instead of building a large JavaScript file, with code that can handle all of the various browsers, GWT builds multiple JavaScript files at compile time, and downloads only the one that is relevant to the browser type that is being used.
EDIT: Every time you make a change to your Java code, GWT changes the name of the corresponding JavaScript file. Web servers can turn on caching for the JavaScript files (so that browsers won't re-download the same file), assured that the name will change when the Java code changes, and the browser will then download the latest version.
EDIT: I also really like the CssResource feature. By creating obfuscated CSS style names, GWT effectively gives each widget its own namespace for CSS styles; for example, I could define a 'pretty' style name on two different widgets, and have those styles using different CSS rules. Of course, it is possible to share CSS styles between widgets too.
Image resources are cool too. They optimise the way that images are downloaded and accessed.
Don't forget internationalization.
I think you pulled together a pretty decent list of differentiators there already. I think that one point worth adding is the RequestFactory feature in the most recent release, which, if you will, is simplistically speaking and RPC for data and makes it quite easy to develop Create, Read, Update and Delete - type (CRUD) of applications.
There are other, more important/wider accepted GUI-Frameworks that are based on Java.
There are for example Struts and JSF. That's why some of your points don't fit only for GWT, but for all GUI java frameworks in general, e.g. bullet point 1, 2 & 3.
But to add another one:
I think GWT is an easy way to code an AJAX-application, because it hides the AJAX stuff quite well. Wouldn't you agree?
Furthermore, GWT is a proprietary framework (which is somehow a unique property). JSF is standardized and Struts is lead by Apache.
Related
We're building a large enterprise application (dozens of modules) with GWT and need to decide whether to use ClientBundle or not. I was curious what pros/cons the StackOverflow GWT community view as deal makers and deal breakers for such a use case.
As far as we see it currently:
Pros
All images/css files that take up server resources to download are eliminated
Client loads faster because of the above (i.e. inlined image urls)
CSS names are obfuscated, so namespace collisions are eliminated
CSS is automatically optimized / verified
Unused CSS classes are eliminated (above)
Java reference to class names are replaced with refactorable css interfaces
UiBinder reference to class names are replaced with refactorable css interfaces
No more big "main.css" fails as resources are module bundle specific
Cons
For maintenance CSS becomes either unreadable in obfuscated mode, or extremely verbose in debug mode
More steps needed for basic CSS work (like adding class)
All devs must know Java,CSS,HTML nuances
CSS3 and other at-rules (i.e. #font-face) are not supported by GWT natively
Increased compilation times
Thanks!
I have been using client bundle heavily in m-gwt.
One thing that was bothering me was styling for devices that did not have dev mode. So styling could mean recompiling the complete app.
Mostly all CSS3 Rules can be used in ClientBundle by using the literal function, so that should be okay. It gets a little tricker with #media queries. You can inject the css as a simple textresource as a workaround, but its kind of ugly.
When you are talking about several gwt modules, consider using multiple clientbundles so you can still use split points to keep the download file size under control (Depending on how big your .js files get)
I have used clientbundles in several big gwt apps and for me compile time checking and refactoring support beats the little quirks that are still in client bundles.
Just two additional notes:
There is a utility available in GWT which allows to automatically create the interfaces for your CSSResources
It's true that debugging styles can be a little bit cumbersome because of the obfuscated names. I had good success by using Firebug to change styles in dev-mode directly in the browser and when I am satisfied I change them in my GWT app.
After playing around with Vaadin for about a week I'm curious about how Vaadin uses GWT. GWT compiles Javacode to Javascript. This has to be done everytime when you are redeploying.
Since Vaadin has to be understood as a server-centric framework, eliminating your flexibility on writing Code that is executed on Clientside and moving everything to the server (which sounds worse than it actually is), the GWT Compiler only runs once a time. For example this happens when you are importing a plugin from the vaadin website.
But it can't be that easy right? If it only would compile the code of the plugins to javascript this could have done before.
So, my question is:
When does VAADIN use the GWT Compiler and what does it do at that point other than compiling to js?
Basically you have it right, and mostly answered the question yourself.
In Vaadin the user interface components consist of two parts:
Server-side "component" compiled using JDK
Client-side "widget" compiled using GWT
These parts communicate with each other over HTTP and automatically synchronize their state as needed. Server-side part maintains the state of the user interface component and the client-side widget renders that state.
Application developers typically only use the server-side components to build the application and they don't really have to care about how the client-side works.
In general, new components to Vaadin can be developed in two ways:
Composing existing components
Creating a new widgets with GWT/JavaScript (+ other client-side tech)
The first method here uses the existing classes and don't need recompilation of the widgets with GWT. Only the application code is compiled (with JDK compiler). However, in the second scenario the client-side classes change and need recompilation. This is when the GWT compiler is needed.
Due to the rather monolithic nature of the GWT compiled JavaScript (regardless of new code splitting features of GWT the namespace is global) Vaadin uses the concept of widget set. That is a GWT module that contains all the widgets needed in the application. That means that adding new (client-side) widgets to an application a GWT recompilation is needed. It is also a good practice to recompile widget set when removing widgets to optimize the widget set size.
GWT compilation step itself is nothing special. However, Vaadin itself contains lot of additions, helpers and workaround to GWT classes that are applied and used by the widgets.
All this is quite visible when using Vaadin add-ons (see http://vaadin.com/directory). Even add-on are simply jar-files, if they contain a new client-side widget code, widget set compilation using GWT is needed, when they are added to a project.
I'm using GWT (2.0.x) to develop a large scale and modularized application, but some modules have a lot of classes.
I'm facing a problem with GWT in development, because the DevMode it's taking a long time (processing) when I change every client-side class and refreshing at the browser.
My last option is to split more that modules, but I'm thinking to edit the GWT-DEV source code and "tell him" to do hotdeploy only on selected classes.
I have another option rather than edit GWT-DEV source code ?
Try using GWT.runAsync() to lazy load your code. If you can load only those modules that you need. You can make fairly complex web apps using GWT which run very fast. Hope you are following the MVP architecture recommended by google. Any extra information regarding the number of your classes etc will be helpful if figuring out if you need to reconsider your architecture or not.
I have my first GWT project that I created using UiBinder (GWT 2.0 way) which I found to be easier than write my UI creation Java source code (GWT 1.0 way).
But I saw this thing called GWT Designer that Google are releasing for free. It has nice features and wizards which were missing with the standard Google Eclipse Plugin. I like it, but I still think that using UiBinder is better. I think GWT Designer will be really useful when it can help you write UiBinder XML files (GWT 2.0 way), and not just source code (GWT 1.0 way).
What do you think about it?
Do I need to migrate to GWT Designer project?
Will it be better if I migrate but still keep UiBinder UI creation?
The latest GWT Designer now has support for UiBinder, and it works great.
http://download.instantiations.com/D2GWTDoc/continuous/latest/docs/html/wizards/gwt/uibinder_composite.html
UiBinder can give you better performance and a better optimized download than traditional widget construction; to me that's enough of a reason to stick with UiBinder. If your app is light and fast enough as it is then the choice probably comes down to what style of development suits you best.
I wouldn't go as far as to port your existing UiBinder templates into the designer. Google will be adding support for them to GWT designer soon enough.
I haven't used the newly-freed GWT Designer yet myself, but I wouldn't expect that it would warrant migrating your entire project over to it if it's already written using UIBinder.
Remember that the two methods of constructing a UI are not mutually exclusive -- you can use the GWT Designer to create a new widget and use it in an existing UIBinder project, and if you decide it's that much better, you can consider migrating at that point. Or not, since they can still happily coexist.
If you are doing professional development in an organization that utilizes experts in CSS and html, then GWt is going to be a tough sell if you don't use something like UIBinder for layouting as well as individual pages. I also think that a CSS designer can do a better job at responding to UI requirement changes than a java developer using GWT layouting techniques.
However if your java staff has control of the requirements and don't have to answer to UI designers, then I suppose choosing between delcarative templates and something like GWT Designer is just a matter preference.
As said in the relaunch announcement:
Now that these products are available again, we hope you’ll start using them within your GWT projects. Meanwhile, our next step is to more deeply unify them into the GWT family of tools by blending the fantastic Instantiations technology into the Google Plugin for Eclipse (GPE). So, there’s much more to come, including things we’re pretty sure you’ll like, such as UiBinder support in GWT Designer.
It wouldn't make sense to get ride of your UiBinder code since GWT Designer will support it soon.
DON'T use the designer plugin. The most recent update (8.1.1 at the time of this post) contains buttons that allow the user to add elements that are incompatible with IE, for instance CellTable, DeckPanel, HorizontalPanel and VerticalPanel.
This means whoever uses the plugin, uses it entirely at their peril. If IE7 tries to pull in these elements, it will load a partial page but fail to load components that use these elements. IE8 may not be able to load the application at all.
is there a difference between Ext GWT and GWT-Ext? Cos i was surfing Ext GWT and saw this page http://gwt-ext.com/demo/. any help guys?
ExtGWT is marketed and maintained by the same guys who developed ExtJs library. ExtGWT shares its look and feel and API structure with ExtJS. Contrary to popular perception, ExtGWT is not a wrapper around ExtJS javascript, but written ground up using GWT DOM and other low level GWT API's. It is 99% java based and uses no (or very little) JSNI to get things done. It also supports data binding. This library is actively supported and also has a paid commercial version.
On the other hand GWT Ext was developed by Sanjeev Jeevan as a wrapper around LGPL version (no support now) of ExtJS. So the library is a very shallow wrapper around ExtJS javascript and uses JSNI extensively. This can create problems, particularly if you need to debug the library. GWT Ext does not enjoy the same level of community support as ExtGWT and also the original author has long since moved on to a different project. Read about the reasons here.
If you have to choose between the two, and plain old GWT is not an option, choose ExtGWT. Keep in mind that it is GNU GPL licensed.
Neither. You'll have nothing, but problems with third-party GWT widget libraries. I've wasted four years on significantly more refined and mature SmartGWT and finally gave up.
Styling standard GWT components that wrap native browser controls is easy. You should strive for native portable control set and you'll rarely need anything more for a modern minimalistic mobile-friendly UX. However if you still crave some third-party widgets, look at GWT-Bootstrap3: https://github.com/gwtbootstrap3/gwtbootstrap3