Slashdot Mirror
Google Web Toolkit Now 100% Open Source
chrisd writes "When we first released the Google Web Toolkit (GWT) we were focused on building a great tool for people to build AJAX apps with. Now, we're happy to announce that all of the GWT source code is available, including the Java to JavaScript compiler and the debugging browser, under the Apache 2.0 license. If you'd like to see how we pulled off letting you avoid dealing with nasty browser quirks, you should take a look. More importantly, we're running this like a true open source project now: we'll be developing GWT completely in the open, as per our project charter. More info on the GWT blog."
While I'm sure purists will decry anything that promises to automate the process, I think we need more tools like this.
One of the problems with designing easy to use functional web applications is that the web is really structured to support it. What you end up with is a difficult balancing act with interactions between server side code, javascript, and anything else in between.
It's nice to see Google sharing some of the tools they use because let's face it...Google's web apps (in particular gmail) are very impressive.
clifgriffin > blog
I mostly work on business layer / mediation tier, and have never been too good with the web tier. So GWT, at first, looked like a god-send to me. But after implementing my first GWT based test-solution, I realized that maintaining a GWT based solution will be many folds more difficult than a traditional Javascript based solution. So, my personal opinion is that although GWT is good for personal projects, it still needs to prove itself for professional development.
I am glad to see smart companies and developers using developer friendly licenses like Apache and Mozilla. I've been burned early in my career by using the GPL and I'll never do it again for any software I write. I hope more developers use good solid community licenses like Apache 2 and MPL.
Stuff like this makes me wish I could code. :(
So... you can write your application in Java, but then compile it to Javascript to run inside a web browser?
-- Ed Avis ed@membled.com
I've always been of the "build it yourself" philosophy in the past, when I first coded my website (4 years ago), I built the blog, the guestbook, the cms, everything. I don't have a CS degree, and this proved to be a valuable way to learn some programming skills.
Even today, I start new projects, I look at existing offerings, reject them and try and put it together myself. I'm currently some way through building an AJAXy online photo-management tool. It's fun stumbling across a bunch of unanticipated problems and figuring out how to fix them. At the end of the day though, with this particular project, I just want something that's asynchronous, but as reliable and cross platform as gmail.
When the people who make the application whose standards you're trying to match release a toolkit that helps you do that, I'm having me some of that.
There is nothing interesting going on at my blog
Found this under the GWT FAQ:
Does Google Web Toolkit send any information about me back to Google's servers?
When you use the Google Web Toolkit's hosted web browser, the application sends a request back to Google's servers to check to see if you are using the most recent version of the product. As a part of this request, Google will log usage data including a timestamp of the date and time you downloaded the Google Web Toolkit and the IP address for your computer. We won't log cookies or personal information about you, and we will use any data we log only in the aggregate to operate and improve the Google Web Toolkit and other Google Services. Please see the Google Privacy Policy for more information.
WulframII - Free Online Mutiplayer 3D Tank Shooting Game
There is no overlap. In fact, the GWT only works with the Java 1.4 subset of the language (though you can run it on any 1.4 and up JVM, you just have to use -source 1.4). No generics, no enhanced looping, etc.
Java 6 SE includes Rhino (without E4X) which I suppose could be used as a target of the GWT for the server side, but it seems a tad pointless except maybe for validation of generated code.
Done with slashdot, done with nerds, getting a life.
No, the reason Java didn't take off for web stuff is the massive hit you take when first firing up the JVM. The first time the JVM initializes you can add 3-10 seconds to the web page load. It also chews memory disproportional to what it was used for -- little applets.
Don't get me wrong, for larger programs and projects Java can be an excellent tool. When you fire up the JVM with system boot, or once a week or so, then no problem. But using Java to give you an automatic clock, roll-over buttons, or pretty water effects on pictures is just wrong on so many levels.
Learning HOW to think is more important than learning WHAT to think.
Time to make like it's nineteen-ninety-eight. Again. I avoid Java applets as much as I can. Not because of security or bandwidth, but because they take so damn long to load and often cause the browser (IE or FF) to freeze until they're done loading.
The modularity lacking in Java is packaging and importing. As another poster mentioned, toolkits create the illusion that JavaScript has these, but it really doesn't. Somewhat less important is that there really isn't a true inheritance model. You can inherit another object's prototype, but that doesn't give you the same flexibility as true inheritance.
"Don't blame me, I voted for Kodos!"
Because it's really hard to write a Java applet that doesn't break user expectations for content inside the browser window. If you do it all with a Java applet, you break the "text size" menu items, the back button, bookmarks, the print menu item, and so forth. If you use AJAX correctly, all of these work (better even than without AJAX, because it makes "next" and "previous" buttons on a big list act like scrolling through it, rather than being additional history items). People want to use web sites like web sites, but with extra-clever controls, not like desktop applications. Java applets are inherently objects embedded in web pages, not integrated with the browsing interaction.
> Almost all Java dev on the server side takes place on 1.4.2-level syntax.
... most java dev is using hopelessly archaic junk. Thank god my Java projects aren't driven by glacial rollout schedules and fear of new things, so I quite happily use things like Seam, which is chock full of Tigerisms like annotations. It's the only I can get myself to stand working in Java at all.
.NET that carries less encumbrance of big legacy deployments must be a bit more liberating. I suppose it all depends on the work environment.
Sadly true
I suspect a platform like
Done with slashdot, done with nerds, getting a life.
Well, according the the GWT website, that's not true. One of the big advantages of GWT, or so is it advertised, is that you can develop *and* debug your app directly in Java, not having to mess with the Javascript at all.
From the GWT overview
Here's the GWT development cycle:
1. Use your favorite Java IDE to write and debug an application in the Java language, using as many (or as few) GWT libraries as you find useful.
2. Use GWT's Java-to-JavaScript compiler to distill your application into a set of JavaScript and HTML files that you can serve with any web server.
3. Confirm that your application works in each browser that you want to support, which usually takes no additional work.
If you are using Tapestry, depending on Tapestry's version it either has AJAX functionality built-in (v4.1) or available through add-on components (e.g. Tacos)
When you need a 12-meg download to run a 160k applet, users will probaply turn away. Remember how it was difficult to redistribute .NET Framework apps because noone would install a 50 meg library just to run the small program they've downloaded? Or even worse, requiring asministrator priveleges, the latest service pack and Internet Explorer to be installed? That just like the problem when nobody writes Linux games because there aren't a lot of Linux gamers because there aren't a lot of Linux games.
And big Java applications like Matlab and Maple and Oracle JDeveloper keep their own version of JRE installed which is invisible to other apps, something to do with compability. That's right, I have 4 independent copies of JRE: one for Maple, one for Matlab, one from JDK and one for everything else.
What I'm trying to say that until Java gets installed on every PC out there, it would be hard to convince users to install it. However since Microsoft seems to be abandoning ActiveX Java has a chance.
This is good news, but I would highly suggest anyone looking at a tool such as GWT also look at ZK ( http://www.zkoss.org/ ).
v iew_wi.html )
While not technically competitors (GWT is all client side, ZK provides a way to handle AJAX requests automatically on the server side) they fill many of the same niches. There is an informative interview available ( http://blogs.pathf.com/agileajax/2006/06/an_inter
If you want to jump straight into the ZK demo, check out http://www.zkoss.org/zkdemo/userguide/
> The reason why I can't modify GPL'd software is fairly simple: releasing in-house software as GPL is expensive. It requires legal oversight to make sure that we can relicense it, it requires infrastructure to allow us to give customers access to it, it requires us to support those customers --- if you're a real company, you can't get away with telling customers to piss off when they ask you questions --- it requires us to religiously differentiate between the GPL'd code and the non-GPL'd code to prevent license poisoning, and above all, it requires the process to manage the above. Using GPL'd software involves an entire management chain from legal downwards. Using BSD software doesn't.
Well, if you're using GPL'd software as part of your proprietary software, you were barking up the wrong tree to begin with--the whole point of the GPL is to promote free (libre) software.
As for the relicensing bit, you can only license things you own. If you're not using code you own, you have your own problems right there, GPL or not.
And if it was for simple in-house *use* (the GPL covers *distribution* as you can see from the preamble section), well, you didn't really have to release anything, anyhow, so there couldn't have been anything to vet to begin with.
Honestly, it sounds to me like you grabbed a screwdriver and were disappointed because you couldn't make a very good hammer out of it.
Yes, we do use this in some of our apps, the most recent of which is described here: http://googlebase.blogspot.com/2006/12/plastic-sur gery.html
Once again a Web 2.0 Javascript framework that doesn't gracefully fail for those who disable JavaScript.
IMO this is nice-looking but a non-starter.
A "tech talk" on GWT is posted on TheServerSide. Of course, if you're generally interested in Ajax you should also check out the tech talk on Ajax Push with ICEfaces just below the GWT talk. In keeping with allowing the developer to write Ajax applications in pure Java, ICEfaces also promotes Ajax development without JavaScript.
try Wt. It is like GWT without Java - uses standard C++ and the only essential dependencies are boost & Xerces. Doesn't have Google pushing it, but is being actively developed. I bet it can beat the pants off GWT for server-side performance, besides being architecturally modern (uses boost signal-socket library for both client and server based event handling). Another nice feature is that it degrades gracefully - defaults to DHTML if browser can't do AJAX.
Three o'clock is always too late or too early for anything you want to do. - Jean-Paul Sartre