After a long debate between many RIA/Ajax framework, we settled on GWT. When reading about it, this framework seams to be doing everything well and easy. But like any technologies, there is always down side and we we learn them the hard-way.
What are the main downfalls or problems when using Google Web Toolkit (GWT)?
(eg: Back/Forward Button support, Slow Response time, Layout Positioning, JavaScrit bugs, etc)
So far, I got the following from the response:
Lots of code for simple UI
Slow compilation
Thank you
I have been using GWT for nearly 2 years. Although I could be called a fanatic about GWT, there are some issues that one should know ...
As others have said, JavaScript compilation is slow. My application requires nearly 4 minutes for core i7 CPU, 8 GB memory. Total size of generated JavaScript is about 5 MB. But thanks to development mode, compilation to JavaScript is not needed frequently.
GWT RPC is extremely slow in development mode. It is 100 times slower than hosted mode. It was quite a big problem for us. We did consider giving up GWT just because of this reason. the reason for this sluggish performance of GWT RPC in dev-mode is serialization. Serialization of types other than String is unbelievably slow in dev mode. We did implement our custom serialization, it is nearly 30 times faster than GWT built-in serialization.
Claims that writing GWT application requires only knowledge of Java is just an illusion. You should have solid information about CSS and DOM. If you don't, you will spend too much time debugging your user interface.
You should consider that you can only use a small subset of the JDK to implement GWT applications. Reflection is not available; you should use third party libraries, such as GWT ENT, or write your own generator for reflection.
Another caveat that one should consider is the size of generated JavaScript by the GWT compiler. Most of the GWT applications consist of a single web page, as opposed to multi-paged traditional web applications. Therefore, loading of the application requires significant time. Although it could be mitigated by using a multi-module approach and code splitting, using these techniques is not always straightforward.
All calls to the server are asynchronous. You should adapt yourself to writing asynchronous code. And the downside of asynchronous code is it is more complex and less readable than the equivalent synchronous code.
Here are my observations on the downfalls:
steep learning curve if one wants to use GWT effectively in large applications, due to enormous number of high level conventions associated with GWT.
Model View Presenter paradigm - in fact there are 2 different approaches to MVP proposed on GWT site.
UiBinder
CellWidgets
Editors
concept of Activities and Places
RequestFactory
AutoBeans
asynchronous requests require different mode of thinking when it comes to designing the whole application
long compilation time, it does not affect Development Mode as much as full builds (all the permutations for all the browsers and languages are compiled which can take hours for big projects). JRebel can reduce requirement of Development Mode restarts a bit.
problems with unit testing - GWTTestCase starts so long that it is unusable for unit testing. However thanks to GWTTestSuite it can work well for integration testing. Thanks to keeping clean MVP it is also possible to unit test Presenter logic by mocking Displays (see my answer).
it requires some experience to decide whether specific logic should be implemented client side (compiled to JS) or server side.
and of course there are some small bugs, especially in new features like Editors and RequestFactory. They are usually resolved quickly with new releases, however it could be annoying when you encounter some GWT issue. Anyway the last downfall applies to any Java framework I have been using so far. ;)
lack of reflection on client side, which could be resolved with Deffered Binding and Generators, but it is another convention to learn.
If I was to start new GWT project I would:
add dependency on Google GIN library (unfortunately it does not work with GWT 2.2 at the moment, but should be compatible soon).
design general layout with LayoutPanels
structure application "flow" according to concept of Places and Activities.
put all the Places into separate GWT module (common navigation references)
put each Activity in own GWT module (it could help in application code splitting later on)
treat Activity as glue code which has View and Presenter providers injected with GIN
design data entities to be compatible with RequestFactory
create all data editors with UiBinder, MVP and Editors framework in mind
use RequestFactory in Presenters, as well as in Activities (to fetch initial data to be shown).
inject with GIN every identified common component like standard date format, etc.
The spring roo tool can generate a lot of GWT based code for standard application elements.
I did a prototype app with GWT some time ago, and I found that the time it takes to compile the java to javascript took a very long time. Even more the time to compile increased noteably with each line of code we wrote.
I just wasn't happy with the code, compile test phase getting slower and slower through time.
Another question on SO about the compiler: How do I speed up the gwt compiler?
I think that main disadvantage is that GWT often requires to write lots of code, to acomplish simple tasks (but it's getting better and better with each release). On the other hand it's brilliant when it comes to developing complex, custom widget where it shines.
During couple of projects GWT has proved to be very good in terms of performance and there hasn't been many bugs - it's very good in terms of cross-browser support imo.
as a fan of nativity...
I prefer JQuery rather than GWT, because, it's easy to animate or accomplish complecated tasks without writing many classes..
Related
I'm trying to decide whether to build a Logic App or a Web App.
It has to do things I'm quite comfortable doing in C#: receive messages in various formats (a few thousand per day), translate them, make API calls and forward them. None of the endpoints are widely used, so the out-of-the-box connectors won't be a benefit. Some require custom headers, the contents of which are calculated using a hashing algorithm. Some of the work involves converting Json into XML and vice-versa.
From what I've read, one of the key points of difference of Logic Apps are that you don't have to write any code. Since our organisation is actually quite comfortable with code, that doesn't feel like it'll actually be a benefit.
Am I missing something? Are there any compelling reasons why a Logic App would be better than a Web App in this instance?
Using Logic Apps has a few additional benefits over just writing code which include:
Out of box monitoring. For every execution you get to see exactly what happened in each step of the process with a monitoring view that replicates your Logic App design view.
Built in failure handling. Logic Apps will automatically retry calls on failure cases and also allows you to either customize the retry policy or have a custom retry policy with a do-until pattern.
Out of box alerting. You can configure alerts to inform you of failures.
Serverless. You don't worry about sizing or scaling and you pay by consumption.
Faster development. Logic Apps allows you to build out the solution faster especially as you consider that you don't have to code for monitoring views, alerting, and error handling that comes out of the box with Logic Apps.
Easy to extend. If you are already using a Logic App access to over a 125 connectors to various services will make it easy to add business value or making it smarter by including things like cognitive services to your workflow with very little extra effort.
I've decided to keep away from Logic Apps for these reasons:
It is not supported outside Azure. We aren't tied to any other providers, and to use Logic Apps would break that independence.
I don't know how much of the problem is readily soluble using Logic Apps. (It seems I will be solving all sorts of problems which wouldn't be problems if I was using C#. This article details some issues encountered while developing a simple process using an earlier version of Logic Apps.)
Nobody has come up with an argument more compelling than the reasons I've given above (especially the first one) why we should use it, so it would be a gamble with little to gain and plenty to lose.
You can think of Logic Apps as an orchestrator - something that takes external pieces of functionality, and weaves a workflow together.
It has nothing to do with your requirement of "writing code" - your code can be external functions on any platform - on-prem, AWS, Azure, Zendesk, and all of your code can be connected together using Logic Apps.
Regardless of which platform you choose, you will still have cross-cutting concerns such as monitoring, logging, alerting, deployments, etc, and Logic Apps addresses very robustly all of those requirements.
I started a CPU-intensive project in web2py which at some point needs a dynamic GUI interface. Due to the intensive nature of the processing, I am unsure whether embedding this python code (in web2py views) would be price-sensitive as deployed to GAE (GoogleAppEngine) with its server-side processing, at least compared to using another framework, etc. Correct me if I am misinterpreting how the code will be processed or if there is an easy way around this (a separate or integral client-side processing implementation, if possible))
Due to the lack of information in cross-referencing Web2py with Cappuccino, I assume combining their mechanisms would be an untenable prospect.
I am trying to put together my first Google App Engine applicaton and having ploughed through the docs and some examples I decided that I quite like the Objectify approach. However, I also like GWT but passing an Objectify object to a GWT class causes issues.
So I tried Objectify-gwt but there just seems to be tumbleweed blowing thorugh that project. Any examples seem to date from 2010/2011 but the project seems to have been forked off the main Objectify branch recently (April 2014) so I was just wondering if it has a future.
If not, what is a good pattern for passing data between an Objectify back end and a GWT front-end? Do I really have to have two sets of objects, one in the persistence layer and one in the UI?
objectify-gwt is a very small bit of code which doesn't require much in the way of updates. That said, someone just submitted a pull request that fixes a problem with Gradle builds. It's overdue for a new release. But unless GAE adds some new data types, objectify-gwt is pretty much done. I wouldn't worry about the future of objectify-gwt any more than I would worry about the future of GWT in general.
That said, I think the value of passing raw entity types back and forth across the GWT-RPC boundry is overrated. It tends to produce an Anemic Domain Model. When I was actively using GWT, I tended to do this with simple embedded components and not with whole entities. But every project is different; maybe it is a good approach for you.
I have been doing high performance scientific computing in c++ most of my life. I am trying to learn to developing AJAXy web applications. As an exercise, I would like to build something that has a subset of functionality of facebook (profiles, posts with comment threads, friend lists) + the ability to search any post/comment.
I have no experience developing these kind of apps, except minor amount of toying with Google Appengine with GWT+Java and little bit of python. What tools/stack would you suggest using for it? I understand that this a very vague question, but I'd like to get a few opinions and your thought process about how would you go about using it.
How does the choice change, if you want a fast prototype as fast as possible, vs if you are trying to build something that can scale and last a few cycles of feature requests.
To be more specific, I'm lost in questions like, should I consider Drupal, should I consider Lucene for search, Would GWT get me what I want in the UI or would python+django be faster to develop. Probably I should not over think and pick something. But some perspective from others would be nice.
If you have started out with Python, that might be the easiest to get going with, especially since you have some experience with Google's App Engine already. However, if you have spent most of your time working with C++ ... did you know that C++ has at least two different full-stack web frameworks?
CppCMS
Wt (WebToolkit)
Remember, it's what you develop fastest in that makes the difference in the long run. What will slow you down most of all is dealing with what you dislike. So, if long compile times kill you, then try Python, Ruby, PHP, or some other dynamic language. If having code that is less than perfectly optimized (and slower that it could be) is what bothers you most, use C++, C#, or Java instead.
One disadvantage with google app engine is that there is no CMS like drupal or Joomla for google app engine so you're going to have to write your own if you want some of that functionality. The advantages of google app engine however outweigh the disadvantage since you have easier development, easier deployment, won't have to fiddle with phpmyadmin or other ugly sql interfaces, with app engine you also leverage google's huge infrastructure and since it's cloud computing you only pay for what you use. If you want something you as a developer will be most happy about - then I recommend you choose Google App Engine.
Is there an open source, reference implementation of a simple, correctly designed, best practiced, GWT + GAE open source application? I would like to see the best practices on the following:
Recommended GWT Page navigation, session handling
GWT best practice UI (validation, controls etc)
Work with detached objects, conversations, wizards
Effective and "as intended" integration between GWT and GAE
MVC implementation with GWT and GAE, where is the controller? (Spring?)
Using domain POJOs in the UI without writing data transfer objects?
JDO (or JPA) and DAO layer - correct mapping, transaction and service layers
A permission layer, (e.g. like Spring security/ACEGI)
Integration with client side libraries (JQuery / Sancha)
JUnit layer for both server and client side
All the samples I found so far handled a very narrow aspect of the above, and I'm sure there has to be one good "starting point" such as the one's you can find for Spring / Hibernate or RoR projects
Have you looked at Roo?
This can be used to quickly build a GWT app based on one of a number of JPA providers and databases.
It doesn't offer all the items listed but has quite a variety of optional add-ons
Unfortunately I don't know of any such reference implementation, and I don't think you're likely to find such an all-encompassing example is because:
It's much easier to understand an example that focuses on one thing, like focusing on using JDO in a GWT app, or using Spring security in a GWT app, or how to do client-side validation in a GWT app. There's no reason one sample has to include such disparate features.
In the same vein, what if I wanted this exact list of features in a reference implementation, but using something else instead of JDO? Should I expect someone to write everything all over again, with that one part replaced? It's much better to write samples and documentation for each piece of the puzzle and leave it up to developers to glue that knowledge together.
Some of the things you listed aren't exactly common usages, e.g., integration with JQuery and Sencha. That's not to say it's not possible, and there are some (focused) examples out there if you look, but it's not the main use case for GWT developers, so I don't think it makes sense in a reference implementation.
The sort of app you're talking about is very complex, something that would take multiple engineers months to write and then would have to be maintained and updated. All for a sample? Some people aren't willing to invest that kind of energy even when there's money involved!
That being said, there are some great GWT sample apps (with source available) here. Even though they don't encompass everything you listed, they'll hopefully be helpful.
There is a "Google App Engine Java and GWT Application Development" A code of the application they build during the book comes "Licensed under the Apache License, Version 2.0" so (I guess this is qualify as open source but IANAL) it worth looking at. At least it does helps me as I am working through the same set of questions. It written Nov 2010 so it is still relevant as Google Platform evolves at astonishing speed.
Declaimer - I got no relation to this book except that I am reading it.