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

Comments

A step in the right direction...

[clifgriffin]

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

[Mad Merlin]

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.

Re:A step in the right direction...

[rmerry72]

Do you need to know how assembly is compiled into machine code then put into memory and fetched by the CPU (with lots of nop in the case of x86 :)?

Actually sometimes you do. I remember a bug a couple of years ago that was traced down to the compiler incorrectly compiling a few lines of C++ code. Yup, a nasty compiler bug (hey, compilers a programs too). One of our guys not only detected this, hey found out why and how and wrote the embedded assembler to fix it. None of the rest of us knew assembler so we were in the dark.

So, whilst you don't need to know such things in your day to day workings its good to have a familiarity with them so that when a problem like ours falls "outside of the box" (ie. compilers don't have bugs) you can grasp that thread of thought and follow it down to a solution, learning more intricate detail as you go. Else your quickly become stuck at "but compilers don't do that" and get nowhere to fixing your problem.

Even though calculators are cheap and generally in easy reach it's still good to be able to do some math by hand. And even though third-level languages are prevalent, its good to get under the covers occasionaly so you understand what really happens not what's suppossed to happen.

Kudos on the licenses

[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:Ready for professional use?

[david.given]

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:Wither AJAX

[chill]

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:Ready for professional use?

[namityadav]

Well, for one, the Javascripts produced by this tool are nowhere as simple and easy to understand as the ones written by the Javascript expert (Sitting in the next cubicle) who understands the product better. And how do you debug a problem now? First you'll have to find the problem in the automatically produced Javascript, then find out how that relates to your Java files that were used to produce the Javascript. What if the tool has a bug? It'll take you a very long time realizing that. Then, most of the times it's much more difficult to maintain a solution which depends on a framework producing files for you at compile time. And finally, how do you deal with mixing some manually written Javascripts with some GWT produced Javascripts? I am sure web-tier people can come up with more technical problems that they see in GWT based solutions.

Re:Wither AJAX

[iabervon]

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:Um ya......

[Anonymous Coward]

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

You were doing WHAT now!?

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

Re:Devil's Advocate

[abes]

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:Ready for professional use?

[NoOneInParticular]

Then, most of the times it's much more difficult to maintain a solution which depends on a framework producing files for you at compile time.

And how is this different from a compiler? Whether it's object files or class files, it's probably worse to debug the raw assembler/byte code then it is to wade through generated javascript. And yes, compilers make errors. Apparently, GWT is a compiler, with the only twist that it generates javascript rather than raw machine language or a (different) virtual machine. Find an error, file a bug report and trust that your compiler builder will fix the bug. In the meantime, write your logic differently so that the bug goes away.

Re:Ready for professional use?

[larry bagina]

having debugged both "raw assembler/byte code" and obfuscicated javascript/generated perl/etc, I find it easier to debug binary code. With assembled code, you can specifically pinpoint an error. With intepreted half languages, the error may be in the compiler, the javascript interpreter, the javascript libraries/dom support, JIT compiler, etc, etc.

Re:Omitted the NOSCRIPT tag - Disabling JavaScript

[soliptic]

Once again a Web 2.0 Javascript framework that doesn't gracefully fail for those who disable JavaScript.

If you just searched for <NOSCRIPT> and didn't find it, and assume this means it won't gracefully fail with js off - you could be wrong.

You can do graceful degradation that way. OR, you can output a page that works without javascript, all the links being traditional serverside "do_something.php?action=foo&id=foo" stuff. And then, the body onload() goes through your DOM and replaces all the links with javascript hooks to do things via the AJAXy method. So, if js is switched off, onload() doesn't happen, nothing gets replaced.

This latter method (often termed "progressive enhancement" - basically looking at things backwards to "graceful degradation" - defaulting to the basic version and dynamically improving it where possible, as opposed to defaulting to the flashiest version and having a basic fallback) seems to be the more fashionable "best practice" among your 'standardista' web developers these days.

So it's possible that's how this framework handles graceful degradation - workable without js and not a <NOSCRIPT> in sight.

NB: I haven't actually looked at it, so I'm not saying it does do this and hence you're wrong; just saying it's a possibility.

Re:Devil's Advocate

[kubalaa]

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.