"The first form refers to pure JavaScript developments. Solutions, implementing this form are the most flexible and powerful. They allow creating amazingly rich user interfaces. However, because of well-known limitations of JavaScript, they are quite hard to develop, debug and maintain. In addition, if multi browser support is required, you will probably have to develop a second AJAX-free version of your UI. "

"Component oriented form is both flexible and easy to maintain. Components do not necessarily expose JavaScript to developers, thus making their job easier. Auto-complete or auto-validating text fields, AJAX-aware trees and updatable data grids are typical examples of this approach. Its main disadvantage is the scope that rarely exceeds a single component (or set of similar components). "

"The third form is sub-page oriented form of AJAX integration. It refreshes "zones" on the page. While being less powerful then other forms, it is ideally suited for upgrading existing projects. It does not have visible scope limitations and preserves the original MVC architecture (presentation controller stays on the server side). Another advantage of this form is graceful degradation possibilities. The same presentation code can support both AJAX and traditional modes."

"Unfortunately, all those forms seem to be mixed up under the same buzzword and compete with each other in developers? minds. "

"It is important underline the possibility or even necessity of different AJAX forms co-existence inside a single application. Why cannot an application that already uses pure JavaScript form of AJAX take advantage of a ready to use updatable data grid component? Why should not an application, being migrated with AjaxAnywhere or DWR use AjaxTags or another great tag library?"

" Although the technologies that make up what's being called AJAX aren't new, like any new approach or technology, I think we're going to see the usual stages: initial excitement and a lot of frankly bad work being done; people will get a little jaded as they get stuck trying to maintain AJAX apps that were done ad hoc; tools, pre-built components, and standardized design approaches will eventually stabilize things and AJAX will become another commonly-used approach."

"In the meantime, I think we all simply need to be aware of the existing limitations, and avoid creating massive AJAX apps lacking strong designs. Unless you like maintaining sites with pages containing many hundreds of lines of Javascript thrown in at random by inexperienced page developers! "

" You wouldn't put up with html people playing in your Java foundation code, so why let java coder play in UI centric stuff?..."

"It changes the nature of the people that you hire. If you can't find people that already know JavaScript, DOM, etc, then you need specific skill people. People that are very good bug hunters and people that are generally bright to pick up new things. People that tend to "play" a lot more than most. You need someone that's ready to go up against JavaScript's little idiosyncrasies."

"It's a different skillset, for a different app that really isn't just text processing in Java anymore (I know, there's more behind Html sites than processing text :) )."

"Having written an Ajax framework for my company's projects, and having to keep worthy developers up to working on it... it's not an impossible thing. Familiarity certainly helps though."

"There is a huge need for really dynamic and responsive applications, but they should be developed and modeled like Java Web Start applications or XWindow ones. "

"And JWS should be enhanced to be able to use central repository of common libraries ( log4j and alike) to avoid downloading them all over again even for tiniest JWS application. "

" Of corse, you are right... but only for the first form on AJAX: Application-specific JavaScript that play a role of presentation controller on the client-side."

"There are, however, lots of possibilities to avoid massive JavaScript coding. What about AJAX-ready components? What about sub-page refreshing solutions, like AjaxAnywhere? They do not require JavaScript coding. "

"I see Ajax, as just another tool in my client-side toolbox. Along with JSF, Swing, ASP.NET, Windows forms, Macromedia Flex, etc.."

"As long as every tool need a proper use, AJAX can be the best choise for some cases. Sometimes not. But to make a wise choise you need to understand all aspects and all forms of today's AJAX. "

" I'm not missing the point. Someone brought up the developer issue that happens when you go the high level of Javascript category. I mentioned that it's a different skillset you need to find developers with."

"I also said I'm firmly in the "very dynamic app, lots of JavaScript" camp... and everything I said supports it."

"I'm very ready to realise that there are other forms that take less advantage of the client JavaScript abilities... so it's all about components that plug into the server, just need to write Java etc. That's cool. Let someone else do the script for you. If your team has no idea about complex JavaScript apps and making them work, then this is most definitely the option that a lot of shops should take. I'm all for it too. Componentised structure is excellent, love it."

"The original item realises a reality that people are facing. They want AJAX, but don't want or can't handle the JavaScript burden. Some are willing for a little script work and so there's a middle road. All good."

"I know exactly what the news item is on about, and I know exactly what of the three camps I belong to. I've made an AJAX/component framework back when there was nothing available, and the acronym didn't exist... I'm riding the bleeding edge... please don't discredit me by saying I missed the point. I'm all over this AJAX thing :) "

" I think that everyone wants the first option, but the browser knowledge and DM knowledge and everything else is quite daunting to get up to speed with. There are many server side guys that know nothing of the client side. These guys are kind of high and dry with the first form."

"The way to attack it, is frameworks that simplify and organise the client layer for AJAX. Plain javascripts going at it without organisation is pretty painful. What's needed is the organisation of the client side, similar to what we have on the server."

"Model 1, JSP's just going for it on the server, gets very unwieldy. This is what most people see of the first option when it comes to AJAX. So what's needed, is frameworks that bring it up to Model 2 status."

"Not so much MVC (but that would be nice)... but a componetised structure that allows the client screen resources to be more easily managed. For events to be more easily managed and handled."

"For example... even just button handling events. In the framework I've written, we write component scripts. When you have a button, or an onChange event etc... rather than make another messy handler function next to all the rest, you just call out to the framework generic "doClick(this)" function. Every button on the screen does this. When the user clicks, the framework will find the component automatically, and call the "handleClick(button)" method for that particular component. Then the component can handle it."

"This has been working for hundreds of components on the screen. The script component is a big plus. We have to write the client script for each components, but it's helped manage the client tier in terms of coding, and helping developers who don't know anything more than Javascript get a helping hand in being productive in the client tier. They just interact with the framework API."

"So I say... it's that the custom scripts for the client side are unwieldy at the moment because they lack a framework to clean it up. Once it's cleaned up, you can have the high level of interactivity that everyone wants, without too much overhead in model 1 script woes."

" The bulk of the presentation logic is client-side, in your JavaScript code. Server-logic is relegated to data processing (ideally, sending/receiving XML data sets, but JavaScript-specific protocols like JSON are also possible)."

" A "traditional" web application, with some Ajax sizzle to make it better. This includes things like auto-completion, updating subsets of the page (like select lists or popups), etc."

"I think both (a) and (b) are valid uses of Ajax. Personally, (a) is the one I am most interested in, but, there are many classes of web applications for which (b) is better (online shopping is a good example)."

"I do think that a component-based, "no Javascript" approach is viable for (b), but it will not work for (a). To write a real, Google-map style JavaScript client, you are going to need real experts in the client-side technology. It is not like JavaScript is rocket science; there are good books out there, and a competent server-side developer can master the technology in time."

"Things will definitely get better, though, as the client-side frameworks mature and have better support for client-side MVC. "

"And I agree with you on the need of client-side framework, but it's not an option today. "

"I also agree that everybody wants the first form, but the majority of teams cannot afford it. "

"I am currently involved in a sub-page oriented solution development. It seems to me that this form is simply ignored. However, this is what business often needs. The difference between 1-st and 3-rd is huge; presentation controller stays on the server-side. Team can take full advantage of the server-side MVC framework, without employing JavaScript gurus."

"If you cannot do pure-JS, you can always do page zones refresh, and of course, you can add AJAX-ready components with their own JS inside. Customer will probably be happy with this."

"Is #3 not complicated enough to be considered as "another form"? Maybe, but it's powerful enough to satisfy a lot of needs. "

"The third form is sub-page oriented form of AJAX integration. It refreshes "zones" on the page. While being less powerful then other forms, it is ideally suited for upgrading existing projects. It does not have visible scope limitations and preserves the original MVC architecture (presentation controller stays on the server side)."

"Oh, so you mean AJAX hasn't rendered server-side MVC frameworks completely obsolete? Hmm, that's too bad as these frameworks have all really sucked and made server-side development an order of magnitude harder than just developing business logic as simply pure SOA beans."

"But this is just a transition, phase right? In the long run the MVC framework is none-the-less destined for the trash bin as users come to expect really cool behaving client-side experiences and page based web is viewed as ultra retrograde."

"Think of all the thousands of projects out there that have joined their business logic at the hip to one MVC framework or another as they've overly coupled themselves to a specific UI approach. Server-side MVC frameworks have inevitably locked an entire web industry into poor server-side architecture that they'll be years crawling out of. But that is the monster that ultra thin client has wrought... "

"Oh, so you mean AJAX hasn't rendered server-side MVC frameworks completely obsolete? Hmm, that's too bad as these frameworks have all really sucked and made server-side development an order of magnitude harder than just developing business logic as simply pure SOA beans...."

"This is a really odd statement to make and seems to stem from a lack of understanding of the purpose and application of current MVC frameworks. Clients built with these frameworks should ideally be consumers of your business logic and not implementers thereof. Most, if not all, of the popular/good MVC implementations say nothing about how you implement the business of your application, but are simply there to help manage the operation of clients consuming those services. "

"Great, you start seeing the difference between #1 and #3. All those things are still called AJAX. While the #1 is able (probably in future) to do the revolution of server-side architecture as you said, #3 does the opposite, it proposes an evolution."

"Think of all the thousands of projects out there that have joined their business logic at the hip to one MVC framework or another as they've overly coupled themselves to a specific UI approach"

"That?s exactly what I?m thinking about. Even if they need AJAX, they still do not want to throw away their existing investments. Right? Then they pick #3, a sub-page oriented AJAX solution. If they want to re-write the application, they pick #1. "

" Coincidentally there was a post today that talked about Microsoft's approach to the Ajax programming model in the form of Atlas:"

"Coincidentally there was a post today that talked about Microsoft's approach to the Ajax programming model in the form of Atlas:"

"I had written a follow up a while back on a different approach that didn't involve so much overhead: "

" He does rbing up a fantastic point. Ajax, and throwing a lot of the smarts into the client, you can trivialise the web handling tier out of sight. Our Ajax framework does all the fun stuff, and makes what is akin to an RPC call direct into our business tier. There's very little handling that has to be done by the servlet. parse and map, and a few other small things."

"If you have an SOA style business tier that fluently speaks XML... it makes fantastic sense to have the XML communication in AJAX speak directly to it."

"Speaking for our project... we don't have an MVC web tier any longer... completely replaced with the above, and so far it's been a big success. "

"I read your post on Avatar but I don't see why your approach is better than the Atlas approach. I probably need to do a lot more thinking but could you possibly take a look at this: "

"Of course I should probably be doing this myself but since you seem to have already achieved the Ajax Zen, I could just stand on your shoulders and see farther ahead :-) "

"JacobI read your post on Avatar but I don't see why your approach is better than the Atlas approach. I probably need to do a lot more thinking but could you possibly take a look at this: "

"and then tell me how Avatar is different?Of course I should probably be doing this myself but since you seem to have already achieved the Ajax Zen, I could just stand on your shoulders and see farther ahead :-)"

"Basically, there's less of a dependency on semantics within the client. A lot examples show extensive use of translating resources (db/file) to objects, then to communicate to the client, they again must translate to XML or some other format, then re-interpreted and re-rendered on the client. My suggestions within Avatar is that everything is retained at the server-- the rendering, coordination, etc, is retained within your OO code, the communication comes down to just being able to re-process parts of the view, like telling a Swing component to re-paint itself. I'm working on one such framework right now that is meant to work with existing MVC frameworks. "

"To elaborate a little bit more, the weakness in the transport layer, where your business models are more efficiently accessed on the server side-- while someone may believe having access to your models in the client may be the next big thing, really, you only want access to your models within the document you created on the server-- not the client-- JSP -> HTML. Then you start to look at if you were to have access on the client side to that model, how would you communicate it? And would it be any more efficient than just passing back the 'output' HTML? IMHO, I believe solutions that would transport model data back and forth would have a lot more overhead than simply calling 'methods' on the server side components and having them produce HTML back to the client-- maybe you don't need to have the whole object sent down for interaction with JavaScript, maybe on the server side, all you needed was the object's name to output. I dunno-- I'm rambling again. "

"AJAX would be a 100 times better if could dump JavaScript and use Ruby instead as the flagship client-side scripting language. And I have a "Trojan Horse" plan to do it:"

"This week-end at the No Fluff Just Stuff symposium in Seattle, I'm infecting the various speakers (who are now all fervently evangelizing Ruby) - such as Dave Thomas, Ben Galbraith, Bruce Tate, and others - with a virus of conspiracy that the next obvious move for Ruby and the advancement of Web 2.0 is to bring Ruby to the AJAX empowered client."

"Of course with the "Trojan Horse" plan I outline, SVG, XUL, perhaps Flash, and a flull blown queued and publish/subscribe capable messaging standard could also be incorporated into the Web 2.0 standard platform. IOW, by end-running around the browser via the concept of the AJAX daemon and the AJAX Widget, the rules get completely rewritten in one fell swoop. The world of the Internet Web thus gets truly reincarnated into a 2.0 rendention. The Matrix is reloaded. "

"My suggestions within Avatar is that everything is retained at the server-- the rendering, coordination, etc, is retained within your OO code, the communication comes down to just being able to re-process parts of the view, like telling a Swing component to re-paint itself.."

"AJAX would be a 100 times better if could dump JavaScript and use Ruby instead as the flagship client-side scripting language."

"I find it hard to tell if this is ironic or not. Assuming it isn't, then it sounds like yet another 'let's jump on the supposed Ruby bandwagon' idea."

"The true future of AJAX has to be based on components that hide as much of the client-side scripting as possible, and where Javascript-free alternatives can be automatically generated. "

"AJAX is surely only useful because all modern browsers have good JavaScript support bundled. Using another client-side language removes this advantage. If you are going to use another client-side language there is one that is proven and secure - Java. "

"LOL! Could not agree more. Of all the available technologies, it seems like the community has chosen the one least suitable for the hype of the day. "

"And the examples given make me stare in disbelief. Combo boxes that go to the server (using encrypted modem connections probably) to obtain possible auto completions? Impressive stuff like Google Maps that is years behind the decent map24 applet in all interactive capabilities. "

"Given the current discussions re. IE 7, this comes back in a full circle to where you can only deploy your ajax application in a fully controlled environment, anyway. And when you do that there are much better ways to develop stable and long lasting applications. "

"AJAX is surely only useful because all modern browsers have good JavaScript support bundled. Using another client-side language removes this advantage. If you are going to use another client-side language there is one that is proven and secure - Java."

"The browser is at an evolutionary dead-end. That is the point of my proposal for the Web 2.0 client-side platform. My proposal does an end-run around the browser in order to advance Web 2.0 client-side technologies."

"The AJAX daemon as a host for AJAX widgets (ala the Mac Tiger OS X Dashboard concept) is the "Trojan Horse" means to accomplish this. Oh, and the other side of this coin is to introduce an "iTunes" concept for AJAX Widgets so that a cottage industry for Widget making is established where consumers can buy a cool widget for a few bucks a pop."

"Wouldn't it be great to be able to earn some green stuff again for one's inspired programming talents? Crafting a cool AJAX widget would be just the kind of endeavor to unleash the creative juices - and earning something back for such expended effort would be a very nice icing on the cake! The time is now ripe for this because a lot of prominent web sites are now offering SOA services that an AJAX Widget will be able to tap into to do all manner of inspired things."

"So the AJAX daemon and the "iTunes" web site for AJAX widgets is a hand in glove concept. But it needs a seriously better runtime platform than the current web browser cul-de-sac. The AJAX Widget concept can't be truly unleashed until there is a daemon process to host it that is always there - just as the Mac OS X Dashboard process. And the richness of the standards the AJAX daemon provides to hosted Widgets needs to take a major leap forward beyond the anemic web browser and its myriad limitations."

"The primary programming language for AJAX Widgets needs to be very productive and very easy to master. Ruby near perfectly fits this bill. It's an easy language to learn yet covers enough language turf such that it is a broadly capable language that can do some seriously powerful things. As a dynamic scripting language it's highly productive - which is precisely what is needed for the crafting of AJAX Widgets."

"Web 2.0 will arrive when the web browser goes back to being relegated to hyperlinked pages that you read and navigate - while cool interactive programs (AJAX Widgets) are things you build for this new AJAX daemon runtime platform (which itself might be nothing but an installer that augments the existing browser install with the necessary Web 2.0 building blocks). "

"LOL! Could not agree more. Of all the available technologies, it seems like the community has chosen the one least suitable for the hype of the day."

"That's not necessarily the focus, IMHO, that should be pursued with AJAX in hopes of replacing the desktop at this point. We are still talking about the web pages. There's technology out there such as XUL which may be applicable, but where I see AJAX coming into play is in being able to immediately transition users without making a whole new request. The way that users interact with the web page shouldn't change-- click back button, click, back button-- it's the routine your grandmother can do. Put her in front of MS Word and she's gotta get a book our your ass over to show her how it works. AJAX can help bring that immediate responsiveness of a desktop to traditional web page interaction."

"In summary, Java WebStart will always have its place along side Web Browsers, but for those delivering applications over the web, jumping over to Java WebStart may introduce complex functionality beyond the click/back interaction that people are used to on the web. If you want to find some middle ground in certain cases, then pursue AJAX lightly. "

"Wouldn't it be great to be able to earn some green stuff again for one's inspired programming talents? "

"Actually, I think not. Maybe I have been in IT too long, but I would rather stick with one clean language throughout to construct my apps. My experience is that real programming talent is used in software engineering, not re-writing everything in JavaScript and/or Ruby."

"But it needs a seriously better runtime platform than the current web browser cul-de-sac."

"The AJAX Widget concept can't be truly unleashed until there is a daemon process to host it that is always there - just as the Mac OS X Dashboard process."

"And the richness of the standards the AJAX daemon provides to hosted Widgets needs to take a major leap forward beyond the anemic web browser and its myriad limitations."

"The same can be said for a large number of other established languages - Smalltalk, Scheme, Python etc."

"I'm afraid the use of 'Ruby' here still sounds to me like jumping on a bandwagon. There are no advantages to it, in terms of usability, performance or security. Just Hype."

"Web 2.0 will arrive when the web browser goes back to being relegated to hyperlinked pages that you read and navigate - while cool interactive programs (AJAX Widgets) are things you build for this new AJAX daemon runtime platform (which itself might be nothing but an installer that augments the existing browser install with the necessary Web 2.0 building blocks)."

"Also, your definition of 'Web 2.0' does not match what I seem to be able to find. From Wikipedia:"

"Also, Web 2.0 is "Purely web based - most successful web 2.0 sites can be used almost entirely through the browser"."

"So if you are doing an 'end-run around the browser', it's not Web 2.0."

"I know it is sometimes fun to re-invent the wheel, but hardly good as a general strategy for IT progress. "

"That's not necessarily the focus, IMHO, that should be pursued with AJAX in hopes of replacing the desktop at this point. We are still talking about the web pages. There's technology out there such as XUL which may be applicable, but where I see AJAX coming into play is in being able to immediately transition users without making a whole new request. "

"I just came back from NoFluffJustStuff symposium (good one, highly recommend it by the way) where I have attended among others Ted Newadrd?s talk on ?The Fallacies of Enterprise Computing?. There are those 10 fallacies:"

"Lets just look at the Ajax with the fallacies in mind and lets especially consider items #1,2,3,4,and 7. It is not even funny? "

" Thank the Creator(s) of Ruby for creating yet another language that can save the world -- an marvelous missions attempted by Perl, Python, PHP, ...! But I have yet to find any trace of proof that Rube can rule the World. "

"Lets just look at the Ajax with the fallacies in mind and lets especially consider items #1,2,3,4,and 7. It is not even funny?"

"All the while iTunes is an immensely successful application that artfully uses web services and rakes in millions in revenue. Apple does the most skillful job of all of seamlessly integrating Internet web services into various aspects of their operating system features and their various applications."

"And now they've introduced Dashboard which is a runtime expressly for hosting applets (widgets in their parlance) that are constructed out of HTML, DHTML, JavaScript, and AJAX style io. Dashboard Widgets are expressly designed to run in their own window and do all their own UI handling. They have nothing to do with the browser web page paradigm. They are declarative UI applets with procedural actions implemented via scripting language."

"The reality of Mac OS X vividly illustrates that not only can all this be done successfully - well, gee - it already has been done. I think that is the point that shouldn't be missed here, folks. From a Macintosh user experience point of view, all these counter arguments and objections are without any substance. The last laugh goes to OS X users."

"BTW, it would only be fair to mention to readers of this thread that this latest No Fluff Just Stuff symposium held in Seattle had numerous presenters and sessions that were all about Ruby and Ruby on Rails. Everywhere you turned - even in the presumably Java-centric sessions - conversation on Ruby (and Ruby as the next tipping point in software languages) would come up."

"Dave Thomas had a great intro session on Ruby and followed with another excellent session that introduced Ruby on Rails (and this impression coming from a guy that usually detest all manner of server-side web development - give me rich clients and messaging-based SOA middle-tier). Even JSF guru, David Geary, presented a session on Ruby on Rails (the story on Geary is that's he's gone through an "Apostle Paul Road to Damascus" experience and has pretty much converted from JSF into the Ruby camp now). In Bruce Tate's session on Beyond Java, Ruby and Ruby on Rails definitely figured into the mix of that talk. Ben Galbraith had a great intro session and an advanced framework session for the AJAX client-side of the equation."

"Okay, I did actually manage to go to one session where Ruby didn't get mentioned at all - the Enterprise Service Bus talk by Mark Richards. Java looks like it will still have a good bit of traction in that space. But if there were a JRuby container for my J2EE app server in which I could write my message driven beans in Ruby, I'd probably switch. These kind of languages are just more productive. "

"Yes, Java made great strides over C and C++. But it really is possible to be even more productive with dynamic typeless scripting languages - if they're good languages with sufficient expressive power. I've done many thousands of lines of perl for business production programming. It's great for getting a lot done in a hurry without all the tedium that goes with a Java programming approach. What I like about Ruby is that it has similar power to perl but cleans up practically every bad or annoying thing that I didn't like about perl - it also adds several features that go beyond perl 5. (Sorry Perl 6 - you guys are going to be way too late to the game to be relevant anymore.) "

" I really don't want to get into a RoR vs Java debate-- wait, yeah I do."

"There's no reason why Java, with things like EJB 3 can't be just as productive as RoR. With RoR, you are tackling the problem from the DB layer, but with EJB 3, you are doing so from the Model layer via simple, or implicit annotations. You can run an ant script to take those annotations and create your DB if you want. Also, Christian (I think) from JBoss wrote a bit on generic DAOs with Hibernate that could apply to EJB 3 too."

"I will give you that the main appeal of RoR is that there are lots of implicit capabilities-- which shorten development time. I've started to see some frameworks do this already. As a personal example, there's Facelets and then there's JSP-- JSP requires you to write lots of descriptor XMLs and Tags, where Facelets just implicitly auto wires everything to your objects."

"As for AJAX, I think that the ideas used in RoR are old news. Stripes is able to do the same thing (actually any traditional MVC framework, just by using Prototype.js too :-))."

"If anything, I believe Ruby and RoR will simply act as a benchmark for the Java community on how to ease development, we're already seeing it rapidly adapt to meet that standard. "

". From a Macintosh user experience point of view, all these counter arguments and objections are without any substance. The last laugh goes to OS X users."

"Being a Macintosh user half of the day, I can assure you that it is indeed very hard to find even a single decent usable valuable Dashboard Widget, bar "Dilbert of the day"."

"Let alone the responsiveness that you get from them. A weather widget, that takes minutes (without user feedback) to show you the weather. YAC (Yet another calculator), oh please...."

"iTunes, by and large, looks like a traditional Objective-C application to me and its main focus is to arrange play locally stored music (and movies) anyway, and not go and fetch stuff from the web (where its main revenue originates, but this is a different story). That it needs to go to the network to do this is hardly surprising and the actual protocol used to do that should be the least relevant question in designing the remote interaction. "

"I'm working on one such framework right now that is meant to work with existing MVC frameworks."

"I am also working on a solution for upgrading existing JSP/Struts/Spring/JSF/etc.. projects without breaking their MVC architecture ( "

"As we are already going in the same direction, we could probably collaborate in some way. What do you think? "

"With RoR, you are tackling the problem from the DB layer, but with EJB 3, you are doing so from the Model layer via simple, or implicit annotations."

"Me: "But working from the DB layer is old-fashioned, restrictive, and leads to problems with portabibility""

"Them: "Well, OK, this is a problem, but you don't have to use Rails. You can use alternative ORMs for Ruby""

"Both JDO and EJB 3 work from the model layer, and I have seen plenty of tools (well at least for JDO - I am sure they are there for EJB 3 as well) that allow working from the DB layer as well, and keep code and schema synchronised. With these tools set up as ant tasks, so they are part of the build, then you have a persistence situation that can be as simple as Rails, but faster and more robust - they can update your code automatically. (Some of these tools have been around for far longer than Rails has been widely known)."

"If anything, I believe Ruby and RoR will simply act as a benchmark for the Java community on how to ease development, we're already seeing it rapidly adapt to meet that standard."

"As long as it does not act as a benchmark for ease of development in the way that Visual Basic did - by allowing sloppy coders to get up quick-and-dirty fixes that lead to messy unportable code, tied in to one database. I fear that it will. "

" old debate that has not come to a conclusion one way or the other over decades. Exactly the same arguments were being put forward in the Smalltalk vs C++ 'battle' as to the dominant OOP language in the 80s."

"So, sorry for sounding cynical, but I just don't accept that dynamic typeless scripting languages are more productive generally. You have to describe the situation. For example, in the 80s C++ won out in general use because it allowed legacy code to be used and because it was 10x or more faster than Smalltalk, however Smalltalk was used (and still is) in many specialised areas. Specifying Ruby (and similar languages) as generally more productive is far too simplistic. "

" Nice classification and I think modern web applications will use all three kinds for reaching better usabiltity. Yes, old standard web interface is too complicated for users and we have to find a way for making their life easier that they wouldn'f fill less comfortable using web interface than standard GUI. I think we're close to it as never before, look at for example "

"Yes, old standard web interface is too complicated for users and we have to find a way for making their life easier that they wouldn'f fill less comfortable using web interface than standard GUI."

"I certainly don't agree that the standard web interface is too complicated for users. On the contrary, I have found that users have a general opinion that the web is 'friendly' and they will use all sorts of controls and features on a web page that they would hesitate to use in a standard GUI."

"You have to describe the situation. For example, in the 80s C++ won out in general use because it allowed legacy code to be used and because it was 10x or more faster than Smalltalk, however Smalltalk was used (and still is) in many specialised areas. Specifying Ruby (and similar languages) as generally more productive is far too simplistic."

"Agreed. And don't forget it depends on how you use a language. For example Java is more and more forced into usage as an actually untyped language where we pass objects around - preferably using a messaging mechanism - or where generic methods like "doSomething" are defined way up in the type hiearchy :-). "

"I am currently waiting for the next wave of "Unsafe languages leads to more stable software" debate :-) "

"And now they've introduced Dashboard which is a runtime expressly for hosting applets (widgets in their parlance) that are constructed out of HTML, DHTML, JavaScript, and AJAX style io. Dashboard Widgets are expressly designed to run in their own window and do all their own UI handling. "

"the net result ? I do not use the dashboard because it takes ?forever? (subjectively) for those widgets to display information they are supposed to display."

"Dave Thomas had a great intro session on Ruby and followed with another excellent session that introduced Ruby on Rails (and this impression coming from a guy that usually detest all manner of server-side web development - give me rich clients and messaging-based SOA middle-tier). "

"Hmm, with all my respect to Dave I consider the session to be really bad, might be because it supposed
... read the whole article