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.
Related
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.
I'm currently exploring similar alternatives to Ruby on Rails, and have been considering Playframework using Scala (cuz I'm not fond of Java).
Problem is, even if the default sample of application works very fine, everytime I try doing actual work with Playframework, it end up with it not answering HTTP requests.
It compiles after the first request, but doesn't answer it.
Then it ignores every other request (not even re-compiling when I changed stuff).
It does kick out an user typing an incorrect request, but it never times you out if the request is correct.
What is this ?
I'm using Playframework 1.2.3 with the Scala module. Is there any way to get a better insight at what's happening ?
So it never times out, isn't it? as if it was compiling forever?
If yes, maybe you have problems with the Scala compiler which is slower than Java compiler and requires more stack. Generally if you don't have enough stack, it should crash with a StackOverflow.
YOu can try to run play with "play run -Xss1024k" for example to increase the stack size.
If you get empty answer, it means the problem is somewhere else like routes or bad object returned from your controller.
Anyway, Play-Scala is still young and in evolution so it's not a reliable solution for an entreprise solution if you're not yet an expert in Scala and don't already know Play IMO. It's already robust and stable but not well documented and as complete as Java version.
Finally, you say you're not found of Java and it's something I can understand but you should really give a try to Play/Java since it's completely different from any other Java stuff. I can say that because I'm an old Java developer and find the language getting a bit outdated in its syntax and basic features. I don't really like Java EE web frameworks in general because they are not really productive and user-friendly. When I found Play more than one year ago, it was like a breath of air for me. You get the best of modern web frameworks and the best of the Java world which are all the robust and approved entreprise tools coming from opensource. I've never been deceived by it since this time.
I recently added GWT to our project to implement an Ajax feature of our web app. The other devs are complaining about the extra time GWT compile adds to the build and are asking why I didn't use JSON and jQuery instead. What should I tell them?
Try to make the build smarter, if it isn't already: The GWT (client) part should only be re-compiled, when the client source changes. I assume, it's mostly you who changes that source, so the other developers won't experience the pain.
Caveat: This doesn't work of course, if your client source shares code with the existing project (I assume, it's a Java project on the server side?). But maybe you should avoid shared code in your case: Even though that's violating the DRY (Don't Repeat Yourself) principle, realize that you'd violate it anyway, if you didn't use GWT.
However, if you do reuse code from the server project, then you have a good argument, why you used GWT.
If developers have to compile the whole GWT stuff (all the permutations) in order to develop application it is real pain. Starting from GWT 2 you can configure the webapp project to be run in "development mode". It can be started directly from eclipse (Google plugin) thanks to built in jetty container. In such scenario only requested resources are compiled, and the process is incremental. I find this very convenient - GWT compilation overhead in our seam+richfaces+GWT application is very small during development cycle.
When it comes to application builds there are several options which can speed up GWT compilation. Here is checklist:
disable soyc reports
enable draftCompile flag which skips some optimization
by adjusting localWorkers flag you can speed things a bit when building on multi-core CPU
compile limited set of permutation: e.g. only for browsers used during development and only for one language
Release builds of the webapp should have draftCompile disabled though. Also all the laguage variants should be enabled. Maven profiles are very useful for parametrization of builds.
What was the reason you used GWT instead of JSON/jQuery?
I would ask the same question since for what you need, GWT may not be legitimately needed.
In my experience, I totally understand the complaints you are getting. GWT is a wonderful technology, and it has many benefits. It also has downsides and one of them is long compile time. The GWT compiler does lots of static code analysis and it's not something that has an order-of-magnitude solution.
As a developer, the most frustrating thing in the world is long development-deploy-test cycles. I know how your developers feel.
You need to make an architectural decision if the technological benefits of GWT are worth it. If they are, your developers will need to get used to the technology, and there are many solutions which can make the development much easier.
If there was a good reason for using GWT instead of pure javascript, you should tell them this reason (skills, debugging for a very hard to implement problem, you didn't want to deal with browser compatibility, etc). If there is no good reason, maybe they're right to be upset.
I use GWT myself and I know about this compile time :-)
If you used GWT for an easy-to-implement-in-javascript widget or something like that, maybe you should have consider using javascript instead.
What tool you're using to compile project?
Long time ago I've used ant and it was smart enough to find out that, when none of source files for GWT app (client code) has changed, the GWT compiler task was not called.
However, after that I've used maven and it was real pain, because it's plugin didn't recognize the code hasn't changed and GWT compilation was run all and over, no matter if it was needed or not.
I would recommend ant for GWT projects. Alternative would be rewriting the maven plugin or getting developers used to long compile time.
I'm planning on starting a new project, and am evaluating various web frameworks. There is one that I'm seriously considering, but I worry about its lasting power.
When choosing a web framework, what should I look for when deciding what to go with?
Here's what I have noticed with the framework I'm looking at:
Small community. There are only a few messages on the users list each day
No news on the "news" page since the previous release, over 6 months ago
No svn commits in the last 30 days
Good documentation, but wiki not updated since previous release
Most recent release still not in a maven repository
It is not the officially sanctioned Java EE framework, but I've seen several people mention it as a good solution in answers to various questions on Stack Overflow.
I'm not going to say which framework I'm looking at, because I don't want this to get into a framework war. I want to know what other aspects of the project I should look at in my evaluation of risk. This should apply to other areas besides just Java EE web, like ORM, etc.
I'll say that so-called "dead" projects are not that great a danger as long as the project itself is solid and you like it. The thing is that if the library or framework already does everything you can think you want, then it's not such a big deal. If you get a stable project up and running then you should be done thinking about the framework (done!) and focus only on your webapp. You shouldn't be required to update the framework itself with the latest release every month.
Personally, I think the most important point is that you find one that is intuitive to your project. What makes the most sense? MVC? Should each element in the URL be a separate object? How would interactivity (AJAX) work? It makes no sense to pick something just because it's an "industry standard" or because it's used by a lot of big-name sites. Maybe they chose it for needs entirely different from yours. Read the tutorials for each framework and be critical. If it doesn't gel with your way of thinking, or you have seen it done more elegantly, then move on. What you are considering here is the design and good design is tantamount for staying flexible and scalable. There's hundreds of web frameworks out there, old and new, in every language. You're bound to find half a dozen that works just the way you want to think in your project.
Points I consider mandatory:
Extensible through plug-ins: check if there's already plug-ins for various middleware tasks such as memcache, gzip, OpenID, AJAX goodness, etc.
Simplicity and modularity: the more complex, the steeper the learning curve and the less you can trust its stability; the more "locked" to specific technologies, the higher the chances that you'll end up with a chain around your ankle.
Database agnostic: can you use sqlite3 for development and then switch to your production DB by changing a single line of code or configuration?
Platform agnostic: can you run it on Apache, lighttpd, etc.? Could you port it to run in a cloud?
Template agnostic: can you switch out the template system? Let's say you hire dedicated designers and they really want to go with something else.
Documentation: I am not that strict if it's open-source, but there would need to be enough official documentation to enable me to fully understand how to write my own plug-ins, for example. Also look to see if there's source code of working sites using the same framework.
License and source code: do you have access to the source code and are you allowed to modify it? Consider if you can use it commercially! (Even if you have no current plans to do that currently.)
All in all: flexibility. If I am satisfied with all four points, I'm pretty much done. Notice how I didn't have anything about "deadness" in there? If the core design is good and there's easily installable plug-ins for doing every web-dev 3.0-beta buzzword thing you want to do, then I don't care if the last SVN commit was in 2006.
Here are the things I look for in a framework before I decide to use it for a production environment project:
Plenty of well laid out and written documentation. Bad documentation just means I'm wasting time trying to find how everything works. This is OK if I am playing around with some cool new micro framework or something else, but not when it's for a client.
A decently sized community so that you can ask questions, etc. A fun and active IRC channel is a big plus.
Constant iteration of the product. Are bugs being closed or opened on a daily/weekly basis? Probably a good sign.
I can go through the code of the framework and understand what's going on. Good framework code means that the projects longterm life has a better chance of success.
I enjoy working with it. If I play with it for a few hours and it's the worst time of my life, I sure as hell won't be using it for a client.
I can go on, but those are some primary ones off the top of my head.
Besides looking at the framework, you also need to consider a lot of things about yourself (and any other team members) when evaluating the risks:
If the framework is a new, immature, "bleeding-edge" framework, are you going to be willing and able to debug it and fix or work around whatever problems you encounter?
If there is a small community, you'll have to do a lot of this debugging and diagnosis yourself. Will you have time to do that and still meet whatever deadlines you may have?
Have you looked at the framework yourself to determine how good it is, or are you willing to rely on what others say about it? Why do you trust their judgment?
Why do you want to use this rather than the "officially sanctioned Java EE framework"? Is it a pragmatic reason, or just a desire to try something new?
If problems with the framework cause you to miss deadlines or deliver a poor product, how will you talk about it with your boss or customer?
All the signs you've cited could be bad news for your framework choice.
Another thing that I look for are books available at Amazon and such. If there's good documentation available, it means that authors believe it has traction and you'll be able to find users that know it.
The only saving grace I can think of is relative maturity. If the framework or open source component is mature, there's a chance that it does the job as written and doesn't require further extension.
There should still be a bug tracker with some evidence of activity, because no software is without bugs (except for mine). But it need not be a gusher of requests in that case.
I keep reading the developments being done on frameworks like Grails and other Java frameworks but not much of a buzz in the Lift camp. And also Lift 1.0 was announced long back. Is the community working on Lift framework? What are the future prospects of the framework? Is it better than Grails and other Java frameworks? (Groovy being less performing than Scala).
I'm on the lift list, and get quite a few emails per day. Quite a lot of interesting discussions, and M8 just rolled out.
So, in addition to the mailing list, looking at the wiki, and the github repository you'll find all kinds of stuff.
From the little I read recently, Lift 1.1 should probably be out before Scala 2.8. As in, real soon now. There is a lot of activity on the Lift front, but they really do seem to be a bit more insular than other projects. I hear way more about Akka than about Lift, which I find really surprising. In fact, I hear way more about the general support of the Lift community for non-Lift Scala projects than I hear about Lift itself.
It's not that they aren't receptive and newbie-friendly or anything like that. I think it is just a matter of not having many personalities that are talkative about what they do, or, perhaps, those personalities are just in completely different circles than the ones I follow on the Internet.
It does bother me a bit that they don't have anyone strong here on Stack Overflow. If you compare the answers from Scala related question to those of Scala & Lift related questions, the difference is striking.
Update Nov 16, 2010
Just to update, Lift 2.0 was released and only works with Scala 2.7.7. Lift 2.1 followed it, though, and is available for both 2.7.7 and 2.8.0 (I suppose it works with 2.8.1 as well, but I haven't tested that). Beyond that, there's already a milestone available for Lift 2.2, so everything is going just fine.
There's a very active mailing list for lift. Perhaps you could peruse its archives and send an inquiry there if you're not satisfied with what you find.
I've some experience with Grails and looked at Lift recently, but I find the programming model of lift somewhat strange and unintuitive. I'd prefer Scala over Groovy, but I'd choose Grails though (which has a Scala plug-in). Grails offers much more than Lift does. Grails is developed by SpringSource whereas no big company is behind Lift.
If you simply want to develop web applications choose Grails. If you're a Scala enthusiast go with Lift.