alanwilliamson
Javascript as a language misses a lot of the constructs that modern day object orientated languages have. Defining a class in Javascript is not an exact science, with a number of design patterns put forward to mimick behaviour. The biggest problem Javascript has is that its not compiled, so you never know if you have it right until you hit the "refresh" button in the browser. A single curly bracket or semicolon in the wrong place and the whole place can come crashing down around you.
However, the whole proposition of producing Javascript with another language (say Java) seemed a little 'round the houses' for me. I couldn't fathom why you would want to do such a thing. But after a year of hacking in and around ExtJS and other frameworks, you soon realized that Javascript is just one big hack. It's a wonder it runs at all!
Java on the other hand has all the necessary OO toys (classes, interfaces, inheritance, polymorphism). These are the building blocks that make any large software project much easier to handle. Of course, with the language being compiled, it is much easier to catch errors before you even get anywhere near deploying.
Imagine coding Javascript applications in such a way that you had all the flexibility of Java, coupled with the easy deployment of Javascript. That is precisely what GWT is.
So what drove me to try GWT?
Well it was the management of the ExtJS project. This used to be an excellent framework with lots of cool widgets that really made your browser dance and sing (also groan under the weight of it at times). Utilising ExtJS in any project is a commitment, and its not just a case of throwing some Javascript calls to it. It's the classic story, gets you 80% of the way in 20% of the time, with the rest taking up the time.
That is fine, as with most frameworks, once you've gone so far, you are locked into that framework for that project. It is generally very hard to switch out a framework at the 11th hour, particurly if its a UI based framework. So, going down the ExtJS route, you are pretty much pinning your colours on their flag pole.
The biggest problem with ExtJS is that they didn't respect backward compatiability at all well, which is a little frustrating considering they released relatively often. Moving from 0.4 to 1.0 required a rewrite. Moving from 1.0 to 1.1 required replumbing. Moving 1.1 to 2.0 required major rewrite, and again from 2.0 to 2.1 it wasn't a case of dropping in the new JS files.
Now with ExtJS 3 looming we couldn't face having to go back to the drawing board. We know there are bugs that were going to be fixed, but the hassle of continually porting for each release was costing us real money. Also it was getting difficult to tell clients why they had to spend money on porting to a new version that wasn't buying them anything.
After talking with someone who had seen the GWT dream he took me through the reasons why I should really give it a chance. Within one day, I was hooked.
Google has defined an API to which to code to and this API isn't for changing. They have also ported the most useful packages of Java over to Javascript. So imagine my delight in being able to call .trim() on a string without having to resort to some Javascript regex hack, or using any of the Collections classes (hashtables, linked lists etc) to manage my internal storage. I can also use all the Java OO techniques, and Google provides all the necessary 'conversion'.
Google has thought about everything, including communicating back to the server. Imagine being able to pass the same object to the server from the client (javascript), do something to it, and pass it back, all without you having to worry about the 'plumbing'. They provide a servlet framework to utilise to allow this magic to happen. Sometimes I think I am dreaming!
Here's the real kicker for me. In the time I have been using it, Google has rev'd 3 times (2 bug fix releases and one major update) and each time I merely dropped in their new JAR, recompiled, and my application worked. No change required! Now I can bet the farm on GWT. My team is now trained up in GWT and shock horror, some are even producing JUnit tests! JUnit tests for code destined for Javascript! Its crazy!
Google's 1.5 release is pretty slick; they have added a lot of serious optimizations and the final produced Javascript is even smaller and faster than 1.4. So as a result, my Javascript software is now smaller and faster, without me having to do a thing!
Andy and I have begun to integrate the GWT stack within Open BlueDragon to provide some of the handling of the new client side tags that have been introduced. By utilising Google we can be sure we won't have to keep recoding this area and it should be easier for people to contribute to if they want, especially, with some of the community GWT projects popping up. <cfcanvas> anyone?
I am also looking at making CFML objects available to the GWT frontend by transparently marshalling it in and out as it moves from GWT to your CFC/CFML request. That way you don't need to mess around with JSON and try to work around some of the limitations that imposes (dates anyone?)
If you have checked out GWT then I urge you to give it a whirl, you will never look at another framework in the same way again.
Comments
please note, all comments will be moderated for spam and abuse before being publicly posted.
Article Details
- Published:
9:06 PM GMT, Monday, 9 June 2008 - Categories:
Technical CFML - Tags:
gwt javascript openbd java - Comments:
9 left; add comment
Related Articles
Article Archives
Recent Cloud posts
Recent JAVA posts
Latest CFML posts
|
Site Links |
Recommended Sites/Blogs
|
1. I haven't used GWT yet and I don't even code in Java. However after hearing about GWT I've decided to start and bought "Java Precisely" last night.
My patience with ASP.NET has worn too thin and if GWT is the best thing out there, I guess, needs must. Can some GWT coders here could help me out more by telling me whether I should be add Hibernate and Spring to GWT? 2. "The biggest problem Javascript has is that its not compiled" - I don't think so. The big problem is the lack of support for good data structures & slightly obscure syntax and semantics . The archaic development process - no good debugging, etc. There are interpreted languages out there with excellent development environments. Even stuff made 25 years ago (like Smalltalk and ucls Pascal - still only interpreted at that time) had much better DEs than Javascript today. I think it's time to leave Javascript behind and let GWT do it for me.Alan, already signed up yesterday for both blogs! Thanks for the explanation; I'll be making our CF folks here aware of BD as a potential alternative to Adobe.
By the way, using OBD pointed me towards my solution in about five minutes. Turns out feedback actually HELPS! Adobe failed to load my servlet, but didn't tell me how or why... or at all really. Anyhow, that's solved. ...looking forward to OBD's future integration with GWT! Cheers!Ed, great to see you are looking to CFML to help you with your server side requirements. In terms of GWT, yes the way you are embedded it in the page is correct, and assuming your client side loads up you shouldn't have a problem there.
I have no experience with Adobe's offering, so i can only advise that you maybe run it under FireFox+Firebug and see exactly the call the GWT application is making so you can see if that does indeed map onto anything you've setup. In terms of OpenBlueDragon, we are taking a slightly different approach. We want your GWT app to be able to call remote CFC's without you worrying about extra JAR files etc. It will be part of the engine and we are working on a small GWT API that you can use to call it, passing in a Java object and not worrying too much about the logistics of it all. For example, you will be able to pass in Hashtables, Lists, Strings, Dates, and all the usual suspects and have them appear in your CFC unhindered, do something with that data, and send it all back. Whats really cool is that your CFC doesn't need to be modified to output anything special. Just let it do its job and live life as an object within your CFML cluster. Keep an eye on this blog and http://blog.openbluedragon.org for more details very soon.Alan, what great timing! I'm coming at this the other way. I'm brand new to CF and now have the need to embed an existing GWT module in an inherited CF app. I'm using Adobe CF8 Developer Edition, and having great difficulty setting it up so that my GWT RPC calls actually hit the servlet.
Couple questions for you... I've edited web.xml to map to my servlet, and am just relying on GWT-generated javascript to make the request (as opposed to using any CF tags). In my (test) CF file, I simply point to the .nocache.js file like the GWT documentation says to do... I'm pretty sure that my mapping and requests are correct, but I get a 404 error from the JRUN server that comes with CF8. Question is, is that normal? Am I dreaming that this should even work in CF8? Another question... Never head of Blue Dragon... Just had a quick scan and think it might be really good for us... Can you comment on its advantages and benefits regarding GWT integration? ...there is also a large .NET contingent in my organization so if there's goodness to know about there, please include that. Thanks.It is very good actually. This is the official widgets that Google are noodling around with:
http://code.google.com/p/google-web-toolkit-incubator/w/list but there is a whole host of community stuff. Whats nice about developing a widget for GWT is that as a widget developer you know its going to have a long shelf life!I'm acutally compare JSF to GWT for my next app.
But what about widget/component library in GWT (JSF has RichFaces, MyFaces, ICeFaces)? AFAIK, days are numbered for Gwt-ext because extJS has migrated to a GPL licence + commercial.Gary, we will be matching the current crop of new additions as closely as posisble. We won't be using ExtJS, so that will naturally come with some interesting side effects. The biggest advantage will be size; we won't need to be forcing the user to download 400KB+ of Javascript files before rendering any components.
GWT is much lighter, and ironically much easier for users to skin to their own look'n'feel. GWT1.5 introduces themes and people are starting to produce libraries of them to choose from. As for the JSON notation, yes there is some issues with that in general, without a doubt. We are actually experimenting with WDDX as the transport layer but if you are coding your clientside portion with GWT then you won't need to worry. You will be able to import our GWT classes that transparently or automagically communicates back to your CFML app without you worrying about the plumbing. So think of it like calling methods of a CFC within a Javascript page. Pretty darn cool I think you'll agree. This will be one of the first things we release. That way you won't have to wait until we are done to start calling CFC's from Javascript."The biggest problem Javascript has is that its not compiled"—it's not the problem of JavaScript, but that's the characteristic of every interpreted language.
Alan, will you be trying to emulate the CF8 ajax tags for cfml portability, or are you thinking of doing it differently because of the extra features provided by GWT?
I'm just getting to grips with JSON and was unable to work with CF8's serialization of JSON. (It's format doesn't match any other formats I've come across). Does GWT give you the ability to code more options into a JSON serialization tag for OpenDB? But it sounds like you've found something better than JSON to move data around?