Gah! Again! People not explaining what something is on the landing page!
> 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.
Not even that is enough. My train of thought was: "This is the Java thing, right?" But I wasn't sure, and it's not mentioned anywhere in the opening paragraph of that page either. Java is not mentioned until "The GWT SDK contains the Java API libraries, compiler, and development server."
That might be on purpose. Way too many people (even seasoned Java pros) tend to dismiss GWT based on the WRONG assumption that "GWT runs on Java".
Not mentioning Java in the very first sentence might by an attempt to avoid this seemingly minor yet critically important misconception.
I still don't quite grok GWT, even having known about it for something like a decade. Is it a web application frontend thing that compiles Java to JavaScript?
Basically yes, you write in Java and it compiles it full-client side JavaScript application. But it also has a lot of goodies, like "templating" or rather binding DOM to code, internationalization, code splitting (so not everything is loaded upfront), client-server communication and other things needed in front development. You typically develop one-page applications with it (fully client side).
When I see a landing page like this, I feel that this is their filter. If you are interested in knowing more, you will seek the answers. Otherwise, you will move on to the next HN post...
The ones that seek to know more are the ones they want to engage.
> The ones that seek to know more are the ones they want to engage.
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.
Grammar question from this non-native English speaker: does it sound right to say "you can quickly develop performance AJAX applications"? Wouldn't you say something like "high-performance AJAX applications" or "highly performant AJAX applications" (or just "performant AJAX applications")? It seems to be missing something.
Been using GWT for almost a decade. It makes it easy to develop and maintain enormous and complex web applications, which would otherwise be difficult if you had to rely only on JavaScript (both the language and the toolchain).
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:
> * GWT has A LOT of features ... and a lot of other stuff.*
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.
I've never used GWT, but it looks a lot like ASP.NET (all the button declarations in code, heavy page lifecycle in code, etc.). Can anyone with ASP.NET knowledge comment on that? ASP.NET has many problems, there are valid reasons why most developers are moving towards ASP.NET MVC so I wonder what is the place for GWT in modern web dev.
First difference is that ASP.NET is running on the server side. GWT is fully compiled to JavaScript and runs in browser. The server doesn't even need to be Java, can be even plain web server without server side code. With GWT you typically develop one-page web applications.
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/)
No, not at all. There is no concept of a component on the server side in GWT. For GWT server is like a second tier, similar as you would write in JavaScript. Though, GWT gives you few ways to communicate with server:
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.
Yes, seriously (at least that's what I heard people at Google calling it). How many different ways could you pronounce "gwit"? (If you really don't get it, it's like "quit" but with a voiced consonant at the beginning).
I was seeing it as gee-wit. jwit also comes to mind.
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.
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!
Thanks for that link. I did a bit of reading, and found this [1].
> 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?
Specifically about this issue, see the section about the MongoDB oplog further down in the article. This removes the polling interval/overhead, so should significantly improve performance and responsiveness.
Ok. It indeed seems to be the case that the polling delay can be eliminated. But I'm wondering, if db-changes are written to the client directly, is it still possible to apply security rules to that? Evidently, I don't want all my db-changes to be written to all clients, and, preferably, a security-filter should be able to determine which clients receive which updates.
Yeah - the very earliest preview versions of Meteor had this obvious gap where reads and writes were basically a free for all. However, it's changed a lot since then. As a development crutch the aptly-named 'insecure' package is installed by default (which maintains the free for all), but you're expected to remove it and able to apply fine-grained control to which clients can C/R/U/D which data.
I'm looking for a solution that allows database access from the client (the browser) directly. As far as I know, you can't run PHP on the client (at least efficiently).
Since there are a million "what is GWT" questions, let me give a thorough answer :
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.
Thanks for that information. I used GWT on two personal projects years ago and for customer work three years ago. The only thing that I didn't like we're the long build times.
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.
It's not exactly been bleeding edge the past few years. Now with the 2.7 release and the 3.0 release (which is hopefully coming very soon) it's receiving a major revival.
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.
No, currently it's 1.7 (with gwt2.7.0) and soon (when gwt 3.0.0 is released) it will support java 8.
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.
I used it for about 8 months, Hated it. Its like a big wall between you and the DOM.
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.
Though it's worth noting that Inbox and similar properties do not use it for UI code, but only (exclusively) for business logic below the UI layer. UI code is written in pure JavaScript/Closure.
Moreover Newsdesk, a reasonably large media monitoring platform is pretty much solely based on GWT, though it looks like they are moving away from it in their new development.
Seems to me the textbook example of Java people trying to make everything Java (and failing at it, as usual)
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.
> 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.