We have multiple product developed primarily using GWT and currently used by our end customers.
Wanted to know the road map of GWT. I got some unofficial update that google is moving there product which is developed in GWT to some other new technology. Is it true?
What is long term plan for GWT and also we haven't seen any new release from past one year. Any suggestions ?
In my opinion the GWT project is dead. The last stable version was released on Oct 19, 2017. As opposed to the other answer I would like to point out that the Google Trends score is relative to the highest point on the chart for the given region and time. Since we are particularly interested in the long term chart it doesn't make sense to analyze the short time chart.
Let's instead have a look at the long term trends. The chart pretty much says it all - the project is facing a massive decline:
Stackoverflow Trends
Google Trends
This is what increased interest would look like:
Example: Google Trends for Angular
I have worked over GWT and GXT for some time now, and as a developer I can say that - GWT/GXT based application are fast for UI development once the layout is done , and they are easy to debug also, there are so many libraries available - which are compatible with gwt and are free also , well there may not be that much of future release in gwt/gxt - but i think the versions of gwt/gxt which are available are powerful enough to develop a complete web application easily.
By the google trends , what I have got for GWT is as below -
and for GXT
If you see the trend for GWT and GXT near by end of 2018 - it has been increased a bit
If you dig into stack-overflow - you will get ton of questions and response around GWT and GXT
GWT questions
GXT questions
so i think - if you have team of good developers - who already have knowledge on GWT / GXT - you can go ahead -
All the best :)
As a I was always fond of GWT - i kept following for updates in between and here you go, new release of GWT is here
[GWT release-notes][5]
2.10.0 June 9, 2022
We are using GWT in an embedded product for some years now with a small team of developers and I find it a plus that GWT is not rapidly developing, opposed to Angular. I am not so familiar with Angular (some other teams are using it), but what I hear from colleagues is that just maintaining the status quo (i.e. having all libraries reasonably up to date) is in it self a lot of work. We do not have the resources for this kind of software maintenance.
How are others experiences on this, has anyone moved from GWT to Angular with a small team and how are the experiences (from a resource point of view) to that?
It is 2020. I don't know whether someone is still looking for an answer to this question.
At this point of time, GWT is not a prudent decision for any new project. There are 2 primary reasons.
Google tries to distant itself from Java as far as it can. Google prefers Kotlin over Java in Android.
2.Angular is far superior in every way. It provides type safety. and closely related to JavaScript. Any JavaScript code is a really typescript code. So the libraries that were created for JavaScript over the decade works seamlessly with Angular.
This is not a direct answer. Just thinking aloud.. perhaps..
But I've seen Vaadin (vaadin.com) using GWT (gwtproject.org) in the past and now changing to Polymer (polymer-project.org) in the recent years.
Can't deny the value GWT brings in through type-safety. So the question perhaps can rephrase to what alternatives developers have without re-writing the whole solution to support a new model/paradigm of a completely new framework.
If there is a way to overcome the slow compilation on GWT, it's still a great idea and a product, and will be for a long time. So worth finding an answer to the question I believe.. ??
Having said that, I wonder if Google still use GWT for Gmail and AdWords? :-) (Or the new interfaces meaning they've already crossed to the Polymer world!
We have a medium size project based on GWT in our company; It's a mature software, with more than 100,000 users and has performed well so far. However, GWT technology seems to become obsolete and I personally see no bright future for it, in competition with brand-new client-side rivals such as Angular. GWT had another minor release (2.9.0) several months ago, but it does not mean that project is still active and promising. I have had a relatively good experience using GWT so far and our clients get used to it as well, but the problem is that you might wake up someday and find out that a new version of Chrome or Firefox is released that no longer supports GWT mutations. Knowing that we gradually started migrating our client code to Angular which is of course very similar to GWT in the soul (Both are complete UI Frameworks; GWT transforms java to JS, while Angular does the same with TypeScript; both projects are supported by Google, and there are lots of widgets for both available out there).
I suggest that, despite all its costs, moving from GWT to another more up-to-date technology is inevitable and crucial IF the remaining of your software's lifetime is more than one or two years.
There has been a new GWT release version 2.9.0 on 2020-05-13.
For GXT (currently at version 4.0.3 from 2018-03-16), vendor Sencha just announced an early adopter commercial release 4.0.4 in either Q3 or Q4 of 2020, but that release is probably only working with GWT 2.8.2.
Unfortunately there's no public roadmap from Sencha to support GWT 2.9.0 yet.
Related
Does anybody know the current status of Scala-GWT project?
Grzegorz Kossakowski, who was the main author there, seemed to quit the project to work on scalac in the Spring.
However, in an interview in November 2011, he said
I expect the next release to be 0.1 and only then I'll be actively
encouraging people to try it for real projects. This release should
happen in a few weeks (before Christmas for sure).
Scala-GWT is a very promising project, in my opinion, since it complements Play2 for Scala -
Play being the framework of choice when creating applications with a lightweight, stateless architecture and Scala-GWT the framework for rich client applications.
I remember recently having read on the mailing list from a main (and currently the only) developer that he's been away for personal reasons and that he's planning to get back on the project some time soon. But the fact that the project hasn't gotten any funding it its life and the number of developers working on it don't make its future promising. Sadly.
Scala+GWT
The Scala+GWT project aims to compile Scala code for the browser via the GWT toolchain.
Background: I have created a CRUD web app using a java based RAD tool called Wavemaker. I am considering developing the app again in a framework that has greater support. Even though I have some experience in development I still get confused by all of the terms. My understanding is that there are languages (C#, PHP, Javascript, Java, etc), frameworks (Wavemaker, Ruby on Rails, Yii, Symfony, Code Igniter, Zend, etc) and editors (Dreamweaver?)?
I outsourced the development of a mobile version of my web app and this was created using jquery mobile, php and ajax. I started using Dreamweaver because I read it had integration for development with jquery mobile and hence I could perform modifications on my mobile app.
I was wondering whether Dreamweaver was a viable choice for the development of a CRUD web app? I used dreamweaver many years ago for the create of html pages and it would automatically create a lot of "unclean" code that made it hard to maintain. I fear that I would put myself in a similar situation here with server-side code.
If Dreamweaver is not appropriate could you kindly suggest a framework that may meet my requirements?
The main things I liked about Wavemaker:
Drag and drop widgets
A lot of the database functions were automatically handled
The main things I don't like about developing with Wavemaker (not Wavemaker itself):
Support: The support generally involves posting to the forums and hoping for a reply that may never come. I would rather paid support over this option which to be fair is offered by vmware but I found it too confusing.
Small number of freelance contractors: Much of the functionality within my app required coding or workarounds outside of the standard features of wavemaker and it is very hard to find a freelance wavemaker developer for help
Ongoing bugs that cause a headache during development
With that being said my priorities are:
Support: great documentation with rapid response to problems (even if this requires a paid subscription)
A large number of freelance contractors available (I guess this means a popular framework using a popular language).
Simple and easy to use (I understand there would be an initial learning curve)
Stable: I won't be running into bugs that hold up my development and need me to wait for the next release for a fix
The ability to incorporate reporting like BIRT reports or Jasper.
Possibly steer clear of Java as I have found Tomcat to be an extra level of complication that it would be great to do without.
Any help would be greatly appreciated.
Thanks.
Dreamweaver was a viable choice for the development of a CRUD web app?
Yes, but with caveats. It still does not produce code that advanced users would consider "clean" but the integration of JQuery Mobile in CS5.5 makes it a good choice for non-coders or beginning coders who need to spin up rapidly and will worry about elegance later.
That being said, if you are outsourcing the design it is likely that the code you get back will be editable in Dreamweaver but not written in such a way as to take advantage of Dreamweaver's built-in behaviors (automatic code writing). Dreamweaver expects to see code written to its specs in order to take over for the user. If not, it is still a great wysiwyg editor and above-average code editor.
But it's not a framework. In your sitution, JQuery Mobile is the framework and any JQuery Mobile developer should be able to step in and run with the project. But if you write big chunks of the CRUD using Dreamweaver, developers may tell you that they will want to rewrite those sections. Some won't care.
Just got back reading a question from 2 years ago here.
From there and several other places on the internet i concluded that developing with Ext-GWT was sucky.
My question is, with the release of GXT 3, whether it is still the condition now?
I have several GXT applications, one of which is ~35K lines. Have not found any of the problems other people mention.
I was doing straight ExtJs/JavaScript, then moved to GWT with the advent of GWT-EXT and later moved to Ext-GWT (GXT). I would still be doing ExtJs/JavaScript today if it were not for those two toolkits.
Performance issues: non issue on modern browsers. on IE6/7, you want to use common sense, displaying 1000 rows in a grid is not the best idea, from a performance and usability standpoint.
GXT is still crappy. We've been using it and although it provides some nice widgets it takes forever to write any business code. Most of our time is spent trying to get GXT to do the things we want. For example, using RPC is painfull because you have to keep converting from JPA entity beans to ModelData object (or some other object that can be serialized over RPC), Also there are inconsistances such as if you want to use the FormBinding object (which automatically maps between form elements and ModelData), then you can't use FieldSets which are really useful. FormBinding will only work with FormPanels and not FieldSets.
Also if you want to use the FileUploadField object you can't test it in Dev mode because of the post URL.
Basically, if you want to add 40% more time to your development fine. But otherwise go with a normal JavaScript framework.
We have been using GXT 2.x in the last one year while we built 3 projects with GXT.
Other than the lack of a WYSIWYG UI designer which makes the UI designing relatively slow compared to other frameworks, it is still IMO the best widgets library built on top of GWT.
So far we have not encountered any major issues with GXT.
A good performance comparision can be found here: http://gxtvsgwt.appspot.com/
In our current project we have been using Ext-GWT 2 for about a year without any major complaint. It's sometimes a bit buggy but generally works.
We used GXT 2.1.x for a year without any major problems. recently, we updated to GXT 2.2.4 and just needed minor changes in our code, but they weren't because of GXT, but due to the upgrade to GWT 2.3.0
Personally, i like coding with GXT. I can't see why someone would say GXT development is sucky, except for the already mentioned performance issues and the lack of a UI Designer.
I don't know any other GWT-based framework with so much features.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
My company is planning on developing a brand new web front-end application.
Some background:
It must "sizzle" i.e. a nice marketable look and feel.
Our development team has no Java experience, with limited experience in Silverlight, Javascript, JQuery or CSS.
Time to market is a factor.
We need to stream large amounts of data from an Oracle database.
It must support 500 - 1000 concurrent users
It will be hosted internally behind a firewall.
We need mapping (geo-spatial) capabilities.
Someone has recommended using GWT instead of Silverlight or Traditional technologies(Javascript, jquery, CSS etc.).
I am not sure if this is the right way to go? A lot of the GWT news is from 2007/2008. It makes me think that this technology is old and maybe dying.
If you had a choice would you choose GWT?
unfortunately two of your statements are mutually exclusive in this context:
Our development team has no Java experience
Time to market is a factor
I'm a Java programmer who has picked up GWT over the last year or so. It's immensely effective being able to write direct to the browser using a compiled language & mature development tools. I can fly through web-development faster than ever before (using ASP, JSP, ExtJS ...).
But, as the other commenters have said: if you've no Java experience you're going to find it a real challenge picking up both technologies (Java & GWT) in a short time. If you do manage to make it to market in a reasonable time I could only imagine the code base would be in very poor condition (since you'd be learning as you go) - which would be a very poor foundation for your organisation's shiny new venture.
There again, you don't have a 'lot' of skills in the other related skills you listed either.
I suspect there's a more effective solution. As some wise old goat project manager said:
I have three variables to delivering your project: time, cost and quality. Pick any two
In your situation, if the organisation wants a quality product in a short time, it's the cost factor that must compensate - your organisation should buy in some interim GWT expertise to give you a sound software architecture and to mentor your team for the next few months. After that you'll be ready to take the reigns, inheriting a quality codebase by 'standing on the shoulders of giants'.
As others have said, GWT definitely is not a dying project. Quite the contrary actually as there are now more than 20 regular contributors from within Google (versus a semi-dozen back in 2008). Wave (despite being discontinued as a Google service, it's still alive as an Apache Foundation project), Orkut, AdWords, Google Moderator and the new (still beta) Google Groups are made with GWT; and parts of Google Buzz and a few other projects at Google are built with it too.
Now as to your choice:
Silverlight is a dying technology. Microsoft made it clear that it now invests in "HTML5": http://www.zdnet.com/blog/microsoft/microsoft-our-strategy-with-silverlight-has-shifted/7834
GWT is mostly a client-side toolkit, but it comes with "high productivity" tools for client-server communications (GWT-RPC and RequestFactory for end-to-end protocols, AutoBeans for easy JSON serialization). With UiBinder, you can easily put to use your web designer skills.
if you're comfortable with JS, then go for it, but then you'd have to choose the "right toolkit" (jQuery? Google Closure?). Otherwise (which seems to be the case), it really depends how much "ajaxy" you need/want to be. I'm a strong believer in "one-page apps", but YMMV, or you can have specific constraints that rule it out. In any case, you'd have to choose a server-side technology.
So, depending on your needs/wants and skills, I'd choose GWT or "some JS toolkit". In any case, you'll have full control over the look and feel (unless you choose one of the bloated players: ExtJS/ExtGWT, SmartGWT or similar; you'll probably have a shorter time-to-market with these, but you'll pay it later, in terms of performance, integration with other toolkits, and look-and-feel).
In the light of what you're saying about your skills, I would definitely recommend GWT (despite your lack of experience with Java); because lack of experience with JavaScript is far worse than lack of experience with Java (you're talking about a "large application", so it's really important to start building things right and/or have tools to help refactoring, which you'll have with Java).
#ianmayo replied while I was writing the above, and I can only second what he said!
GWT is definitely not old or dying! A lot of Google's own applications are developed using GWT. You can download the GBST case study and learn how the global financial company uses GWT to improve productivity and create a rich user experience. You have to know that when you use GWT you automatically use javascript, html, etc. You create a your gwt application in java, but when you compile it gwt creates a folder with html files, javascript code, css, etc...
I definitely recommend it!
In order not to mislead readers with above seemingly unanimous answers, keep objective view in respected stackoverflow, following review expressed exact experiences I had with using GWT. Whether GWT is dying depends on how many new apps will adopt it,Google trend can tell (gwt trend).
Excerpt from https://softwareengineering.stackexchange.com/questions/38441/when-not-to-use-google-web-toolkit
>
I am both good and bad to answer this question - good, in that I've actually used it before, and bad, in that I was quite experienced with HTML/CSS/JavaScript prior to working with GWT. This left me maddened by using GWT in a way that other Java developers who don't really know DHTML may not have been.
GWT does what it says - it abstracts JavaScript and to some degree HTML into Java. To many developers, this sounds brilliant. However, we know, as Jeff Atwood puts it, all abstractions are failed abstractions (worth a read if considering GWT). With GWT, this specifically introduces the following problems:
Using HTML in GWT sucks.
As I said it, to some degree, even abstracts away HTML. It sounds good to a Java developer. But it's not. HTML is a document markup format. If you wanted to create Java objects to define a document, you would not use document markup elements. It is maddeningly verbose. It is also not controlled enough. In HTML there is essentially one way to write
<p>Hello how are <b>you</b>?</p>
In GWT, you have 3 child nodes (text, B, text) attached to a P node. You can either create the P first, or create the child nodes first. One of the child nodes might be the return result of a function. After a few months of development with many developers, trying to decipher what your HTML document looks like by tracing your GWT code is a headache-inducing process.
In the end, the team decided that maybe using HTMLPanel for all HTML was the right way to go. Now, you've lost many of GWT's advantages of having elements readily available to Java code to bind easily for data.
Using CSS in GWT sucks.
By attachment to HTML abstraction, this means that the way you have to use CSS is also different. It might have improved since I last used GWT (about 9 months ago), but at the time, CSS support was a mess. Because of the way GWT makes you create HTML, you often have levels of nodes that you didn't know were injected (any CSS dev knows how this can dramatically affect rendering). There were too many ways to embed or link CSS, resulting in a confusing mess of namespaces. On top of that you had the sprite support, which again sounds nice, but actually mutated your CSS and we had problems with it writing properties which we then had to explicitly overwrite later, or in some cases, thwarted our attempts to match our hand-coded CSS and having to just redesign it in ways that GWT didn't screw it up.
Union of problems, intersection of benefits
Any languages is going to have it's own set of problems and benefits. Whether you use it is a weighted formula based on those. When you have an abstraction, what you get is a union of all the problems, and an intersection of the benefits. JavaScript has it's problems, and is commonly derided among server-side engineers, but it also has quite a few features that are helpful for rapid web development. Think closures, syntax shorthand, ad-hoc objects, all of the stuff done by Jquery (like DOM querying by CSS selector). Now forget about using it in GWT!
Separation of concerns
We all know that as the size of a project grows, having good separation of concerns is critical. One of the most important is the separation between display and processing. GWT made this really hard. Probably not impossible, but the team I was on never came up with a good solution, and even when we thought we had, we always had one leaking into the other.
Desktop != Web
As #Berin Loritsch posted in the comments, the model or mindset GWT is built for is living applications, where a program has a living display tightly coupled with a processing engine. This sounds good because that's what so many feel the web is lacking. But there are two problems: A) The web is built on HTTP and this is inherently different. As I mentioned above, the technologies built on HTTP - HTML, CSS, even resource-loading and caching (images, etc.), have been built for that platform. B) Java developers who have been working on the web do not easily switch to this desktop-application mindset. Architecture in this world is an entirely different discipline. Flex developers would probably be more suited to GWT than Java web developers.
In conclusion...
GWT is capable of producing quick-and-dirty AJAX applications quite easily using just Java. If quick-and-dirty doesn't sound like what you want, don't use it. The company I was working for was a company that cared a lot about the end product, and it's sense of polish, both visual and interactive, to the user. For us front-end developers, this meant that we needed to control HTML, CSS, and JavaScript in ways that made using GWT like trying to play the piano with boxing gloves on
First of all , GWT is not dying technology, its usage increases, and its latest version is 2.2. I am using GWT for 2 years, since version 1.6. Its improvements since them is quite amazing.
Since GWT is client side technology, it does have only positive effects of your application scaliblity feature. Because server side web technologies such as jsf, struts, wicket are server resource consumers, but gwt does not need any server resource to render user interface..
But there is problem for your team. Because your team has no java experience, it would be quite difficult to adapt yourself two new technologies java and gwt.. If you have time to learn , I would strongly suggest GWT.
It takes approx 1 year to become proficient in GWT. Using GWT pays off if you develop an application as sophisticated as MicrosoftOffice or PhotoShop. It makes no sense to use GWT for small and relatively simple apps, IMHO. GWT is a time killing framework indeed, and you have to have very strong reasons to use it. I think that 99% of web apps don't need GWT.
GWT is not dying framework, but time killing framework. It has security issue. You can do easily CSRF(Cross site request forgery) request to the GWT applications. Also Java and Javascript are totally different languages, you can't translate easily. For your productivity avoid GWT.
I'm starting work on a smartGWT project in a few days and I'd like to know what kind of experiences you had. To avoid making this a bashing of smartGWT or GWT or a freestyle discussion, I'm going to provide some pointers for the discussion:
Do you feel that the provided widgets are integrated well? Is there any widget you miss in particular?
Have you encountered any problems when designing your application that were caused by the framework?
Is the datasource integration as usefull as the smartClient team claims?
What methods do you use to make your smartGWT application persistent? e.g. How well do Hibernate and smartGWT play with each other?
Feel free to add anything you feel is worth pointing out.
I guess you already have your answers, but I would like to add a few more comments that may affect your decision:
Pros:
SmartGWT is the most compreensive LGPL GWT-based widgetery library you can find. So if you care for GPL pain, this is your thing
Comprehensive Showcase.
Really good performance (just check the Showcase).
Very active community in the forums.
SmartGWT extensions is another important project. For example, it has support for GWT-RPC based communication, which is not possible only with SmartGWT (unless you implement your own integration).
Rapid pace of development from the SmartGWT guys. Just count the number of releases since the SmartGWT project appeared.
Cons:
Besides the Showcase, I sometimes feel the only way to figure out how something works is by asking in the forums. This leads to a spread knowledge base. A community based wiki would be preferable.
Large amount of static files you have to use with your application (the famous 'sc' directory) which might lead to problems if your back-end is in GAE (because of the 1000 files limit).
We used SmartGWT in our last project (duration: 6 months). The following is my personal opinion:
The widgets are really great! The documentation and API is verbose. We would use client-side again.
The server-side integration works, but did not save any development time. Instead we had a lot of problems where we had to find workarounds. Also, because of the new API, no other developer can maintain the project within investing a lot of time to learn the SmartGWT API.
Some Cons:
You have to learn a totally new API instead of using Hibernate and GWT-RPC or REST.
The data integration is done automatically, that is true. But if you need some (also little) changes, you have to write XML mapping files as with Hibernate or JDO. So the benefit is gone.
The forum support is bad: You get an answer to almost every posted question. But that answer often does not help. They ask you things such as “why do you want to do that”. Or they say: “use our tool and do XYZ with it” three times, although again and again I told them this suggestion does not work. After a few answers to a question the final answer is: “you need training, buy our support”.
The commercial support is way to expensive (costs approximately as much as the SmartGWT license).
We will probably not use the server-side integration of SmartGWT again.
You can read all my "lessons learned" with Pros and Cons at my blog:
http://www.kai-waehner.de/blog/2010/12/11/lessons-learned-smartgwt-2-3-component-library-for-google-web-toolkit-gwt/
Best regards,
Kai Wähner
Do you feel that the provided widgets
are integrated well? Is there any
widget you miss in particular?
You could create any missed widgets, there is no single framework that can provide everything you want. The widgets are pretty extendable.
Is the datasource integration as usefull as the smartClient team claims?
The data (JSON/XML) can be provided by servlet services, and they are understood by the
widgets.
What methods do you use to make your smartGWT application persistent? e.g. How well do
Hibernate and smartGWT play with each other?
In the backend servlet services of GWT, you can persist your data in the store by using any persistent layer in Java. Hibernate can be just used as same as normal java app.
Do you feel that the provided widgets are integrated well? Is there any widget you miss in particular?
Yes. The widgets have a consistent API and work well together.
Is the datasource integration as usefull as the smartClient team claims?
This IMO is one of their strongest feature. Once you start using their Datasource API you realize how little code is required to get a fully functional CRUD screen
What methods do you use to make your smartGWT application persistent? e.g. How well do Hibernate and smartGWT play with each other?
Hibernate works out of the box with the SmartGWT EE version. With the LGPL version using Glead works wells
I think SmartGWT has a ton of great widgets, but but but there is a HUGE price.
Create a simple SmartGWT based project and watch how many files get loaded by your page.
That, I think, is totally against the ideals of something like GWT. While SmartGWT may be a pretty good option for people on a deadline, if you want raw performance, stay away from it.
The number of HTTP requests will simply kill your application.
Have you encountered any problems when designing your application that were caused by the framework?
Yes. When I combined Google Eclipse plugin, SmartGWT, GWT 1.6.4, and Wicket the gwt compiler would emit bad javascript. By bad javascript, I mean javascrip that would not work in webkit, or firefox. I was not able to get good javascript until I removed it completely from the Eclipse project and restarted Eclipse. So, this combination would not work and I ended up building the SmartGWT piece separately in another project. The other issue is that the Smart client seems to want control of the whole page in a css sense. So, the integrated SmartGWT module was all messed up, because styles were not isolated properly. Your mileage may vary.
Personally if you use SmartGWT only and for everything then all will most likely be fine, but if you try and mix it, well my results were disastrous. So, I no longer use it.
Just as a counterpoint to the poster above who mentioned troubles with Wicket, the SmartClient forums (forums.smartclient.com) have reports of success integrating SmartGWT with a wide variety of other technologies. This poster's problems sound like 1) a GWT bug causing bad JavaScript and 2) CSS naming conflicts between SmartGWT and Wicket, probably neither framework's fault. All of SmartGWT's style names can be renamed via the skinning system to resolve any such conflict.