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."

A step in the right direction...

[clifgriffin (676199)]

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.

Re:A step in the right direction...

[dsginter (104154)]

While I'm sure purists will decry anything that promises to automate the process, I think we need more tools like this.

The problem isn't that these new tools aren't useful - they are. Rather, the "purists" seem to hate it when education is made on assumptions.

For example,

Switching theory is considered the "calculus" of computer engineering. And like calculus, it is being dropped from many undergrad curriculum with the assumption that software can best manage this aspect of microprocessor and other digital design. Those who graduate without this knowledge are basically standing on a foundation of assumptions. This is the proverbial "box" outside of which one is supposed to think.

The purists are just quick to point out that one should never found their decisions on assumptions. In the GWT example, the purist will quickly point out that it is safe to use, provided that the user have the knowledge to work under the hood, when necessary. In my switching theory example, what will happen to microprocessing once we are up against the very laws of physics? This will happen in the near future and those who don't know the basics will not be able to go back to them in order to move us beyond such limitations.

Back in the '90s, when Y2K was the big worry, the FAA went to IBM for reconciliation. IBM's response?

"We'll have to replace the whole thing. There isn't anyone left who understands the entire system."

Re:A step in the right direction...

[Fozzyuw (950608)]

Switching theory is considered the "calculus" of computer engineering. And like calculus, it is being dropped from many undergrad curriculum with the assumption that software can best manage this aspect of microprocessor and other digital design.

This has always been one of my pondering points of Star Trek. Where, in the development of the Earth, did they find the time to 'educate' students on the likes of Calculus and 'general education requirements' while also being able to teach them the intricacies of Quantum Mechanics, deflector dish re-alignment, and power coupling re-direction, all by the age of like 18 and flying around on a star ship!

Calculus was pretty difficult enough, let alone the difficulties of studying as a teen-age when the temptations of a holo-suit are sitting in your own 'dorm'. There's enough addiction in games like WoW, I cannot imagine what it would be like on the Enterprise. =D

Cheers,
Fozzy

Re:A step in the right direction...

[s4m7 (519684)]

Eh, no it's not. The 'box' is the set of standard notions that are currently accepted as the way to do things.

That's what you think the box is. I think it is an actual box, located 15 miles south of Champagne, IL.

All kidding aside, please don't legitimize corporate doublespeak buzzwords by trying to claim they have an actual definition. It's an insult to those of us who are not marketroids.

Re:A step in the right direction...

[Mad Merlin (837387)]

Well, since the current web standards are garbage...

No, the current web standards aren't garbage. The browsers that don't even attempt to pretend to follow the standards are garbage (I'm looking at you, IE).

The correct solution is to rip and replace IE, not the perfectly good web standards that it ignores.

Ready for professional use?

[namityadav (989838)]

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.

Re:Ready for professional use?

[david.given (6740)]

From what I've seen, the big advantages to using GWT are:

• You get to write your logic in a language other than Javascript --- that is, one with type safety, compile time checking, sane syntax, and a reasonably consistent implementation.
• You get to use the same form verification logic on the client and on the server, which means you don't have to implement it twice, which makes it much harder to get it wrong.
• You completely avoid the horrific browser inconsistencies.
• You get a real debugger.
• For most tasks, the pain of connecting your front end to your back end is done for you.

I wouldn't say that GWT is a particularly nice solution to the problem --- it's doing some pretty damned foul things behind the scenes, you should look at the code it generates some time --- but it hides the foulness rather effectively. It basically lets me get the job done far more easily than I could otherwise, which makes it valuable to me.

Re:Umm...

[EvilKevin (26404)]

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 [blogspot.com]

Re:Ready for professional use?

[breadbot (147896)]

There's a good answer to that: the compiler can be invoked in two modes. Production mode generates compressed, obfuscated (as a side effect of compression) JavaScript, with function names like a3(). Development mode, though, generates incredibly verbose JavaScript, with Java packages and class names and method names visible everywhere, that is encredibly easy to trace back to your original code.

Kudos on the licenses

[by Anonymous Coward]

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.

Re:

[david.given (6740)]

As someone who has contributed bits and pieces of code here and there, and considering some bigger ideas to be released as GPL, I'm interested in why you'd prefer Apache 2 and MPL. It's all rather murky to me what the differences are. Mind elaborating?

If I'm a company, then if I use GPL software, I cannot modify it. This rather defeats the purpose of using open source software.

The reason why I can't modify GPL'd software is fairly simple: releasing in-house software as GPL is expensive. It requires leg

Re:Kudos on the licenses

[by Anonymous Coward]

GPL primarily has distribution restrictions. If you are just using modified GPL code internally, that is not a problem. If you are re-distributing (selling) the software, you need to provide the source code, including your modifications. I don't see the problem.

Your company doesn't want to "support" the software? Why would anyone want to purchase software from your company?

You were doing WHAT now!?

[by Anonymous Coward]

> 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.

Only if you promise to think about the irony

[Ed Avis (5917)]

So... you can write your application in Java, but then compile it to Javascript to run inside a web browser?

Yes please :)

[growse (928427)]

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.

Re:Yes please :)

[growse (928427)]

It doesn't. You missed the point. I tend to think in the "build it yourself" mindset, but I don't write my own compiler, or my own XML parser plugin for Perl. Sometimes, it just doesn't make sense to build something when there's a tool out there that helps you achieve the ultimate goal. Sure, I don't learn about how to get around browser specific JS bugs with the GWT, but on the upside, I get to learn Java. Bigger benefit.

Um ya......

[jrwr00 (1035020)]

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.

Re:Um ya......

[by Anonymous Coward]

You have the sources, so you can just cut out that functionality.

Devil's Advocate

[wralias (862131)]

From TFA [google.com]:

Writing dynamic web applications today is a tedious and error-prone process; you spend 90% of your time working around subtle incompatibilities between web browsers and platforms, and JavaScript's lack of modularity makes sharing, testing, and reusing AJAX components difficult and fragile.

Anyone who has done heavy work in JavaScript can attest to it's modularity; in fact, it is a very beautiful, expressive, and misunderstood language. Some folks claim that it is not object-oriented - but that is simply not true. It supports inheritance, static members, etc. - you just have to conceptualize them differently. I hesitate to trust the output or business logic of a program that "compiles" in javascript from another language, even if it is something so similar syntactically as Java is. I guess if you don't know JavaScript and you're uncomfortable with browser quirks, and you are a Java person, then this framework is for you. Bad news, though - you'll still need to figure out CSS, and that is a mind-fuck in and of itself.

Re:Devil's Advocate

[abes (82351)]

It's a first that I've seen someone call Javascript beautiful. Javascript, for what it was first conceptualized for, got the job done (back when it was Livescript). The misunderstood part of Javascript, is that it is prototype-language, which is unlike most other languages. That is, you can create object types on the fly due to how the associative arrays work. foo.bar is the same as foo['bar']. From that you can get all the OOP you want (note: although Python is much more of an OOP'd language, it can also be used as a prototype-language).

But this is definitely where the beauty is in the eye of the beholder comes into play. Is this some quick syntactical sugar that gives the impression of structure, or is there indeed a well thought out design to the language. Of course, the fact it's been a slowly evolving/hacked together language would point more towards the former in my book.

Personally, I've never been a fan of the Javascript method of doing things, and prefer a much stronger structure in the language. Python does a great job of it, I like what little I've seen on Ruby (especially Rails), and there is of course my personal favorite C++ (yes, flame all you want, but *know* the language first before you complain about it).

Prototyping languages, from what I've seen so far, are great for hacking together small projects, but get messy when you try to do anything on a larger scale. This is where strong language structure comes nicely into play.

While Java is not my favorite language (I usually refer to it simply as, 'that bastardized c++ language'), I am excited about trying this out. I'm curious as it will compare against RoR, Django, etc. The prospect of being able to write a well maintained library for web interfaces that is easily extendable is a much worked on and much needed item in the world of webs.

Re:Devil's Advocate

[kubalaa (47998)]

You cannot package javascript up in a module which ensures that there will be no namespace collisions

Sure you can, if you are willing to accept the risk of collisions in module names (after all, what happens if two Java packages use the same name)?

// define a new module
org_slashdot_moduleX = new function() {
var module_private_variable = ...
function private_function() {
...
}
this.public_function = new function() {
...
}
} // end module org_slashdot_moduleX
 
// import the module as "mX":
var mX = new org_slashdot_moduleX();
mx.public_function();

You can even parameterize modules to create ML-style functors.

Re:

[nuzak (959558)]

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.

Re:Wither AJAX

[chill (34294)]

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.

Re:Wither AJAX

[iabervon (1971)]

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.

Re:

[curunir (98273)]

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.