GWT just got a new look
gwtproject.org
gwtproject.org
> GWT is used by many products at Google, including Google AdWords and Google Wallet. It's open source, completely free, and used by thousands of enthusiastic developers around the world.
Any amount of things fit that description. Beer? Air? Clicking "Learn about GWT" gets you this:
> GWT is a development toolkit for building and optimizing complex browser-based applications.
That's all it takes! Can we please start seeing these kinds of descriptions on landing pages. You're not selling a clothing brand, you are selling a toolkit to developers: I care first and foremost what the thing does, not how fashionable it is.
The ones that seek to know more are the ones they want to engage.
Only my speculation.
GWT is a solution, not a community. It might have a community behind it, but some poor soul might land up on that page with the only intent of getting shit done within the scope of their own job.
The ultimate core goal of GWT is to save people time: that is why developers write frameworks. Why should someone have to waste time [struggle to learn the purpose of 'framework X'] in order to save time [use 'framework X'].
Saving people time starts on your landing page. They need to be able to accept or reject your framework with as little further research as possible. "This is what our product does, here are some people who use it, this is what people say." Once people know that you can carry on with the more floral explanations.
http://english.stackexchange.com/questions/38945/what-is-wro...
the way they are using it seems like their spell checker just changed the word from "performant" to "performance"
Being able to write the entire application, from the client and the domain model on down to the backend, in the same language, re-using classes across the entire application, is a big advantage.
In addition, being a very mature toolkit by now, GWT has A LOT of features to make life easier. Transparent RPC/serialization, code obfuscation/deobfuscation, IDE integrated debugging, i18n, resource bundling, code splitting, JavaScript interoperability, and a lot of other stuff.
Current project: Real-time multiplayer GTA-style game based on HTML5 canvas:
Yep, that's the problem. I had to learn GWT for a project last year and I don't share your enthusiasm. The learning curve is steep, integration with "the rest" of a Java EE application messy (but doable) and you still need a CSS expert. GWT is now a 'grown' framework. Many concepts have changed during the years and therefore many previous recommendations are obsolete nowadays. Documentation is meager. After a while I spent most of the time searching for the right code snippets on Stack Overflow.
Like any decent project.
As of doing everything in code - not necessary. As of now GWT has UiBinder - it is a kind of template or DOM + widgets, where you then bind code to it. But in upcoming 3.0 it will use web components standard (http://www.w3.org/TR/components-intro/)
1. RPC, which is in a way similar to RMI. It supports polymorphism, so you can get an interface in response and GWT will create correct implementation. Java is required on server.
2. RequestFactory, which is more focused on data transfer than implementation. It also allows to transfer data model, which in server is not compatible with GWT. Sends only delta of changes when sending back to server. Also requires Java on server.
3. REST. It is not maybe advertised that mutch, but GWT can work with any REST endpoint. It has built in JSON (de)serialization with AutoBeans; or you could also use Overlay types. There also some third party libraries for REST. This time server can be anything, just to return JSON.
But if you really want to have sibling component on the server side, then there is Vaadin - a framework built on top of GWT which has server-side components which synchronize with client-side counterparts. But then, all handlers are on server, rather than client as with GWT.
Seriously? First I've heard this is how you pronounce it. And how does one pronounce gwit? I think I'll continue to call it: G.W.T.
Obviously "gwit" is pronounced as "jwit", right?
Not that I have any stake in it, but the most confusing thing to me is that it doesn't mention the words "Google Web Toolkit" until the Tutorial page. It's an abbreviation; one that describes the product quite well (a toolkit for web apps, built by Google). Silly to bury it.
1. client-side (javascript) database access
2. automatic updates to the client's view of the database
And also:
3. automatic optimal re-execution of javascript code whenever something changes in the input (e.g., the database). Note the word "optimal", e.g., no glitches, and no (or minimal) unnecessary work done.
Of course, it should be fast :) Does anybody know where to find such a toolbox, or libraries that allow me to accomplish the above? Any pointers are greatly appreciated!
> These are the main bottlenecks when scaling Meteor, and they introduce two main issues: 1. The polling and comparing logic takes a lot of CPU power and network I/O. 2. After a write operation, there is no way to propagate changes to other Meteor instances in real-time. Changes will only be noticed the next time Meteor polls (~10 seconds).
This seems like quite a limitation. So I wonder if there are any libraries out there that successfully solved this?
These two steps of the Meteor tutorial probably describe it best: https://www.meteor.com/try/10 https://www.meteor.com/try/11
If you have any question with "javascript" anywhere in there GWT is not the answer, unless it's "how can I avoid javascript alltogether ?" (a common question for me and a lot of others).
GWT is a crosscompiler, RPC generator and UI toolkit. That means :
1) Crosscompiler: all code is in Java (and you can pick what code runs client-side). You write browser applications in Java, instead of Javascript. It's not emulated. The client-side javascript is not large (like asm.js stuff), doesn't require plugin downloads that don't work on half the platforms (flash, ms stuff, ...), it's not limited (like most of the javascript frameworks that are advised here that won't work for graphs in canvas ...), ...
TLDR: it's cross-platform, resulting application can work on all browsers, and everything else (e.g. native Android/iOS/Windows/...) (even IE6 if you really want).
2) RPC generator: you can call server-side methods that are also in Java. You can call them as if they are local methods, except that they can execute asynchronously and they can fail with network-related exceptions. This means you don't do it yourself, meaning no work and no errors.
This means that using any java-accessible code on the server in your in-browser applications is trivial.
3) A powerful desktop-like UI toolkit that works well. GWT is "Delphi/Visual Basic/Visual C++/..." with Java as the backing language on the web. https://www.youtube.com/watch?v=kV5H3rGfqOE
4) It's java. The same code works on Android, works on iOS, works in Windows, works on linux native, works on ... and works in the web browser (though you'll have to use different UI toolkits. But in a well-designed application, MVC, only the V needs to be platform-specific).
5) Because reusable code is actually possible in this UI toolkit, you find graphing libraries/controls/... that work well within the toolkit and that work together and you can usually get support for (e.g. Vaadin).
Making client-side Models and Controllers that work on all platforms is very easy (with a little discipline). Making sure that code stays in sync across all platforms is trivial (java is statically typed. Add a new field, and forget to add it on one platform, boom, compile fails).
The big disadvantages :
The big one : Java is a language that is made primarily to allow you to manage complexity in large applications. There is a lot of "default" complexity and lots and lots of tools to manage and refactor large codebases. Java itself is a static language with access controls and many tools to help you. That means that GWT-Java based applications can be a LOT larger than anything you'll ever write in Javascript. This also means that this is meant for large applications. You will find it less helpful for small applications.
You can't use javascript frameworks easily (but it's possible).
It's possible to not use the UI toolkit, but it requires lots of inside knowledge.
You have no easy control over the generated javascript (again, possible, but if you don't know compilers, you may want to avoid this).
You have very indirect control over the DOM elements in your web page. If this is important to you, life's gonna suck.
It's java, not many people would call this their favorite language.
I like web dev environments that use the same language on both client and server sides: Meteor, Clojure + ClojureScript, and GWT. I need to use several programming languages and there is always a small overhead for me when switching languages.
One of the most important new features are javascript interopt, which enables you to write libraries in java and let other people use it like any other js library. In the other direction, you can easily use javascript (libraries) in java. That means it's possible to just use modern stuff like polymer from within gwt without much of a hassle.
Parts of the page are still rather outdated and haven't really been touched since 2010/ 2012.
This is why it's so great that the site got a new look now, it indicates that things are moving again and I'm sure the outdated parts are going to be removed soon.
EDIT: Nevermind, found a list here: http://gwtreferencelist.appspot.com/
AdWords UI AdSense UI Blogger Groups Doclist Parts of Maps / Geo
according to https://groups.google.com/forum/#!msg/google-web-toolkit/Mjj...
Their case studies page has a few more: http://www.gwtproject.org/casestudies.html
https://news.ycombinator.com/item?id=8554339
Other references mentioned by the poster are "Apple (iAds Workspace), Amazon (AWS Console), Nike".
I guess its good of you hate html and javascript. But once you grow up and realise your making a web page and need to control the DOM in a particular way, it just gets in your way.
- http://trends.builtwith.com/websitelist/Google-Web-Toolkit - but this might be seriously underestimated, as they are not able to detect services accessible after login, where GWT is mostly used.
- http://ars-codia.raphaelbauer.com/2011/12/why-google-web-too...
Other that I'm aware of:
- https://ruxit.com/ - their service once you log in
- http://gogrid.com/ - again after login
- Angry Birds web version
- web mail at http://wp.pl (one of the major mail services in Poland)
While it's funny (and sometimes silly) to see a huge amount of .js libraries popping up, they're not adding a big block between the programmer and the browser.
And js may have its quirks, but it's not java and I'm thankful for that. I'd rather use js over java anyday, unless there's something really dependent on it.