Getting Started with AJAX using Java: An Introduction


News: Getting Started with AJAX using Java: An Introduction

  1. Sometimes it's worth the time to just step back a little, and get familiar with the basics once again. Here's a great little tutorial by Praveen Kumar Jayaram that will help remind you of exactly what's going on when you have an Ajax call in your applications, and how the JavaScript and Java code running on the server works together. It's a good introductory tutorial, especially if you're just starting to manage those Ajax enabled components in your code:

    More on getting started with AJAX using java. Beginners will find it interesting.

  2. If you're doing AJAX and you're doing Java and you're NOT using DWR (and assuming you're not using a larger framework like GWT) then you're doing yourself a huge disservice.  It's almost unheard of in this day and age to be doing "naked" AJAX, as this article describes, but even using something like jQuery or Prototype seems antiquated after you've used DWR.  And yes, there's a few other very similar libraries out there now too, but DWR was the first (as far as I'm aware) and, IMO, still the best.

    While I don't generally have a problem with someone publishing a basic, introductory-level article like this, and while I ALWAYS think understanding the basics is very important even if you're going to be abstracted away from them day-to-day, I'd hate for any developer to think that this is the right way to do things anymore... oh, you can still come up with some cases where doing it at such a low level is warranted... but really, those cases are few and far between now and becoming more rare with each passing day.  Whether DWR or not, there's tons of better options these days and, if nothing else, I would have liked to see this article discuss that at the end.

  3. With all due respect, if you want to do AJAX, PLEASE use Javascript and develop your apps natively in HTML/CSS/Javascript. I know frameworks like GWT, DWR, and a host of others make it easy to develop web apps in Java and other high level languages, but developing apps is one thing and optimizing and continually improving them is another. With natively developed apps, you have full control on every aspect of the app.

  4. That's an age-old argument, and one I usually lean towards your point of view on... but there comes a point where it just no longer holds true. 

    For example, we're using ExtJS and DWR for all new projects where I am after much debate and research... and more importantly, after developing a very large and complex application (much larger and complex than most people do frankly) using 98% homegrown stuff... now, it worked, and there was even some real nice benefits to doing it... but it took a LONG time, A LOT of money, and it's just as difficult to maintain, if not more so, now... that's because only really 2-3 of us have the expertise to deal with all the details.  Over time, we've lost developers, some who weren't ever too good anyway but somehow got by (barely) and others that were OK but not great... the problem is you need top-notch developers to do something like we did and frankly there's just not enough of them out there.

    If you're doing a simple little app, it's probably not a big deal... but the larger and more complex the code becomes the netter the developers have to be.  It's very idealistic and even noble to say you should only hire top-notch developers, but the reality is there's not that many out there and the ones that are out there are typically unavailable or cost too much.

    Now, contrast our experience to where we are today... using ExtJS and DWR, our development times are a fraction of what they were, the cost by extension is significantly less, and we're able to get by without every last developer being an expert (we still WANT them to be, but you can get by with lesser developers).  Hey, I wish we could hire nothing but experts and the best and brightest, but very few companies are able to do that (aside from Google anyway).  Plus, we have functionality that we didn't before because we don't have to take the time to build it all ourselves, and more importantly, to justify that time and effort to the business.

    I'm 100% with you if you say there are times when building it yourself is better... and I've been extremely vocal over the years against developers who don't know the basics, can't get into details and simply can't think and who rely on their tools and libraries to get by... but at the same time, when you've been a professional developer as long as I have, at some point you see the other side of the equation... the benefits of using a good library versus building it yourself very often, most of the time actually, outweigh the benefit of that total control you mentioned.  And frankly, as powerful as some of these libraries have become, you wind up not giving up control anyway, and in many ways you gain MORE control because they're so robust and make so much available to you. 

    Remember, very few people can look at something as good as ExtJS and, honestly, say "I can do that".  Hell, I bet I *could* build ExtJS myself at this point, but it would take so long and take so many years of my life it could simply never be justified!

  5. With all due respect, if you want to do AJAX, PLEASE use Javascript and develop your apps natively in HTML/CSS/Javascript. I know frameworks like GWT, DWR, and a host of others make it easy to develop web apps in Java and other high level languages, but developing apps is one thing and optimizing and continually improving them is another. With natively developed apps, you have full control on every aspect of the app.

    Personally, I can't be bothered to relearn Javascript but if you use Wicket (or something similar) can't you define your own components if you wish to optimize them?

  6. What happened to GWT[ Go to top ]

    There seems to be a lot of javascript scattered about the posting, and givne the title mentions "JAVA" how could one forget GWT where one writes Java on both sides of the browser / server fence ?

  7. What happened to GWT[ Go to top ]

    Frankly, the ideal (but not often achievable) thing for you as a web developer would be to learn Javascript/HTML/CSS in addition to the back-end languages or frameworks of your choice. Create your own set of components - combo boxes, datagrids, pop-ups, etc -  i.e. those missing from the basic HTML. Really complex stuff. And then when it becomes difficult to maintain and extend your work or simply necessary to do so for business reasons, use something like ExtJS or Qooxdoo to make your life easier. Although most Javascript frameworks promise to shield you from Javascript, I've found that really knowing Javascript (as well as HTML/CSS) makes it easier to get the best out of whatever framework you may be using.

    GWT may be great, especially for Java developers, but I think it's best to code directly in Javascript for a number of reasons. However, the strongest arguments for GWT are the availability of high quality development tools and the type safety of the Java language when compared to Javascript. These are strong points to consider especially when the project is large and has to be coded and maintained by a fairly large group of developers.

  8. What happened to GWT[ Go to top ]

    Well, despite the fact that I really appreciate the work of the Google people that invented and created GWT, I think that I would only use it if I need a massive amount of client functionality - more or less a JS fat client, maybe with some RPC calls.

    But if the focus lies on server-side Java (which surely is our focus on this site here), I would rather use the Vaadin framework, which uses GWT in a generic way for rendering and AJAX. Here your application code IS server-side Java and STAYS server-side Java.

    If you don't know it give it a try...

  9. What happened to GWT[ Go to top ]

    I know about Vaadin. In fact my company was really considering it for a fairly large project a few months ago. At first, I was blown away by its nice looking components and read the Vaadin book. By the way, a very well written book considering the fact that Vaadin is open source.

    However, my investigations stopped when I realised that its UI components, widgets if you like, are generated on the server; even worse, their states are also managed on the server. For instance, selecting/deselecting a checkbox sends state changes to the server. I know a couple of other frameworks that do the same thing but it's not really ideal; especially in an environment where Internet connections are often slow and unreliable (yes, in Africa). And so we chose something else - Qooxdoo to be precise. It provided the ideal browser-based front-end to our JEE back-end. Disclaimer: I'm not affiliated to Qooxdoo in any way.

    In any case, these days we're seeing the emergence of a large number of client-side web applications based entirely (or mostly) on Javascript and the increasing popularity of frameworks like GWT attest to their viability. Once the browser loads the necessary js files, such apps are usually more responsive than their page-oriented counterparts and fit nicely into the AJAX philosophy. And there're some additional benefits too. For instance, in our own application, users can open up new tabs and fill out forms while waiting for their connection to be re-established. This was the functionality we couldn't get with Vaadin.


  10. too elementary.  I am sure, people coming to this page would know more than whats in here.  Guys, go checkout Seam with JSF on JBOSS.  It has AJAX and much more, esp. EJB 3 support is just amazing.  The best I have see lately.

  11. The reason I say this is because after reading the title of the article, at once I assume that its about using some Java framework that will do the AJAX part for me.

    However, the article is about elementary AJAX. The server side component could have been written in any technology (as long as its HTTP).

    I humbly suggest that the title is renamed to something like, "Getting Started with AJAX: An Introduction". This will take away the wrath of the readers :-P

  12. Application Developer[ Go to top ]

    We are a FFRDC(Federally funded Research and Development Company), specifically MIT Lincoln Laboratory; hence, we tend to stay on the bleeding edge as far as new development technologies are concerned. The tutorial was well written, easy to follow, and a good introduction to AJAX. That said, I am of the opinion that it is probably better to use some existing frameworks, like jquery or YUI; YUI is currently part of our java development stack, as is Hibernate, JPA, and Spring. We find that having a standard stack helps in terms of code maintenance and efficiency. I do not beleive that anyone starting with Ajax would assume that the tutorial is 'the way' to do Ajax. People evolve in their skills, as do technologies.