More on getting started with AJAX using java. Beginners will find it interesting.
- Posted by: Joseph Kulandai
- Posted on: July 22 2010 10:56 EDT
- Is *anyone* this much of a beginner anymore? by Frank Zammetti on July 22 2010 11:56 EDT
- Getting Started with AJAX using Java: An Introduction by rags kidiyoor on July 22 2010 13:39 EDT
- Getting Started with AJAX using Java: An Introduction by Frank Zammetti on July 22 2010 14:38 EDT
- Getting Started with AJAX using Java: An Introduction by James Watson on July 23 2010 09:50 EDT
- What happened to GWT by Miroslav Pokorny on July 22 2010 23:00 EDT
- Getting Started with AJAX using Java: An Introduction by Ajit Panicker on July 26 2010 01:42 EDT
- Application Developer by Constance Irwin on July 27 2010 13:11 EDT
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.
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!
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...
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.
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.
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
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.