×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Google Web Toolkit Now 100% Open Source

Zonk posted more than 7 years ago | from the nicely-done-sirs dept.

Google 173

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

173 comments

cool! (0, Redundant)

jrwr00 (1035020) | more than 7 years ago | (#17210992)

Yet Again Google is Da Bomb, Now people can have Ajax the is true cross boswer and open source, i see alot of OSS projects becomming Ajax now

Re:cool! (0, Troll)

jrwr00 (1035020) | more than 7 years ago | (#17211056)

WOW! i was looking at the Kitchen Sink example they have up, OMFG its a dev teams dream! Thank you Google!

frist psot! (-1, Troll)

Anonymous Coward | more than 7 years ago | (#17211014)

w00t!

A step in the right direction... (5, Insightful)

clifgriffin (676199) | more than 7 years ago | (#17211036)

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... (2, Informative)

clifgriffin (676199) | more than 7 years ago | (#17211114)

That should read "the web isn't really structured"....

Sorry.

Re:A step in the right direction... (-1, Troll)

Anonymous Coward | more than 7 years ago | (#17211904)

Dude, we're not a bunch of morons who can only accept the strictest literal read of given text.

Wait a minute, I'm at Slashdot, you were right to post the correction.

Re:A step in the right direction... (0, Redundant)

Bob Gelumph (715872) | more than 7 years ago | (#17211430)

Yeah, like scriptaculous, yahoo and a few other players already do.
It's great and all, but not the only thing out there

Re:A step in the right direction... (4, Interesting)

dsginter (104154) | more than 7 years ago | (#17211590)

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... (1)

Aladrin (926209) | more than 7 years ago | (#17212656)

'This is the proverbial "box" outside of which one is supposed to think.'

Eh, no it's not. The 'box' is the set of standard notions that are currently accepted as the way to do things. 'Thinking outside the box' means to step outside current notions and use a new way to solve the problem, usually inventing that new way as you go.

It has nothing to do with base-level systems or automation of those systems. It has nothing to do with the base level of education and whether or not it's basic enough.

The only thing it even slightly has to do with that you mentioned is 'assumptions', and only those in the fact that there is an assumption that there's no other way to do it, and 'thinking outside the box' throws that assumption away.

Besides that very wrong point, I completely disagree that learning the exact details behind processor theory is necessary to program efficiently. If the person is good enough, there will come a time that they will need to understand this information. Well, good enough and has the right job. Most of the time, this information is completely unnecessary. Especially since we are talking about web scripting, not kernel coding.

Don't get me wrong. I love knowing the nitty-gritty details. They just don't matter a whit most of the time.

Re:A step in the right direction... (4, Funny)

s4m7 (519684) | more than 7 years ago | (#17213686)

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... (2, Funny)

breadbot (147896) | more than 7 years ago | (#17213804)

You mean Champaign [google.com] , Illinois? I'm typing this from Urbana, right next door to Champaign (and just down the highway from storied Peoria), although as a child I lived in the the one and only Oblong, IL [villageofoblong.com] .

Ha! A chance to be pedantic! How often does that happen?

Auugh! No, not the off-topic button! The Midwest really does exist! It's made of peeeeeooople!

Re:A step in the right direction... (4, Funny)

Fozzyuw (950608) | more than 7 years ago | (#17212944)

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... (1, Insightful)

Shados (741919) | more than 7 years ago | (#17211610)

::nods:: Well, since the current web standards are garbage, we need to abstract it. Either through toolkits that simply replace it (Flash, WPF, etc), or stuff that, again, abstract it (OpenLazlo, GWT, and so on).

Someday, hopefully, all this cross-browser mess will be behind us.

Re:A step in the right direction... (5, Insightful)

Mad Merlin (837387) | more than 7 years ago | (#17212024)

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... (2, Interesting)

Shados (741919) | more than 7 years ago | (#17212268)

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

Re:A step in the right direction... (1)

metamatic (202216) | more than 7 years ago | (#17212028)

My problem with the tool is the source language. Yes, developing GUI applications using web standards is painful--but writing Java is painful too. I suspect people would be more enthusiastic about it if it used Python or Ruby.

Re:A step in the right direction... (1)

abigor (540274) | more than 7 years ago | (#17213820)

There are orders of magnitude more programmers writing Java than Python or Ruby. Google knows the demographics of web development. Ruby in particular remains a small niche language.

Re:A step in the right direction... (1, Informative)

Anonymous Coward | more than 7 years ago | (#17212710)

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.

Look again: Google doesn't use GWT for any of their apps. Google bought GWT and open-sourced it.

It's an interesting tool, but it's not what's behind GMail or Google Maps.

Tapestry Integration? (1)

chochos (700687) | more than 7 years ago | (#17211066)

Does anybody know how to use this toolkit along with Tapestry [apache.org] ? We have a couple of web apps of considerable size now, done in Tapestry, and are in the process of adding some AJAX functionality. This looks like a great alternative but the web developer told me he hasn't been able to integrate these two frameworks.

Re:Tapestry Integration? (2, Informative)

Valdukas (247053) | more than 7 years ago | (#17212102)

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 [sourceforge.net] )

Re:Tapestry Integration? (1)

chochos (700687) | more than 7 years ago | (#17213092)

We've been using Yahoo UI. It's been fairly easy to integrate that with Tapestry, although I'm not aware of the details since I haven't been directly involved in the web development lately.

Ready for professional use? (5, Interesting)

namityadav (989838) | more than 7 years ago | (#17211070)

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.

Umm... (1)

Phil John (576633) | more than 7 years ago | (#17211200)

Um..correct me if I'm wrong, but doesn't Google use this to power some of their web-apps?

Re:Umm... (1)

hclyff (925743) | more than 7 years ago | (#17211250)

I think right now they use mostly Python, but I wouldn't be surprised if some Java GWT based projects were underway.

Re:Ready for professional use? (1)

Ritchie70 (860516) | more than 7 years ago | (#17211300)

So....

What is it about GWT that makes it may folds more difficult?

Re:Ready for professional use? (2, Insightful)

namityadav (989838) | more than 7 years ago | (#17211536)

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.

Debugging (3, Interesting)

da_flo (1029770) | more than 7 years ago | (#17212078)

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.

Well, according the the GWT website [google.com] , 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 :

Google Web Toolkit (GWT) is an open source Java development framework that lets you escape the matrix of technologies that make writing AJAX applications so difficult and error prone. With GWT, you can develop and debug AJAX applications in the Java language using the Java development tools of your choice. When you deploy your application to production, the GWT compiler to translates your Java application to browser-compliant JavaScript and HTML.

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.

Re:Ready for professional use? (2, Insightful)

NoOneInParticular (221808) | more than 7 years ago | (#17213118)

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? (3, Interesting)

breadbot (147896) | more than 7 years ago | (#17213864)

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.

Re:Ready for professional use? (5, Insightful)

david.given (6740) | more than 7 years ago | (#17211452)

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

Dion (10186) | more than 7 years ago | (#17211740)

As far as I can tell it's 100% the other way around.

GWT gives you one good language for all browsers.

JavaScript gives you a terrible language that breaks differently in all browsers.

So if you value a working, professional solution you will use GWT, if you just want something to play with and don't care about stability or compatibility then you can use JavaScript.

To me it's not a choice between JavaScript and GWT it's between plain HTML and plain HTML + GWT, because JS is useless as it is.

Re:Ready for professional use? (0)

Anonymous Coward | more than 7 years ago | (#17213598)

Uhmmm...you do realise that GWT outputs JavaScript right? So without JavaScript your HTML + GWT is pretty fucking useless.

JavaScript the language is great. There is little wrong with it. It's the browser's JS engine that is crap. The DOM model is what is broken. Idiot "web developers" who write IE only code is what makes JavaScript "break".

Despite your low UID, it doesn't seem like you know what you're talking about. If you praise GWT while at the same time denouncing JavaScript then you're seriously confused.

Indeed, if you can't write stable, secure, cross-browser JavaScript without the help of GWT in the first place, you shouldn't really be using it. (Or developing for the web, IMO)

Kudos on the licenses (4, Insightful)

Anonymous Coward | more than 7 years ago | (#17211078)

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:Kudos on the licenses (1)

ben there... (946946) | more than 7 years ago | (#17211164)

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?

Re:Kudos on the licenses (2, Informative)

maxume (22995) | more than 7 years ago | (#17211282)

If you are in a situation where you are working on a code base that you initiated but it has become a 85% you, 15% contributed situation, your ability to 'go binary' becomes pretty limited, depending on how that 85% is spread about. That's the point of the GPL of course, but if you start using it without realizing the implications, I can see how you would feel burned.

Re:Kudos on the licenses (3, Interesting)

david.given (6740) | more than 7 years ago | (#17211348)

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.

Re:Kudos on the licenses (5, Informative)

Anonymous Coward | more than 7 years ago | (#17211560)

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!? (5, Insightful)

Anonymous Coward | more than 7 years ago | (#17212202)

> 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:Kudos on the licenses (1)

marcosdumay (620877) | more than 7 years ago | (#17212610)

Who still mods this up? This guy is affraid of using GPLed code inhouse because he can`t send it to his customers!!! Not quite inhouse...

Just to clarify. Using GPLed code inhouse is perfectly clear (unless you got problems with patents). You need no metodoly, or legal team, or anything, just use the code. Now, when you want to DISTRIBUTE closed source programs, well, make sure you are selling your own code.

Re:Kudos on the licenses (1)

Peter La Casse (3992) | more than 7 years ago | (#17212676)

Using BSD software doesn't.

Your parent poster didn't ask about the BSD license, they asked about the Apache license and the MPL, which seem to be the same the GPL from your point of view. Do you prefer them over the GPL? If so, I too would like to hear your reasoning.

Re:Kudos on the licenses (0)

Anonymous Coward | more than 7 years ago | (#17213144)

Umm... you seem to be confusing two issues. Releasing your own code as GPL and using someone else's GPL'ed code. Yes, releasing your own code means you need legal infrastructure to make sure the code conforms properly - but you need that regardless of the license. Furthermore, as you mention yourself, you need to support your software - this is regardless of whether or not it's GPL'ed.

If you're using someone else's GPL'ed code, as others have mentioned, you generally don't need to redistribute if it's strictly in-house (talk to a lawyer about any caveats - IANAL). Furthermore, if you're worried about linking to the GPL'ed code, then just slap on a COM or C wrapper and dynamically discover the interface of the library - thereby you only need to redistribute modifications to the GPL'ed code while your own code can stay proprietary (if you don't want to redistribute your changes, then you are basically mooching off of the work of others and not contributing back to the community, which is exactly what GPL's goal is to prevent).

Basically, you're whole post is FUD - I've seen plenty of GPL code being used by proprietary companies with no need for additional legal or support infrastructure.

Re:Kudos on the licenses (0)

Anonymous Coward | more than 7 years ago | (#17211256)

How does the GPL burn you for your own code?

GNU GPLv3 will be compatible with the Apache 2.0 (1)

YA_Python_dev (885173) | more than 7 years ago | (#17211482)

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 don't agree with you on this, but FYI the GNU GPL version 3 will be compatible with the Apache 2.0 license. See this RMS transcript [fsfeurope.org] from the Free Software Foundation Europe. The combined GPLv3+Apache2 work can be released under the GPLv3+"patent termination protection" license.

If people think that the GNU GPLv2 is viral wait until everyone realise what are the implications of the GPLv3 new compatibility! And, yes, this is one of the many reasons why I really like the GPLv3.

Re:GNU GPLv3 will be compatible with the Apache 2. (1)

Richard_at_work (517087) | more than 7 years ago | (#17213636)

Im sorry, thats not the GPL v3 being 'Apache 2.0 license compatible', thats the Apache 2.0 license being compatible with the GPL v3 - it only goes one way, ever. The GPL series of licenses (from 2 upward, I know nothing about v1) are not compatible with any other license, because you cannot distribute GPLed code under another license without the express permission of the copyright holder. However many licenses are compatible with the GPL because code under those licenses can be distributed under the GPL. One way.

Im not having a rant against the GPL, Im just asking that you get the terms correct.

Re:Kudos on the licenses (0)

Anonymous Coward | more than 7 years ago | (#17211706)

If you wrote the code yourself (and not for an employer), you own it. The fact that you released it under the GPL doesn't stop you from releasing it under any other license on earth. Of course, you can't use anybody else's code that's released under the GPL, and change its license, unless all copyright holders of that particular code agree. In case that's your own code, all you have to do is agree to give yourself the right to release the code under another license :) .

Just as Sun release Java SE 6 (1)

badzilla (50355) | more than 7 years ago | (#17211090)

I'm not that knowledgeable about Java but do the bells+whistles in this new release overlap with what GWT does?
http://java.sun.com/javase/6/ [sun.com]

Re:Just as Sun release Java SE 6 (2, Informative)

nuzak (959558) | more than 7 years ago | (#17211386)

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:Just as Sun release Java SE 6 (0)

Anonymous Coward | more than 7 years ago | (#17211860)

Disclaimer: A former java guy, now working in Redmond (posting anonymously from the job). Almost all Java dev on the server side takes place on 1.4.2-level syntax. In fact, with JDK 1.4.2 you can still have -target 1.1 with 1.4.2-level syntax. That switch prevents the compiler from inlining constants, which is important if you ever change any constant - you won't have to redeploy all .class files (or jars). Of course, you should NEVER change a constant, just add new ones - especially true in the OSGI-like world for instance.

Re:Just as Sun release Java SE 6 (2, Interesting)

nuzak (959558) | more than 7 years ago | (#17211992)

> Almost all Java dev on the server side takes place on 1.4.2-level syntax.

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

I suspect a platform like .NET that carries less encumbrance of big legacy deployments must be a bit more liberating. I suppose it all depends on the work environment.

I feel like celebrating (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#17211106)

Maybe go to sea-world, take off my pants.

Good news... (1)

gigne (990887) | more than 7 years ago | (#17211108)

It is good news that more open source toolkits are becoming available, I would love to check this out...

the problem is the demos don't seem to work in Konqueror (3.5.5) although I am not surprised. Funnily enough I have problems with Gmail in Konqueror, it freezes, and some of the features just don't work.

It would be nice to see some patches against GWT to support these browsers, now it's open, we can.

Re:Good news... (1)

jrwr00 (1035020) | more than 7 years ago | (#17211186)

Signature v2.0, now with AJAX, LAMP, and a load of other useless acronyms
Well, now your signature can really have Ajax! :P

... Or patches to KJS :-) (1)

Almahtar (991773) | more than 7 years ago | (#17212804)

Whether it's GWT's fault or KJS's fault, at least we can actually determine the problem much more quickly now that we can access the internals of both. Sweet.

Dang it. (2, Funny)

Anonymous Coward | more than 7 years ago | (#17211122)

Stuff like this makes me wish I could code. :(

Only if you promise to think about the irony (5, Funny)

Ed Avis (5917) | more than 7 years ago | (#17211134)

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

Re:Only if you promise to think about the irony (1)

Joebert (946227) | more than 7 years ago | (#17211532)

Yeah, I thought that was funny too.
Here it is from the horses mouth.

... and the GWT compiler converts your Java classes to browser-compliant JavaScript and HTML.

Darn internet (0)

Anonymous Coward | more than 7 years ago | (#17211168)

I'm only 23, yet I feel like a dinosaur. I liked the good ol' days where you coded everything yourself from the ground up as a one man operation, and there was no boring HTML, fluffy Java, or crazy XML. *sniff* I can't be assed with web coding, it all seems so dull and repetitive.. I'm tempted to start learning something like Ruby on Rails, as web coding is still better than no coding, and I'm going to be writing a database driven web app for work again soon.. but bleh.. the WWW is in a way the greatest thing to happen to computing in the last few decades, but also, in the end, the most boring to work with! This isn't a troll, just a rant..

Re:Darn internet (0)

Anonymous Coward | more than 7 years ago | (#17213880)

...the WWW is in a way the greatest thing to happen to computing in the last few decades, but also, in the end, the most boring to work with! This isn't a troll, just a rant..

That's kind of the way I felt about C++. More power, less Zen.

I'd rather have the Zen, personally, but it's not up to me.

Yes please :) (2, Interesting)

growse (928427) | more than 7 years ago | (#17211170)

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 :) (1)

mattwarden (699984) | more than 7 years ago | (#17211404)

So, um, how does using GWT to avoid browser quirks and the need to know JavaScript fall in the "build it yourself" philosophy?

Re:Yes please :) (4, Interesting)

growse (928427) | more than 7 years ago | (#17212240)

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.

Re:Yes please :) (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#17211428)

Since you'll be writing in Java to use GWT, why not just write an applet? [wikipedia.org]

Applications written in Javascript using XMLHttpRequest() are retarded hacks.

Um ya...... (3, Informative)

jrwr00 (1035020) | more than 7 years ago | (#17211272)

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...... (4, Insightful)

Anonymous Coward | more than 7 years ago | (#17212118)

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

Wither AJAX (1, Insightful)

Anonymous Coward | more than 7 years ago | (#17211302)

With Java 7 under GPL, why would anyone develop an AJAX application instead of a signed Java applet? The reasons Java applets never took off were security concerns and limited consumer bandwidth. Both of these are less of a concern now and no more of a concern than running rich apps directly in the browser.

Time to make like it's nineteen-ninety-eight. Again.

Re:Wither AJAX (1)

Shados (741919) | more than 7 years ago | (#17211468)

Well, lack of needing a plugin for one. And making an applet that have ajax functionalities probably require some socket connections or something. Much much larger memory footprint, etc.

There's a ton of reasons.

Re:Wither AJAX (5, Insightful)

chill (34294) | more than 7 years ago | (#17211492)

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 (1)

codemachine (245871) | more than 7 years ago | (#17213282)

I see you too have been to a webpage where it waits to load a big JVM, and all that comes up in the grey java box in the end is an animated image with a water efffect. And you have to wonder why they chose Java instead of an animated .gif or something.

It is all about the right tool for the job. Loading an entire virtual machine to display an animation was not a good use of Java. But Java applets would be very useful if Java were built in to most browsers instead of a large plugin.

Heck, if Java were built directly into browsers, you could conceivably have plugins written in Java. Meaning one class file would could potentially work on all platforms. No more x86 or Windows only Firefox plugins for PDF and Flash (assuming Adobe would get on board with that).

Re:Wither AJAX (2, Informative)

whargoul (932206) | more than 7 years ago | (#17211592)

With Java 7 under GPL, why would anyone develop an AJAX application instead of a signed Java applet? The reasons Java applets never took off were security concerns and limited consumer bandwidth. Both of these are less of a concern now and no more of a concern than running rich apps directly in the browser.

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.

Re:Wither AJAX (4, Insightful)

iabervon (1971) | more than 7 years ago | (#17211864)

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:Wither AJAX (2, Interesting)

zlogic (892404) | more than 7 years ago | (#17212152)

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.

Re:Wither AJAX (1)

aeoo (568706) | more than 7 years ago | (#17212424)

I agree that it's always good to keep our eyes open. Applets might have had problems in the past, but since then Java has not stood still.

The advantage of an applet is that it's more cross-platform for what it can do (I know that "hello world" in Javascript is very cross-platform, but who cares about that shallow level of compatibility?). Now with the new license Java will be 100% friendly to all environments without exceptions (including all open source OSes).

I think you have a point. Yet Javascript is also moving forward, and considering you get it for no-perceived-additional-download-cost, it's pretty good.

"JavaScript's lack of modularity" ? (1)

bcrowell (177657) | more than 7 years ago | (#17211410)

Can anyone explain what they mean in TFA by "JavaScript's lack of modularity?" AFAIK, javascript is a pretty standard (prototype-based) OO programming language, and I don't understand what's not modular about it.

Re:"JavaScript's lack of modularity" ? (1)

Shados (741919) | more than 7 years ago | (#17211442)

The OO features are kind of lacking in it, or tend to be annoying to use. Certain toolkits "fake" it, thus adding all the missing features. Its kind of cool.

Re:"JavaScript's lack of modularity" ? (1)

great throwdini (118430) | more than 7 years ago | (#17211642)

Certain toolkits "fake" it, thus adding all the missing features. Its kind of cool.

No, usually, it's done (within these 'toolkits') in a half-arsed fashion that tend toward extended exercises in obfuscation.

I guess that's a kind of cool.

Re:"JavaScript's lack of modularity" ? (2, Informative)

curunir (98273) | more than 7 years ago | (#17211652)

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.

Re:"JavaScript's lack of modularity" ? (1)

dedazo (737510) | more than 7 years ago | (#17211958)

The Dojo Toolkit [dojotoolkit.org] is a good, real world example of how JavaScript is lacking in modularity - imports and references have to be hacked.

Having said that, it's still a fact that we're using JS in ways the original designers probably didn't envision, although I must say that from a basic design standpoint JS is certainly impressive. You're still running within the constraints of the browser, which mostly treats scripts as a sort of annoying necessity rather than an integrated part of the client experience.

Devil's Advocate (5, Informative)

wralias (862131) | more than 7 years ago | (#17211586)

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 (1, Insightful)

Anonymous Coward | more than 7 years ago | (#17212178)

I agree about JavaScript being misunderstood. Too many people have done *only* linear progrmaming with JS. It would be like judging C++ without ever writing a class. *Of course* people think JS is a messy, disfunctional language if all they've ever used it for was to alert some text, confirm a delete button, and add two form fields together.

Re:Devil's Advocate (5, Insightful)

abes (82351) | more than 7 years ago | (#17212288)

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 (1)

marcosdumay (620877) | more than 7 years ago | (#17212346)

They aren`t quite objects if you need to conceptualize them in a different way...

But Java Script offers something that RESEMBLES objects. And can be a mess to deal with when people start to use variables without declaring them, because the language doesn't make the scope clear.

Re:Devil's Advocate (0)

Anonymous Coward | more than 7 years ago | (#17213062)

You sir, are an idiot.

Re:Devil's Advocate (0)

Anonymous Coward | more than 7 years ago | (#17213840)

I hesitate to trust anyone that cannot discern the difference between it's and its.

ZK (2, Informative)

Dan Farina (711066) | more than 7 years ago | (#17212192)

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/ [zkoss.org] ).

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_interv iew_wi.html [pathf.com] )

If you want to jump straight into the ZK demo, check out http://www.zkoss.org/zkdemo/userguide/ [zkoss.org]

Guarantee of longevity! (1)

radarsat1 (786772) | more than 7 years ago | (#17212364)

This is a great step for Google! One thing I haven't seen mentioned yet is that that open-sourcing the toolkit guarantees its longevity. I had looked at GWT before and thought it was really great, but I'm always a little wary of starting a project based on a company's "free" offering, no matter how nice it looks, because the last thing I want is for the rug to be pulled out from under me at the last minute.
Now that it has been open-sourced under a decent license, there is an implied guarantee that I can now depend on this product to be around as long as there is a public interest in it. That makes the difference, for me, to whether I'll use it or not.

.NET? (1)

edmicman (830206) | more than 7 years ago | (#17212552)

Could this be used as an alternative to MS's Atlas/AJAX.NET with ASP.NET? Would I want to use GWT instead of the MS way?

Re:.NET? (1)

namityadav (989838) | more than 7 years ago | (#17212904)

GWT is not an alternative to .NET. Java EE is an alternative to .NET. GWT is a tool that you might want to use once you have already decided that you want to use a Java based solution instead of a .NET based solution.

Re:.NET? (0)

Anonymous Coward | more than 7 years ago | (#17213194)

He asked if this was an alternative to Atlas, not ASP .Net. Atlas is the AJAX framework released by Microsoft designed to work with ASP .Net application (2.0 and higher). Atlas operates similar to GWT, but it has integration with Visual Studio and ASP .Net.

A better alternative to Atlas might be to look at using script.aculo.us with ASP .Net. I've done it a few times and it's much more responsive than atlas, but it takes longer to code and you're giving up your compile time checks.

Re:.NET? (1)

edmicman (830206) | more than 7 years ago | (#17213374)

^^ Yes, what he said! I'm already on ASP.NET, I'm just wondering if the GWT is a valid alternative to the MS integrated AJAX solution. I'll have to check out the scriptaculous...
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...