Slashdot Mirror
GWT in Action
Michael J. Ross writes "Server-side computer languages, such as Java, possess numerous advantages over their client-side counterparts — including more robust integrated development environments (IDEs). In contrast, Web-focused languages, such as JavaScript, benefit from the global accessibility of the Internet. Bridging this gap, and leveraging the strengths of both sides, has long been an objective of the software development community — though not all attempts have been successful, e.g., Java applets. The Google Web Toolkit (GWT) is the latest attempt, and shows considerable promise, as illustrated in a new book intended to help programmers learn this new technology: GWT in Action." Read on for the rest of Michael's review
GWT in Action
author
Robert Hanson and Adam Tacy
pages
600
publisher
Manning Publications
rating
6
reviewer
Michael J. Ross
ISBN
1933988231
summary
A practical introduction to programming with the Google Web Toolkit (GWT).
Written by Robert Hanson and Adam Tacy, this book was published by Manning Publications on 5 June 2007, under the ISBNs 1933988231 and 978-1933988238. For any prospective reader who would like to learn more about the book, they can first try the book's Web page, where they will find online versions of the "about this book" section, table of contents, preface, and index. The publisher offers two freely downloadable chapters, "Creating the Default Application" and "Communicating with GWT-RPC," in PDF format. In addition, there is a link to purchase the book's electronic version, and a link to the author's forum, where readers can post questions about the book or GWT, and likely receive a response — perhaps even by one of the authors.
The book's 17 chapters are organized into four parts, and cover a generous number of topics: introduction to GWT; creating the default GWT application; building your own application based upon the default one; creating widgets and panels, including composite panels; processing user events; creating JSNI components; modularizing your code; communicating using GWT-RPC; client-side RPC; classic Ajax and HTML forms; using JSON for interoperability; automatically generating code; GWT's native properties; testing and deploying GWT applications; more on the inner workings of GWT itself. The book has no appendices, but a substantial index, which is essential for such a technically detailed subject area.
GWT in Action is clearly intended to be a practical and fairly comprehensive coverage of Google's new toolkit. Almost all of the GWT concepts are explained within the context of developing a substantial sample application, the Dashboard, created by the authors. The reader is encouraged to follow along as the authors build the application, thereby learning from doing — almost always an effective approach. At 600 pages, with almost none of the formatting padding found in far too many technical books nowadays, the authors have not skimped on providing the reader with a lot of information. Furthermore, their treatment of application deployment is far better than any other I have encountered.
Unfortunately, the book has many weaknesses. On an overall basis, the order of presentation is at times disjointed — seemingly dictated more by the Dashboard and less by the most logical order for someone new to GWT. Compounding the problem, the authors frequently refer to advanced topics, covered in greater detail later, and also repeat earlier information, occasionally several times. Despite promises to provide a gentle exposition, it can be difficult at times for the reader to determine if any critical steps were skipped, as a consequence of key instructions for building the sample application being spread out, and interspersed with too many references to general comments covered earlier. In turn, readers will likely find it frustrating to try to get the sample application working at each step of the development process — and not just at the end, with the complete code.
One source of these difficulties, is that in the first few chapters, the authors try to introduce too many topics all at once, and as a result do not thoroughly discuss each one in its own section. Instead, they break up the information over multiple sections, scattered throughout the book. An example of this is internationalization. Section 2.2.4 is titled "Implementing Internationalization," and yet provides almost no details, and is essentially unusable by itself. At the very least, it should mention that later sections 3.2.1 and 15.3 provide a lot more information. Furthermore, internationalization was introduced far too early in the book, and greatly complicates the process. Instead, the authors should have created a simple application using only English for the user interface, and introduce internationalization later, after fully explaining the basics of turning Java code into JavaScript functionality.
Part I of the book is the weakest of all of them, which may, sadly, turn off readers who would otherwise get to the better material later. The authors are clearly enthusiastic about the topics at hand, and the number of moving parts associated with Java/JavaScript/GWT development is certainly not trivial. Nonetheless, those initial chapters would greatly benefit from a rewrite; this would make the material more comprehensible and easier to follow, step-by-step.
We can mention some specific flaws: A book like this that is introducing a new technology, must take care to not leave the unwarned reader wondering if they have been left behind in the steps. People reading some of the earlier material may conclude that those steps have already been assumed by the authors, and will not be covered. The authors do not mention how to obtain and install GWT until page 30; that should be right up front. The authors do not appear to mention which version of GWT they used for the book. (I chose 1.3, not 1.4RC, available as of this writing). Any reader trying to follow along and implement their example application (the Dashboard) will probably find several hurdles. First of all, make sure that you have version 1.4 of GWT installed, and not 1.3.3, which does not include some of the panels and widgets used in their sample code.
In Chapter 1, they modify a "Hello world" application to create another application that shows a tic-tac-toe board that has clickable squares, but does not play the game. Chapter 2 describes this as "a fully functioning Tic-Tac-Toe application," which is like claiming a program works because it compiles. Also in Chapter 2, their discussion of development alternatives is slowed down by repetition of the same information. The sample code in the book has minor inconsistencies. For example, naming a password String "oldPass" in one method, then "old" in another, related method. There are other instances, but these give one an idea of some of the inconsistencies.
The coverage of topics is generally quite thorough, though at times verbose and redundant — particularly in Chapter 2, though it is certainly not limited to that chapter. The second and third paragraphs in Chapter 3, for instance, continue the repetitious style which is found in many places throughout the book, and likely has made it longer than necessary. In Chapter 4, the first two pages explain what widgets are, several times, and conclude with a picture of a button — as if any reader who has made it that far into the book doesn't know what a button is. The book could certainly use some trimming.
The downloadable source code is not complete. For starters, it is missing the code from Chapters 1 and 2, though admittedly none of that is too long. The code provided for Chapter 4 is just a portion of what is displayed in the book. Moreover, the directory paths in the sample code archive files, are not consistently named, and some may even be incorrect. For example, the code for Chapter 5 has a folder named "Dashboard — Chapter 4." That sort of thing does not instill confidence in the typical reader. The authors should revisit the sample code — making it complete and consistently named.
The publisher's page for the book does not appear to have a link for errata; perhaps none have been reported yet. Here are some: On page 75, in Table 3.1, in the left-hand column, "gwt-onLoadErrorFn" should instead read ""gwt:onLoadErrorFn." On page 77, in the second paragraph, the file name extension should be all lowercase, not all uppercase. On page 78, in Listing 3.6, the String parameter in the first label.setText() call should be delimited with straight quotes, not curly quotes. (Microsoft Word strikes again?!) On page 81, in the third paragraph, "comply to" should read "comply with." On pages 87 and 88, the -whitelist and -blacklist option values each contain an extraneous space before the "^." There are undoubtedly more such errata throughout the book, and can be corrected in the next edition; but these are enough to at least get an errata file started. Fortunately, none of them would lead an alert reader astray.
Even though the book could use significant reorganization and streamlining in the next edition, GWT in Action is packed with practical information on a wide range of GWT topics.
Michael J. Ross is a Web developer, freelance writer, and the editor of PristinePlanet.com's free newsletter.
You can purchase GWT in Action from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The book's 17 chapters are organized into four parts, and cover a generous number of topics: introduction to GWT; creating the default GWT application; building your own application based upon the default one; creating widgets and panels, including composite panels; processing user events; creating JSNI components; modularizing your code; communicating using GWT-RPC; client-side RPC; classic Ajax and HTML forms; using JSON for interoperability; automatically generating code; GWT's native properties; testing and deploying GWT applications; more on the inner workings of GWT itself. The book has no appendices, but a substantial index, which is essential for such a technically detailed subject area.
GWT in Action is clearly intended to be a practical and fairly comprehensive coverage of Google's new toolkit. Almost all of the GWT concepts are explained within the context of developing a substantial sample application, the Dashboard, created by the authors. The reader is encouraged to follow along as the authors build the application, thereby learning from doing — almost always an effective approach. At 600 pages, with almost none of the formatting padding found in far too many technical books nowadays, the authors have not skimped on providing the reader with a lot of information. Furthermore, their treatment of application deployment is far better than any other I have encountered.
Unfortunately, the book has many weaknesses. On an overall basis, the order of presentation is at times disjointed — seemingly dictated more by the Dashboard and less by the most logical order for someone new to GWT. Compounding the problem, the authors frequently refer to advanced topics, covered in greater detail later, and also repeat earlier information, occasionally several times. Despite promises to provide a gentle exposition, it can be difficult at times for the reader to determine if any critical steps were skipped, as a consequence of key instructions for building the sample application being spread out, and interspersed with too many references to general comments covered earlier. In turn, readers will likely find it frustrating to try to get the sample application working at each step of the development process — and not just at the end, with the complete code.
One source of these difficulties, is that in the first few chapters, the authors try to introduce too many topics all at once, and as a result do not thoroughly discuss each one in its own section. Instead, they break up the information over multiple sections, scattered throughout the book. An example of this is internationalization. Section 2.2.4 is titled "Implementing Internationalization," and yet provides almost no details, and is essentially unusable by itself. At the very least, it should mention that later sections 3.2.1 and 15.3 provide a lot more information. Furthermore, internationalization was introduced far too early in the book, and greatly complicates the process. Instead, the authors should have created a simple application using only English for the user interface, and introduce internationalization later, after fully explaining the basics of turning Java code into JavaScript functionality.
Part I of the book is the weakest of all of them, which may, sadly, turn off readers who would otherwise get to the better material later. The authors are clearly enthusiastic about the topics at hand, and the number of moving parts associated with Java/JavaScript/GWT development is certainly not trivial. Nonetheless, those initial chapters would greatly benefit from a rewrite; this would make the material more comprehensible and easier to follow, step-by-step.
We can mention some specific flaws: A book like this that is introducing a new technology, must take care to not leave the unwarned reader wondering if they have been left behind in the steps. People reading some of the earlier material may conclude that those steps have already been assumed by the authors, and will not be covered. The authors do not mention how to obtain and install GWT until page 30; that should be right up front. The authors do not appear to mention which version of GWT they used for the book. (I chose 1.3, not 1.4RC, available as of this writing). Any reader trying to follow along and implement their example application (the Dashboard) will probably find several hurdles. First of all, make sure that you have version 1.4 of GWT installed, and not 1.3.3, which does not include some of the panels and widgets used in their sample code.
In Chapter 1, they modify a "Hello world" application to create another application that shows a tic-tac-toe board that has clickable squares, but does not play the game. Chapter 2 describes this as "a fully functioning Tic-Tac-Toe application," which is like claiming a program works because it compiles. Also in Chapter 2, their discussion of development alternatives is slowed down by repetition of the same information. The sample code in the book has minor inconsistencies. For example, naming a password String "oldPass" in one method, then "old" in another, related method. There are other instances, but these give one an idea of some of the inconsistencies.
The coverage of topics is generally quite thorough, though at times verbose and redundant — particularly in Chapter 2, though it is certainly not limited to that chapter. The second and third paragraphs in Chapter 3, for instance, continue the repetitious style which is found in many places throughout the book, and likely has made it longer than necessary. In Chapter 4, the first two pages explain what widgets are, several times, and conclude with a picture of a button — as if any reader who has made it that far into the book doesn't know what a button is. The book could certainly use some trimming.
The downloadable source code is not complete. For starters, it is missing the code from Chapters 1 and 2, though admittedly none of that is too long. The code provided for Chapter 4 is just a portion of what is displayed in the book. Moreover, the directory paths in the sample code archive files, are not consistently named, and some may even be incorrect. For example, the code for Chapter 5 has a folder named "Dashboard — Chapter 4." That sort of thing does not instill confidence in the typical reader. The authors should revisit the sample code — making it complete and consistently named.
The publisher's page for the book does not appear to have a link for errata; perhaps none have been reported yet. Here are some: On page 75, in Table 3.1, in the left-hand column, "gwt-onLoadErrorFn" should instead read ""gwt:onLoadErrorFn." On page 77, in the second paragraph, the file name extension should be all lowercase, not all uppercase. On page 78, in Listing 3.6, the String parameter in the first label.setText() call should be delimited with straight quotes, not curly quotes. (Microsoft Word strikes again?!) On page 81, in the third paragraph, "comply to" should read "comply with." On pages 87 and 88, the -whitelist and -blacklist option values each contain an extraneous space before the "^." There are undoubtedly more such errata throughout the book, and can be corrected in the next edition; but these are enough to at least get an errata file started. Fortunately, none of them would lead an alert reader astray.
Even though the book could use significant reorganization and streamlining in the next edition, GWT in Action is packed with practical information on a wide range of GWT topics.
Michael J. Ross is a Web developer, freelance writer, and the editor of PristinePlanet.com's free newsletter.
You can purchase GWT in Action from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
That's a lot of reading. Can someone sum it up in 5 words or less for us lazy people? Thanks in advance.
The game.
The more I learn about JavaScript, the more I like it as a language.
I'm not really sure I see the point of GWT, given that JavaScript is actually a more powerful language at this point. I'm almost tempted to suggest that someone build a webserver platform around a JavaScript interpreter.
Well, almost. The problem with JavaScript is that it's horribly slow to execute. But then, you still have that problem, even if it's JavaScript generated from Java code.
Don't thank God, thank a doctor!
http://googlewebtoolkit.blogspot.com/2007/08/gwt-1 4-release-and-out-of-beta.html
(Disclaimer: I evaluated GWT and decided that it was cool for larger web apps, but for a smallish website I think it is overkill. So.. I'm not a GWT user, sorry.)
When I was developing my site (which you will visit now and purchase lots of album downloads), I had to deal with the fact that browsers do not implement things consistently. In particular, IE seems to do things differently than every other browser. The idea of GWT is to do all the hard browser bug workarounds and compatibility work for you, so that you write some code in Java and poof! Your web app will look and behave the same across all browsers everywhere. Among the downsides, you have to learn GWT of course, and your resulting code is almost guaranteed to be less efficient and slower to load than if you just code directly in Javascript/HTML/etc.
In the end, I ditched GWT in favor of simplicity, dealing with IE issues as they arose (my native development platform is Firefox). Then again, my site has very limited functionality. YMMV.
david
BitWorksMusic.com -- odd tunes for odd times
Yeah?
I did an evaluation of it. I kind of liked it, but in general don't like "lets make a servlet environment pretend its an applet", so I didn't endorse.
Now, after months of using Wicket, I wish I had pimped for it more. Seriously. If you're gonna pretend it's an applet, then REALLY do it like GWT does, fake JVM and all. This Wicket stuff.... ugh. keeping the html view and java in synch for anythign complex is SO IRRITATING.
Seriously, after years of Struts and stuff like Wicket, I don't see any real advantage over "Model 2+" (Servlet/JSP pairs) that I started with in 2001. There is a benefit to simplicity and writing HTML in HTML and writing Javascript in Javascript that over-engineers who are, frankly, a little OO-obsessed just don't get.
Maybe years of Perl CGI has bent my brain but The HTTP Request/Response paradigm just doesn't seem so awful that it needs to be (leaky) abstracted away.
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
The sentence "Server-side computer languages, such as Java, possess numerous advantages over their client-side counterparts - including more robust integrated development environments (IDEs)." is possibly the most retarded thing I have ever seen on Slashdot. Ever.
Come on, doesn't anybody read these?
we discovered a new way to think.
I would like to point out that the GWT can also be used from a Java server application. I'm using a package from Instantiations, WindowBuilder Pro, that can generate Swing (default Java GUI), SWT (IBM/Eclipse GUI) as well as the Google Window Toolkit. It's an application/plugin for creating graphical interfaces, so you would probably not get too exposed to the GWT itself. I haven't yet tried it out, but it might be a good idea to start of with a GUI builder and only delve deeper when needed. Of course, understanding what happens is great when you need to debug something, or if you are not happy with the functionality. But I would not start off by writing web-pages when trying out this relatively new technology.
Before somebody grills me, the version of WindowBuilder Pro that I am using is a bit unstable and crashes Eclipse now and then. Lots of memory is also recommended (then again, if you are a developer, you need lots of memory anyway).
Does the book - or somewhere else - address why GWT ought to be on my tla radar screen? Does it work with Apache, or just J2EE containers? Is it open source? I know I could find that out by, um, googling the information, but if the book is meant to evangelize the tla, I would have expected it to concentrate more on why I should use GWT and in which situations, not how to build a tic-tac-toe game.
I thought they said GWOT. My bad.
You are not the customer.
Some day, I'll be able to use a browser to write desktop apps without resorting to plugins or XUL or whatever. No, Google Gears doesn't do that.
JS is a great language and GWT is a great tool, especially the hosted development environment. But it will never reach its potential until it is a general purpose application programming language.
Spot on, that's a really terrible summary. It's like a reverse summary really as there are few to no IDEs which come close to Visual Studio. Even Eclipse, for all its niceness doesn't compare well. Which sucks, as I spend most of my development time working with Eclipse and its variants.
"The first thing I'd like are some of my favorite features from Common Lisp, like first class functions, ability to do procedural, functional, and object oriented programming with the same language, dynamic typing, macros, closures, and lexical scoping.
Having a C-like syntax would be good for people who are used to C or Perl and don't want to learn about s-expressions. Automatic memory management is a must."
You just described pike (although it has both static and dynamic typing).
http://pike.ida.liu.se/
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. ...provided you have some other server capable of running the necessary services to put the A&X in AJAX, which raises the rather obvious question: what does this simplify again? So it's JSF-lite, except I have to roll my own SOAP services for everything?
Hell. No.
Languages don't have performance characteristics. They can't be faster or slower than each other. Only implimentations of languages are faster or slower. For instance, the mozilla implimentation of javascript is very slow, rhino is not as slow, but still slower than the official implimentation of python, and most other reasonable language implimentations. I am not aware of any javascript implimentation that comes even close to the performance achieved by high performance implimentations of pascal, miranda, scheme, or common lisp, much less languages with very fast implimentations like ocaml, C++, C, D, etc.
The content on Google's GWT site almost speaks for itself concerning the power of it, so I'll elaborate on some negative aspects I've encountered.
I went to explore the possibility of a non-servlet based backend and very quickly encountered problems that are not really GWT's fault but a side effect of having a hosted environment: the browser is based on Mozilla and thus inherits the security restrictions of it. I could not make RPC calls to my backend web server because Mozilla disallows cross-domain access. I spent a lot of time trying to circumvent this, and did find some work-arounds but nothing that worked to my satisfaction (too cumbersome). GWT should offer a modified Mozilla with these restrictions removed, or even better, adopting Flash's excellent practise of looking for a crossdomain.xml file in the root of the target webserver (to see whether access is allowed or not).
Also, developing on an AMD64 based Linux I discovered that the hosting environment just doesn't work running from a 64bit JVM. Setting up a 32bit JVM isn't that difficult, but it's not a good solution (However, I talked to a GWT developer on IRC who claimed this issue was high on their priority list).
Lastly, GWT is a nice environment, but it's still a bit young. It seems stable enough, but if you engage in a large GWT based project you may find yourself doing a lot of low-level client-side code unless their limited palette of widgets and other client-side features completely cover your needs
Is there anywhere I can find out how to make the Google DB accessible to software that can query only an LDAP API?
--
make install -not war
Just a few hours ago I finished a small, mostly-for-fun project in GWT, and now I see a GWT-related story on slashdot. Surely it's not a coincidence and therefore I must pimp my project: a chess board diagram composer.
If you have a team of Java developers who want to do pretty UI's and AJAXy things, GWT is a framework that lets you use Java to do that, IE: you use your strengths. It makes complete sense too -- essentially a web browser is treated like a compilation target. Kinda like writing C code that then builds assembly, rather than having to hand code the assembly yourself.
Anyone who has maintained a pile of Javascript for a few years understands the problem with hand coding javascript and/or the alternative javascript frameworks on the market right now -- lack of good IDEs/debuggers/tools like for other languages, among other problems. GWT counters this by allowing you to work with Java, and providing tools that integrate with your current toolset -- Intellij, Eclipse, NetBeans, etc.
Personally, I will be surprised if this model isn't the way we are all doing browser development within the next 5-10 years -- write your code in one high-level language and have it compiled into a given target (IE: turned into js, css, html, etc). This is exactly what has happened in the evolution of computing languages over the past 50 years, why shouldn't it happen in the web?
So glad to see this article on Slashdot. I've been a co-worker of Rob Hanson's since 2000 and in the near 20 years I've been in the biz I've yet to meet a better programmer. I'm no longer a developer and I haven't read the book yet (thanks for the free copy, Rob...not) but knowing his knowledge and dedication I can only assume that it is nothing short of excellent. Carry on...
It's actually not braindead. It makes a lot of sense, when you understand in more detail how javascript works...
But look up Douglas Crockford. He had one way of solving this: var that = this. Since Javascript supports closures, you can then refer to that, even in nested functions in which "this" gets overwritten.
Don't thank God, thank a doctor!
The writer of the review talks about how server side languages have a richness benefit, but client side languages, while less powerful, benefit from a wide installation base due to being included in web browsers. He talks about how GWT tries to bridge the gap, but I would recommend getting a book on silverlight, reading it, and using that instead. The current 1.0 version of silverlight is mostly just good as an online media player, but the 1.1 alpha version bundles a version of the .Net framework. Therefore, all that power you get from the .Net framework on the server side, you can ALSO get on the client side. And silverlight is cross platform. There've been a number of these "bridging" technologies that try to bridge these gaps, but silverlight definately looks more useful than GWT.
Beware of bugs in the above code; I have only proved it correct, not tried it.
I mean, there are plenty of things to hate about PHP, and even object-oriented PHP, but you can no longer complain that it doesn't have namespaces.
And Javascript is just far too flexible not to let you hack together namespaces on your own. Watch this (sorry about the lack of indentations; stupid Slashdot):
I highly recommend reading Douglas Crockford if you don't already know about tricks like this. From what I can tell, he's pretty much written the book on best practices in Javascript.
Javascript is at least as powerful as Ruby, if not more so, and the syntax feels a lot cleaner. But it has been awhile since I had to do any Ruby, too.
Don't thank God, thank a doctor!
In theory, any language could have a sufficiently good compiler to make it as fast as any other language.
In practice, the more powerful the language is, and the simpler a naive interpreter is, the harder it can be to make a good compiler.
Consider JavaScript -- you have to carry around enough baggage to be able to support random 'eval' statements. Or Perl -- common wisdom dictates creating classes as a hash table, because there's no such thing as actual object members in Perl. Technically, you could make a Perl object that's as fast as, say, Ruby or Python objects, but it requires some brutal hacks -- and since OO in Perl is already a brutal hack (though a bit beautiful, too), you know this is going to hurt.
Ruby must store and lookup all function and variable names at runtime as strings, in order to support things like the default method -- which is a method that gets called when it can't find a given method, with the name of that method as a string argument.
It's theoretically possible to make these languages faster, but in practice, I've found that things like Jython usually end up supporting a subset of the language and not providing much of a speed boost. Of course, that's mostly just a "feeling level", so I could be way off here...
I think that Javascript, Ruby, and friends could all be made faster than C. It's just going to take a kind of JIT compiler that I don't think anyone's seen before.
Don't thank God, thank a doctor!
Like many things, this can be hacked to be better in Javascript. Crockford's idea of a "superconstructor" is actually really useful, I think.
Don't thank God, thank a doctor!
Take a look on Wibokr, wibokr.com. There is demo available. Wibokr is 100% GWT-based wiki system.
While not disagreeing that product documentation could be better, have you seen the Wiki, and particularly http://cwiki.apache.org/WICKET/documentation-index .html ?
which I believe it is better than GWT, although not entirely similar (much better than echo2 though).
My major gripe about GWT ist the use of Java, which I never liked.
...
So I want to give oyou two pointers to projects that could need help to transfer the idea of GWT from Java to Python and Ruby:
Python: pyjamas - build AJAX apps in Python (like Google did for Java).
Ruby: Blog Entry from Michael Neumann, who tries to port GWT to Ruby.
The Ruby stuff is in the very early stages
Bye egghat.
-- "As a human being I claim the right to be widely inconsistent", John Peel
So he is saying he likes Java right? That's why he thinks it has a better IDE than say Visual Studio ?
... notepad ?
.Net stacking up against the slow pace of Java's early development I still have little faith in the language. Some of the worse viruses I've gotten came through my Sun Java folder and their updater splash screen shit is just annoying. It's just the best you got, it's not the best. Perhaps right now the biggest problem with Java is that it's become the standard teaching language meaning we have a huge proliferation of slow running cross platform apps that mostly run on windows anyway.
It's no biggie, but it seems the use of client-side vs server-side as an intro to his article was a bad choice. That just doesn't make a lot of sense. I think he should have clarified that he is explicitly talking about web based development only and not say Java applets compared to VB/SQL. He just should say something like web based client-side development or something because a 'client-side' apps are developed in the likes of Visual Studio, which you'd have a very hard time quantifying that comment suggesting that Java has a good IDE, compared to what
Cmon, C# is still shiny it's so new and it's IDE is already better than anything I've seen for Java, though ultimately the IDE need but be functional and user can adjust. Still this is a bad choice in terminology and even though it appears we are entering the web-centric world, I have my doubts that we will live up to this manifest web-centric destiny. Meaning, don't forget that non-web based programming isn't dead yet. Java may be the most popular modern language out there and certainly the most popular web language, but it's main advantage is by far being the first to the game not being led by a great company or community. I say Java IDE's suck and are only just IDE is a mistake and will eventually be changes. There is no real need for multiple competing non standardized IDE's, especially when none of them are making a lot of money. This is a major weak point for Java and with the realization of
I don't know about you guys, but the thrill of google is just about over for me. Their web search result accuracy has dropped considerably for a lot of topic and you can clearly see they are censoring and failing to check the majority of their sponsers. That's not going to last. Web search wise, google has entered the decline and I guarantee that cannot change. You can only be THE ONE for so long until everyone catches onto your game and then ruins your search engine by exploiting it's ability to find on topic content vs finding the content you pay the most to have listed the highest.
Riiight, so the only good web search has to be one run without sponsors and one that can resist the developing of business who exist only to skew your results as a service to other businesses looking for better advertising. Now, how to do that is beyond me, but google needs a new real product beside their search. Right now I see their collaboration tools as their best offering, though online office apps that don't suck would be nice also.
Really what's the hold up there, how long can it possible take to emulate MS Office and Outlook via the web and why wouldn't everyone and their mom want to be the first ones out there with a good looking and functional version of this. It's ridiculous that people are using things like Open Office, I mean Corel certainly offered more features 10 years ago than Open Office offers and with no worse of a look or interface. It's just a clumsy, feature lacking and sadly slow suite. You really can't expect to compete with a product as underdeveloped as Open Office. Their is no way someone can't put all the functionality of Open Office into an online suite of office apps years ago. It's just not being serious done. Lots of companies are making half assed attempts. I think they seriously don't see the long term profitability in owning corporate america's office suite choices. Though I know corporate america i
Are you in need for an easy-to-use, easy-to-understand (less than 1/2 hour), servlet-based framework to write your simple web-based applications? If so, have a look at Hamlets (http://hamlets.sourceforge.net). Hamlets is an open source framework with BSD license that allows you write your web applications entirely in Java. No Java in the HTML, no HTML in the Java, instead strict separation of content and presentation. Hamlets is simplicity and speed.
One of the most important points for using something like GWT has been missed: You can write test code for GWT very easily! If you ever tried to debug a mid-sized Javascript application, you know what I'm talking about. With GWT you have a hosted environment that makes debugging much easier. Also, you can employ Test Driven Development much easier. There is even explicit support for JUnit in GWT. For your favourite toy web application, GWT may be overpowered. For massive, distributed internet applications who need to involve the client side as much as they can, GWT currently is the best solution for Java shops.
Well, how about Adobe AIR?
If you read Ajaxian, you might have heard about this a long time ago. Its essentially the AJAX version of Java Webstart.
Never by hatred has hatred been appeased, only by kindness - the Buddha
I started with Perl CGI. Take a look at Django or Rails. The Java implementations have been way too heavy.
My guess is that you have been polluted by bloated Java implementations, and still only have a foggy idea of what OO is. True, OO is just a set of ways to organize and think about code along with its data. But if done right, it increases the effectiveness of your organization a lot. And like procedural programming, it can also be done wrong and cause misery. If you want to investigate something, you need to find the best examples of it. And to do that in OO, you can't *just* look in the Java world. There is much fine OO in the Java world. But it is only one slice of a larger pie. This is especially true for Web Apps.
From what I've seen GWT and other frameworks are just sweeping the dirt under the rug. The reason web apps are the Frankenstein of software apps is because they are layered on a protocol which wasn't designed for that purpose.
> But it will never reach its potential until it is a general purpose application programming language.
Why not use a general purpose application programming language like C to create internet apps?
http://www.newio.org/