Is Anyone Using the Google Web Toolkit? 470
eldavojohn writes "After seeing some applications from Google and participating in the Google Codejam (which seems to be built using the GWT), I kind of expected to see websites spring up left and right based off the GWT. Well, it's been a year and a half since they open sourced it and I have to admit that I am more than a little disappointed by its low profile in the UI community. I've been trolling their blog and have seen a few books out on it. But the one thing I'm not seeing is its use outside of Google. I've worked through the examples and tutorials at home and though I've been impressed with the speed, I am disturbed by the actual result — a whole ton of generated Javascript. But this is the first UI technology I've found where I can write in the native language of the server (Java) to generate and unit-test the UI code. Aside from Google's use and the games of Ryan Dewsbury like KDice & GPokr, does anyone know of major sites using the GWT? If you don't and you've used it yourself, why isn't it taking off? Is it too immature? Is it a solution to a problem that already has too many solutions? Is it fundamentally lacking in some way?"
Why are you expecting this? (Score:5, Insightful)
Because a big company open sources something we're supposed drop what we're doing and run to the next best thing?
JavaScript libraries and toolkits multiply faster than rabbits, there's a new "framework" coming out each week, and some of them had strong developer support (i.e. people willing to answer my stupid questions in forums) long before Google came out with their stuff.
Not that it's bad or anything, but in the end it's all JavaScript anyway, and learning two different ways to get to the same goal (an interactive site) is generally pretty low on everybody's priority list.
Are you using Google Sparse Hash by the way? Why not?
The secret shame of Web 2.0 (Score:5, Insightful)
is that everyone wants to roll their own.
We had a POC Report Designer (Score:5, Insightful)
We built a Proof of Concept Report Designer and Report Viewer on top of BIRT using GWT for the interface. It had some cool features, like multi-user real-time report development, versioning, and tie ins to the commercial report repository that the company that built BIRT sells. It had a real nice WOW factor to it, but in the end, it was just a pretty POC that we could show at conferences, it would never replace the desktop version due to responsiveness (imagine, an Eclipse app that is more responsive than something else...) IMHO, web technology is just catching up in the UI space to where desktop apps were like 15 years ago, and Web 2.0 is still a tacky buzzword. To do some things that are trivial in a desktop app requires a lot of convoluted steps (callbacks, etc). And even things that would be done the same way still requires a network round trip to get information that desktop apps don't suffer (simple tasks like dynamic drop-down or list population). GWT is a step in the right direction, and the ability to debug in an IDE both client and server side components is very nice.
Re:The secret shame of Web 2.0 (Score:5, Insightful)
Mostly because no one's really gotten it right yet.
That, and we still don't have any set of frameworks which have built up enough to be difficult to replace. Nothing close to, say, GTK+, Qt, WinForms, Cocoa, etc.
Why the conclusions? (Score:2, Insightful)
There are more than 67 million businesses in the world and I wonder how many of those you have polled. Can you tell us how many of those businesses you have surveyed?
If you don't and you've used it yourself, why isn't it taking off? Is it too immature?
If you are asking a question and providing the answer, I wonder why you even ask.
In your submission, you should at least have informed us about Google's view on this issue is, if you wanted us to take you serious. Be serious please.
As a Software Development student (Score:4, Insightful)
Just a few weeks ago, I had an itch to scratch, so I figured I'd bang out a quick fix in my most well known language, Java (I started Java around early 1.4 days back in high school, as they were fading out C++, although I passed the AP test in C++ the last year it was given in that language). I figured I'd expand my horizons a bit and learn Java Enterprise, as I already have a really solid background in Standard Edition. After compiling a JBoss server, Ant, and getting JBoss studio (read: a day later), I decided to jump right in. Several hours later and a trip to the book store later, I realized that I needed more background info and got the hardcopy version of the Java EE Tutorial. It assumes that you know, XML, RPC, SQL, Hibernate, ODBC, etc. I've got experience with a good deal of it, and it's still a daunting task to learn just the architecture of the Java EE suite. This is before even thinking about writing a bit of code. The amount of time that you have to invest and the steepness of the learning curve is, frankly, intimidating!
My Eclipse install is a gigabyte, ATM, I've got about 10 IDEs, 3 SQL servers, and a directory called 'programming' with a range of tools and a sub directory called 'libraries' which has SDKs that I've downloaded and intend to getting around to trying. I bought Flex2 and Expression Studio last summer and have barely had time to play with them, and both have new versions out already. Then I've the SDK for Android, Flex (looks like another month of studying the architecture just to hit the ground running), and AIR, all sitting around for me to have time to play with them, before they're obsolete. Not to mention another Java release in the wings.
There are simply too many frameworks, languages, and methods for anyone to be well versed in more than a small number of them. And they come and go so quickly, I don't know if I should invest time in what might become the next Laszlo (looked really, really, cool - never got any traction). Google offers APIs and SDKs in what, half a dozen languages, and half of them are just interfaces to XML? What's wrong with libcurl?
I've only got so much time, and lately everything falls in to one of three categories, "cool, and worth the time investment", "cool, but probably only for my own hacking around", and "...what the crap does it do?".
Am I the only one with this issue? I admit, I spend a lot of time playing with Linux distros, too, so I have less time than others. Oh, yeah, and the four or five languages I'm expected to use every semester, and the three or four that I use at work on a monthly basis.
Re:It's used... (Score:5, Insightful)
On a personal level, I'd rather see the effort spent learning GWT applied to learning Javascript and the web technologies instead. There are a lot of frameworks out there, but none of them are actually needed in 90% of the cases. What we actually need are programmers who know how to write maintainable and highly interactive Javascript components for their sites. Such knowledge allows them to get the job done faster than mucking about with Yet Another Framework(TM) designed to take a cannon to the problem of killing a fly.
It's not learning Javascript that's the big obstacle to coding your own solutions sans framework; it's dealing with the browser compatibility issues. Frameworks largely compensate for that.
If you write your own non-trivial Javascript code, you have to test on IE 6/7/8, FF 2/3, Opera 9.whatever, Safari 2/3, etc etc etc etc.
Re:To me, (Score:5, Insightful)
It's not about valid code, it's about accessibility.
Your attitude is the same as some dick opening a shop with spiral stairs leading up to it 'cos it's prettier, right?' Yeah, except for those wheelchair users.
There not be many disabled people compared to 'able', but if you ever become disabled one day, you'll be shouting from the roof for more accessibility just like all the rest.
Re:The secret shame of Web 2.0 (Score:3, Insightful)
The barrier to entry for web development (even web 2.0) is much lower than your standard desktop environment. You can build damn near anything out of a dozen components (tags) and a little more than two dozen properties (styles).
So, where's the question? (Score:5, Insightful)
You start with the assumption it should be widespread, and are disappointed because it is not. Which leads to the question, what leads you to that assumption?
Re:To me, (Score:3, Insightful)
To me, the biggest problem is abolutely no fallback to non-javascript browsers. I'm not so much worried about users, but search engine bots won't be able to spider me and drive traffic to me.
Your issue has nothing to do with GWT. JavaScript only has fallback for non-JavaScript browsers if you write fallback HTML; and GWT is no different.
The same applies for spiders; your content (either static or dynamic) needs to be in the HTML part in order for a spider to see it. If your content is loaded dynamically through AJAX then no spider will see it.
For fallback and spiders, JavaScript (either hand-written or compiled from GWT) can manipulate pre-rendered HTML. The pre-rendered HTML can either be static or dynamically-generated from PHP, Ruby, C#, brainf*ck, ect, ect...
Re:As a Software Development student (Score:5, Insightful)
As a student, don't bother learning frameworks with the idea that you will use them later. There are only two good reasons to learn a framework. The first is to use it right away on a project you want to get done. The second is to get experience with frameworks in general and particular types of frameworks. It is valuable to be able to:
Knowing a framework is, in itself, pretty useless unless you are going to use it right away or apply for one of those mythical Monster.com jobs where companies hire people to work with version 2.37a of Ridiculously Specific Technology Z. I don't know of any companies that actually hire that way unless they need a consultant to work with a legacy system whose developers have long since disappeared. In other words, you won't be hired for your experience with a specific framework until that framework is obsolete.
Now, setting aside the proper way to study frameworks, why are you even thinking about frameworks as an "investment" at your age? You sound like you're in way too much of a hurry. If you learn one distributed N-tier application framework, one web application framework, and one rich client application framework, then you will have much more industrial-type experience than most developers ten years older than you. The downside is that industrial-type experience, while it helps you make better decisions about large-scale software development, also tends to dull your brain. If you're already focusing on frameworks in college, you're going to be burned out and useless by the time you're thirty. You'll end up quitting and starting over from scratch in a new career, just to get away from software. Unless you're just one of those precociously responsible (*cough* boring *cough* *cough*) kids who tracked his gas mileage in high school and thought the coolest thing about the Science Fair was having an excuse to wear a suit and gesture at graphs.
In college, you should be implementing your own language, becoming a whiz at Emacs Lisp, mucking with kernel modules, starting your own web business, building natural language parsers, and doing all the other silly, vain, perfectly useless (Emacs Lisp excluded) things that end up making you into a smart, versatile programmer.
Re:As a Software Development student (Score:5, Insightful)
As a software development *student*, you should be focusing more on the concepts, on engineering problem solving, and on reasoning skills than on the specific technologies.
As a software engineering professional, I learn the tools that I need to effectively do my job. I learn things that look interesting and applicable to whatever it is I am doing. Thus, I work with the GWT and with AJAX because I decided that's what I needed in order to tackle a problem we were having. As a senior engineer who is engaged in the hiring process, I care more about that you can think than that you happen to have seen and worked with twelve dozen technologies by the time you graduated. As a job posting I saw recently says [fogcreek.com]:
You can't predict it and the specific tools will change tomorrow, so as a student I would generally say that learning it--unless it is for a specific project or class of projects, or because it contains a concept or problem solving idea that you want to learn--is a waste of time. I learned R back in school because it was more efficient than using Minitab for multivariate statistics and for statistical modeling, not because it was out there and I needed to put it on my resume. On the latter point, I still think learning Prolog and LISP were extremely valuable despite that I never use them professionally and will probably never use them professionally.
Incidentally, if you are a good engineer, the language doesn't matter. If you are a bad engineer, the language still doesn't matter. *Problem solving* counts for more in the long run than bullet points.
Re:The secret shame of Web 2.0 (Score:0, Insightful)
The secret shame of Web 2.0^W^W^W^W programming in general
The secret programming in general
You're doing it wrong. ^W means delete previous word. Maybe you're looking for ^H which deletes the previous character?
too few know GWT for "multi" developer projects (Score:1, Insightful)
I used it back in Oct 2007 to develop an internal CDN monitor and control tool. It is used internally, and that project was used to see how well it worked.
Since then GWT 1.5 can come out, and it seems even better now. The reason it isn't used externally yet at my place it the "external" projects involve several developers, and they are too tied to the old ways (raw Java-script) to try something new.
(I honestly think part of it is, java-script is a maintenance nightmare, and thus "job security" for those people.)
I fully expect GWT to be used more, but it is being held back from "large" projects because not enough developers know it yet.
Re:Why are you expecting this? (Score:5, Insightful)
GWT is NOT a Javascript library! It's a Java library and a Java-to-Javascript compiler; it saves you from having to learn or work with Javascript at all. This means that you write your client in Java, same as your server-side code, and get to use a real Java debugger.
Re:Why are you expecting this? (Score:5, Insightful)
Re:The secret shame of Web 2.0 (Score:1, Insightful)
Quite possibly because trying to build a rich user interface in a web browser is a stupid idea.
Progressive Enhancement (Score:5, Insightful)
http://en.wikipedia.org/wiki/Progressive_Enhancement [wikipedia.org]
When building sites I start with the plain HTML, make it usable, and then use statically linked JavaScript to start rewriting the page with the bells and whistles when the page loads. That way, if JS is not enabled the reader doesn't get the 'enhancements' but the core functionality is still there.
Re:There are GWT apps, but not in the public web (Score:5, Insightful)
I couldn't agree more. There 2 very different ways to use Ajax:
1) have a traditional site and embed small "Ajax goodies" here and there, like digg does with comments.
2) have a 100% Ajax site, like GMail.
Cleary, GWT is good for (2), not (1). Now ask yourself, how many full Ajax sites do you know? GMail, Yahoo mail, a couple more? So it's not a problem with GWT, it's just that the idea of a full Ajax site is not suitable for the open web, it is much more useful for intranet and web-apps use.
Re:To me, (Score:4, Insightful)
Not only that, once you're in deep for a while you realize that "valid code" is a self-defined term. Do you mean w3c valid or microsoft valid or acid 4 valid? Even the developers of each browser have their own view of "valid," hence all the diversity.
Valid means "valid", which is not the same thing as "working", which is what you're talking about.
There's no such thing as microsoft valid or acid 4 valid html.
Re:Why are you expecting this? (Score:3, Insightful)
It is? Best tell that to all the banks, Google, corporations, ...
Re:The secret shame of Web 2.0 (Score:3, Insightful)
Surely that suggests that the design of your traditional GUI approach is wrong (and indeed modern GUI design is somewhat different to the approaches of yesteryear, involving many techniques borrowed from different domains).
Rich clients aren't meant to be like traditional applications either - they are supposed to be what their name suggests, ie a client to some remote functionality that gives a richer experience than a traditional web application.
How you expose that functionality is critical if you want users to make the most of your data and services, but that applies to web applications as well as desktop applications and rich clients. Perhaps you are just better at building web applications (as most enterprise developers naturally are at the moment from 15 years of webapp development)
Re:Why are you expecting this? (Score:4, Insightful)
A lot of them also write in Cobol, C#, Ada etc. Your point?
Java *is* used, and typically for the bits that joins all of the C/C++/Ada/Java/Cobol/Netezza/SQL/{{List_of_programming_languages}} components up.
Have you tried writing javascript? (Score:3, Insightful)
--Coder
Re:As a Software Development student (Score:3, Insightful)
Python.
Re:It's used... (Score:1, Insightful)
I don't understand why you're getting modded so high for these comments.
While I agree with some of what you say, the main attraction of using prototype - besides browsers compatibility issues - is that it's much more brief.
Almost all prototype methods return the element it's called on, which enable you to turn:
var ele = document.createElement('iframe');
ele.id = 'new_frame';
ele.className = 'shim';
ele.src = 'whatever.html';
ele.style.display = 'inline-block';
ele.style.backgroundColor = '#000';
document.body.appendChild(ele);
into:
document.body.append(new Element('div', {'class':'shim', 'id':'new_frame', 'src':'whatever.html'}).setStyle({display:'inline-block',backgroundColor:'#000'}));
So they got a method call wrong. Submit a patch.
Not only that, but the runtime patch approach to compatibility isn't something I've seen used a lot in prime-time. Don't get me wrong, it's obviously the ideal solution to browser incompatibility, but it seems to me to be more trouble than it's worth. It requires some architecture changes and a lot of the browser bugs are a total bitch to sniff. Besides, it doesn't even solve one of the main problems with javascript - it's extremely verbose nature.
BTW. If you want to do any real heavy lifting with prototype you better be aware of how scoping works.
Re:Why are you expecting this? (Score:1, Insightful)
GWT is NOT a Javascript library! It's a Java library and a Java-to-Javascript compiler; it saves you from having to learn or work with Javascript at all. This means that you write your client in Java, same as your server-side code, and get to use a real Java debugger.
So for all the Java programmers who need to bash together a UI, it's a dream come true.
For everyone who already does web design and development, it's pointless because they already know Javascript.
Re:To me, (Score:4, Insightful)
My problem stems from laws that require me to cater to people I may not even care about as customers.
For example, lets say I sell stairmasters. If I do not install a wheelchair ramp, I might get sued. Does that make any sense?
Re:Why are you expecting this? (Score:3, Insightful)
What about accessibility? That's a pretty huge gap. You're excluding a lot of users just to have whizzy controls, and for some industries it's the law that you have to have accessible Web pages.
Making a second set of pages for accessibility is a poor choice. And as a benefit of making pages accessible, they usually work well in mobile browsers.
This is why I don't use a comprehensive framework like GWT, aside from the lack of ultimate control over layout and functionality.
Re:It's used... (Score:3, Insightful)
The way we run it, we use a set version of the library for a page.
We decided to go wtih jquery + plugins. So for one site I use one version of jquery. We will not update that jquery for that site (baring security updates). If the customer needs more work done, we use that same version of jquery.
Now a new project needs done, now we move to a new version of jquery. When the customer needs a major design change, that is the time to change the tools. Otherwise, if it's not broke, don't fix it.
Re:Why are you expecting this? (Score:1, Insightful)
Perhaps this is the reason it hasn't taken off. Many web 2.0 sites strive to be agile and they can't really do that in Java.
You wouldn't write a web app in C++, so why would you want to write it in a language that was designed to replace C++?
Re:fr0sty piss (Score:5, Insightful)
I think the market has shifted a bit more than you're giving it credit for.
But it all depends on your niche.
We built our business on web retail and we still do an awful lot of it. And in that world, you simply cannot afford to lose a customer due to whatever whizbang technology you want to use at the moment.
But outside of retail is very different.
And the truth is, non-JS visitors and non-Flash visitors are the slimmest of minorities. 1-3% on average. If I was targeting the /. market I'd accommodate it. But for a general cross-section of the web? Javascript rules the day.
Re:Why are you expecting this? (Score:4, Insightful)
You wouldn't write a web app in C++, so why would you want to write it in a language that was designed to replace C++?
Wow, this comment I think wins the Best Java Troll on SlashDot for this month. There are so many logical fallacies in such a short sentence it almost boggles my mind to try to construct a response that sets the record straight. But to try to cut to the essence, Java solves many problems very well and is thus very widely used, and its technically pedigree is neither particularly rooted in C++ nor is it relevant to the decision to use the language.
Re:fr0sty piss (Score:3, Insightful)
>Not everyone needs AJAX.
To expand on this, not everyone needs Google's API to do AJAX. It's possible to write cross browser AJAX code and not end up with 10k of javascript. My own stuff ended up being 1.58k total.
This code reads xml (generated by server side processing on the fly), and generates large dynamic arrays of form controls, as well as the typical list population stuff. In my case, that's all I needed.
It will actually _add_ to a user's experience if they are on a slow modem, since the static html would be 100k +. The AJAX powered stuff is under 8k source they are downloading.
If I used googles API it would take 2-3x as long for someone on a slow connection. Anyone that's seen the broadband penetration numbers for the U.S. (just hit 50% in April) realizes that page size is, indeed, still important.
Add that fact to the fact that you become dependent on google's site being up when you use google's API to generate your interfaces, and it's simply not an attractive option for some (apparently most) people.
It's Google's API so it doesn't suprise me that they are just about the only one's using it. AJAX is Really Simple(tm) stuff. You are better off grokking it and writing the minimum you need to do the job.
I do use google maps though; that's cool stuff. However since my site will work if the map server dies, I don't feel so cagey about using it.
-Viz
Re: Is Anyone Using the Google Web Toolkit? (Score:1, Insightful)
There's a saying that "It's hard to teach the old dogs some new tricks" (or sth like that) and this also might apply here. But the major reason why the GWT isn't widely seen in use is I think the lack (for now at least) of a strong need for it. I mean, most web apps I see still don't rely heavily (not to mention entirely) on JavaScript where using GWT as an alternative might be a big win (in some cases). There are some exceptions of course: apps which involve some serious browser coding (like Gmail or Google Maps though none of them done with GWT) but they're still in minority.
So, in my opinion, the GWT is still waiting for its time to come, i.e some serious explosion of demand for desktop-like web apps in the browsers where it would justify the effort of learning & using it (of course for those who like Java/static typing/the tools around it and hate/don't want to learn JavaScript or get used to its dynamic functional-like nature).
Now, if it goes about some "major" web apps using GWT (besides those mentioned) I know of one more: Lombardi Blueprint [http://www.lombardisoftware.com/bpm-blueprint-product.php]. There's also a Google I/O 2008 session "Using GWT to Build a Diagramming Tool" done by the guys who build it [http://www.youtube.com/watch?v=xh5Vo_drhDE].
PS: sorry for my crappy English - it's not my native language.
Re:Why are you expecting this? (Score:3, Insightful)
We do tons of agile development in Java where I work. Being agile doesn't mean you can't use strongly typed languages.
Two More Answers... (Score:2, Insightful)
Most people that are in charge of project are not going to pick a "new and cool" component-based web framework like the GWT or Wicket simply because they are afraid of what they do not know. I am not talking about some guy providing professional services (those are the people mostly using Wicket and GWT actually) but about primary architects at medium to large corporations with multi-million dollar budgets.
Why do they not make what I think is the right choice? The fear is part of it of course, but these guys are good, smart professionals, so there must be another reason. I believe that reason is the glut of web frameworks currently available on the Java platform. Even evaluating one takes time a lot of these people do not have. If they cannot evaluate everything, they cannot agree on anything, so there is no industry wide consensus. Most of these people are very careful risk-averse individuals (a good trait to have for an engineer), and there we are.
Re:Why are you expecting this? (Score:4, Insightful)
Screw "basic"; if you're building an AJAX site, you want your javascript to be all-singing and all-dancing... and entirely reliable.
Writing for Java, you have static compile-time checking; you have 1001 different unit tests framework and code coverage frameworks and other tools you can use to help write reliable, production-quality software. For JavaScript, you have jack squat -- not even compile-time static checking. GWT solves that gap, providing a way to apply the same quality control tools and processes you have for your server-side code on your client-side code. As such, it's an extremely valuable tool in your toolkit.
Re:Why are you expecting this? (Score:4, Insightful)
You wouldn't write a web app in C++, so why would you want to write it in a language that was designed to replace C++?
Wow, this comment I think wins the Best Java Troll on SlashDot for this month.
That doesn't mean the troll is wrong! ;)