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."
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.
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 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.
Frequently, it's not worth the effort. It would be cheaper for us to find some sub-par non-GPL code and fix the bugs, or to write our own version from scratch. When I'm wearing my corporate hat and I'm looking for code, I'll frequently not even bother looking at it if it's GPL'd.
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."
More
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.
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.
There is nothing interesting going on at my blog
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.