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.
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
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
> 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.
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.
Matter of opinion i guess. Having done internal apps that had to take full advantage of "the perfectly good web standards" (thus picking a single standard compliant browser..it was internal after all), I'm not confused by the difference between Microsoft's crappy implementation, and the standards themselves.
In my opinion (which i guess is what I had forgotten to specify), the web standards are garbage. Fully implemented or not. (And well, in some cases, IE isn't the only one to blame... Safari's javascript implementation, I'm looking at you...)
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.
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