Slashdot Mirror
Is Anyone Using the Google Web Toolkit?
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?"
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?
is that everyone wants to roll their own.
How we know is more important than what we know.
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.
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.
OtakuBooty.com: Smart, funny, sexy nerds.
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.
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?
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.
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:
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.
Integrate Keynote and LaTeX
http://en.wikipedia.org/wiki/Progressive_Enhancement
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.
Stupid flounders!
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.
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.