Welcome!

Machine Learning Authors: Pat Romanski, Yeshim Deniz, Liz McMillan, Elizabeth White, Zakia Bouachraoui

Related Topics: Java IoT

Java IoT: Article

A Cup of AJAX? Nay, Just Regular Java Please

The idea is noble: instead of rendering an entire HTML page on each little change on the page

These days everyone is talking about AJAX. It’s supposed to be a cool way of creating Web applications.

The idea is noble: instead of rendering an entire HTML page on each little change on the page, it’s much better to send an asynchronous request that will  get the data for you and refresh only the relevant portion of the screen. Every author writing on AJAX is giving the same (the only? ) example where this technology is being used: Google maps and email. (BTW, I’m a little sick of these examples). Since I’m not going to be helping Google in improving their maps, I’d like to see some real-world examples implementing  this technology.  Ajax proponents will immediately come with this exciting example of how great it is to refresh some  screen info as the user enters character in a text field. And here's  a sample conversation that might have happened between an imaginary  AJAX supporter and myself.
  •  See, I’m just typing the letters of the person’s name and it prompts me with all potential candidates like in Microsoft Outlook
  •  Wow! I like it… as long as you do not have to be a rocket scientist to program this functionality. But wait a minute, do not you think that any entry level Visual Basic/PowerBuilder/Java programmer can do the same thing easily? AJAX applications have to rely on JavaScript, assume the expert knowledge of this not-so-interesting language, different Web browsers may give you different serious issues, may not even always report the problems in communication between you browser and the server, yada-yada-yada..   
  • Yeah, but we want this functionality under the Web browser.
  • But what about using Java Web Start (JWS) to launch the full-fledged Swing clients? They can easily process events, work the same way under each operational system?
  • Yeah, but what if your users  do not have   the JVM?
  • But JWS can download it automatically for you.
  • Yeah, but what if you are Google, Amazon or EBay and want to have a very thin client.

OK, now we’re talking.  I can agree that big Internet guys can and should invest some serious dough into supporting screen-refresh-on-mouse-move in HTML-based screens. But when it comes to a regular Intranet business application,  when the users/browsers/platforms are known and  when the  cost of the project development matters, I’d stay with a fat client written in Java, or (if you like a fancy GUI)  Adobe  Flex.

Many vendors  are happy to offer you a tool to simplify AJAX development, because it’s the right momentum to do so. But development is just the beginning. What about production support? I have a gut feeling that starting an Ajax project is like one way street: it won't be easy to  go back. The users will be more and more demanding, and you'll be spending  most of your time on adding more bells and whistles to the GUI instead of solving  business problems.

Today's  Business Week has published a surprisingly shallow article called "Java? It's so Nineties".  First, a former Sun's employee explains that LAMP is the way to go. After that they say that the number of published books in Java is 4% off this year while sales of AJAX books is up 68%. Sure, if last year there was just one AJAX  book and now there are three of those, we can even talk about 200% increase.

Having said all this, I have to admit that I also include the talks on AJAX in my Weekend With Experts seminars, because it’s a buzzword and people want to hear about it, but as of today, I’m not going to invest my time in mastering this technology. I’m staying with the good old Java.

More Stories By Yakov Fain

Yakov Fain is a Java Champion and a co-founder of the IT consultancy Farata Systems and the product company SuranceBay. He wrote a thousand blogs (http://yakovfain.com) and several books about software development. Yakov authored and co-authored such books as "Angular 2 Development with TypeScript", "Java 24-Hour Trainer", and "Enterprise Web Development". His Twitter tag is @yfain

Comments (18) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
rdgflex 06/30/09 12:22:00 AM EDT

I was amused when AJAX came out, as though it was some great invention to be able to finally perform asynchronous calls. Before it was called AJAX (pre Windows SP2 days before they put the security screws on x-frame scripting), I was doing the same thing. All that was needed were several invisible HTML frames, making multiple web service calls, directing each web service response to a different invisible frame, and then have the returned contents load itself (via JS, inserted into the returned HTML that was server side rendered by XSLT) into the visible display area. Now, people put a name (AJAX) on an old set of tool with a new API and think they've got the latest and greatest.

R. Grimes

paulm 12/12/06 09:06:34 AM EST

Jakov,
I had the same opinion as you until I found Echo2.
Now I can program in old plane Java but have it displayed in the Web browser window.

JDJ News Desk 12/02/06 07:26:28 AM EST

The idea is noble: instead of rendering an entire HTML page on each little change on the page, it's much better to send an asynchronous request that will get the data for you and refresh only the relevant portion of the screen. Every author writing on AJAX is giving the same (the only?) examples where this technology is being used: Google maps and email. (BTW, I'm a little sick of these examples). Since I'm not going to be helping Google in improving their maps, I'd like to see some real-world examples implementing this technology.

David Small 11/28/06 04:19:20 PM EST

SWING's GUI is only has an advantage as deep as their widgets toolkit. As AJAX widget/libraries build-out and standardize that advantage will disappear. To a large extent that has already happened. Currently, I spend more time working on my business/data layer than my AJAX layer. This runs counter to Yakov assertion that I'm bogged down in GUI work.

Plus, I don't have to worry about getting my user base on-board with downloading a JVM they may or may not want on their local machine.

Yakov 11/15/06 10:15:47 AM EST

Mike,

Yes, this was an old article. I feel the same about Ajax being not a good choice for business applications. My today's choice is Adobe Flex as a front end for server-side Java applications. Swing is too complicated for deployment and too expensive for development.

You can find my Flex-specific articles and links to presentations at our company's blog: http://flexblog.faratasystems.com

Mike Addesa 11/15/06 07:04:42 AM EST

I am curious about the timing of this article. It looks like it was posted in Yakov's blog in December of '05, but was published on this site in October '06. Given the pace at which technologies seem to move these days I wonder if Yakov feels the same now as he did 10 months ago?

j j 09/27/06 07:25:15 PM EDT

The idea is noble: instead of rendering an entire HTML page on each little change on the page, it's much better to send an asynchronous request that will get the data for you and refresh only the relevant portion of the screen. Every author writing on AJAX is giving the same (the only?) examples where this technology is being used: Google maps and email. (BTW, I'm a little sick of these examples). Since I'm not going to be helping Google in improving their maps, I'd like to see some real-world examples implementing this technology.

Colorado HomeFinder 06/14/06 12:54:12 PM EDT

Have a look at this real world example of GWT, Google's AJAX web toolkit:
http://www.cohomefinder.com/Colorado-mortgage.htm

Our GWT mortgage calculator is a simple application we are using evaluate the GWT framework. We are documenting the steps to get this up and running and providing source on Dan Moore's blog:
http://www.mooreds.com/weblog/

Mike 04/28/06 05:01:37 PM EDT

I have to agree with this 100%, but I'd like to add that in response to the worries about people not having java, or statements about the ubiquity of javascript I started hunting around for stats about browsing statistics. Found a couple of sites, (banner ad suppliers), that published that sort of info and found that indeed, the Ajaxistas were right, Javascript was available and usable in somewhere around 94-96 percent of browsers, whereas Java was available in between 93.5-95.5 percent of browsers...I think I'll stick with java after seeing those sorts of statistics! ;)

Yakov Fain 04/19/06 06:18:43 PM EDT

LCB,

I can agree with your statements regarding Web Start. I would not suggest JWS for Amazon and other applications that are used by thousands of customers. Try not to miss the article on RIA development with Flex and Java that will be printed in May's issue of JDJ. You'll see not so trivial application written with minimal code. You'll see a good example of a public facing application (I'm sure that the public won't mind pressing the button and to download a Flash player)

LCB 04/19/06 05:13:02 PM EDT

I prefer Swing - it is a lot easier to use and more robust.

However, even for Intranet apps, there are clients who just won't accept Webstart apps for various reasons. Those reasons, justified or not, are hurdles to acceptance and sales. The client says they want a web client for various reasons, won't be convinced otherwise - they get a web client if you want to sell your software to them. When it means half a million dollars in revenue, you don't just walk away.

And I can see some of their reasons as being halfway reasonable and applicable; security, maintenance, not wanting to have to hassle with deployment - whether they really apply or not to a Java Webstart app or not is debatable (for the most part they don't) but customers have their minds made up.

Then there is the public facing app - where companies want to have some subset of the applications facing outwards to the public. As an employee to a company I don't mind using Java apps that Webstart onto my desktop, but if I want to go do some banking business I want a webclient - and it is not just Google or Amazon who need this, it is auto parts stores, grocery stores, banks, credit unions, and many other small volume businesses.

AJAX, used where appropriate, and in moderation, can be helpful/useful. It is not the answer to all problems, it is just another tool - and I personally don't view it as such a big deal as many others seem to. But it is new, so all the hype that goes with something new gets attached to it. *sigh*

SYS-CON Belgium News Desk 04/11/06 07:17:01 PM EDT

The idea is noble: instead of rendering an entire HTML page on each little change on the page, it's much better to send an asynchronous request that will get the data for you and refresh only the relevant portion of the screen. Every author writing on AJAX is giving the same (the only?) examples where this technology is being used: Google maps and email. (BTW, I'm a little sick of these examples). Since I'm not going to be helping Google in improving their maps, I'd like to see some real-world examples implementing this technology.

JDJ News Desk 04/11/06 03:35:52 PM EDT

The idea is noble: instead of rendering an entire HTML page on each little change on the page, it's much better to send an asynchronous request that will get the data for you and refresh only the relevant portion of the screen. Every author writing on AJAX is giving the same (the only?) examples where this technology is being used: Google maps and email. (BTW, I'm a little sick of these examples). Since I'm not going to be helping Google in improving their maps, I'd like to see some real-world examples implementing this technology.

Steve Benfield 12/14/05 02:28:55 PM EST

>> But wait a minute, do not you think that any
>> entry level Visual Basic/PowerBuilder/Java
>> programmer can do the same thing easily?

First, entry level developers can't do much to begin with. But they can use tools--as can intermediate + advanced developers. So what you'll see growing around AJAX are tools and frameworks--in droves.

So, a better way to phrase the question is--can VB + PowerBuilder developers build their current apps *without* the tools they use--probably not. And even if they can, who wants to? It takes too long because hand-coding GUI is painful--something that is only for people that have too much time, bililng by the hour, or who have some very stringent functionality and/or performance goals.

So, yes, I believe these programmers can build AJAX applications--with the right tools + frameworks.

It is easy to say, just build it in Swing instead--but AJAX provides ubiquity across browsers with no special downloads--and its backend independent. So you're free to choose a backend language and server whether its Java, PHP, .NET, Ruby, etc. Today, AJAX techniques can cover maybe 80% of the client/server GUI apps you might want to build. I predict more in the future.

If you need to deliver apps to a mix audience--or you want to use a common set of programming techniques for your public and internal applications--then AJAX provides that. Any other downloadable medium does not although flash gets closer than anyone.

Full disclosure: I represent a company that provides ThinkCAP JX, an open source, J2EE-based AJAX development environment + framework.

--Steve Benfield
ClearNova

Baz Web Development: Ajax, FastCGI, Joomla 12/13/05 09:12:57 PM EST

Trackback Added: Ajax vs. Ordinary Java; Yakov Fain wrote an interesting article: A Cup of AJAX? Nay, Just Regular Java Please at SYS-CON DEUTSCHLAND.
I can agree that big Internet guys [Google] can and should invest some serious dough into supporting screen-refresh-on-mouse-move in HTML-ba...

SYS-CON Germany News Desk 12/13/05 02:20:18 PM EST

cup of AJAX? Nay, Just Regular Java Please
The idea is noble: instead of rendering an entire HTML page on each little change on the page, it's much better to send an asynchronous request that will get the data for you and refresh only the relevant portion of the screen. Every author writing on AJAX is giving the same (the only?) examples where this technology is being used: Google maps and email. (BTW, I'm a little sick of these examples). Since I'm not going to be helping Google in improving their maps, I'd like to see some real-world examples implementing this technology.

JDJ News Desk 12/13/05 01:46:23 PM EST

A cup of AJAX? Nay, Just Regular Java Please
The idea is noble: instead of rendering an entire HTML page on each little change on the page, it's much better to send an asynchronous request that will get the data for you and refresh only the relevant portion of the screen. Every author writing on AJAX is giving the same (the only?) examples where this technology is being used: Google maps and email. (BTW, I'm a little sick of these examples). Since I'm not going to be helping Google in improving their maps, I'd like to see some real-world examples implementing this technology.

CloudEXPO Stories
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions need to be truly scalable. Far from it. There are at least six major pain points that companies experience when they try to deploy and run Kubernetes in their complex environments. In this presentation, the speaker will detail these pain points and explain how cloud can address them.
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-centric compute for the most data-intensive applications. Hyperconverged systems already in place can be revitalized with vendor-agnostic, PCIe-deployed, disaggregated approach to composable, maximizing the value of previous investments.
When building large, cloud-based applications that operate at a high scale, it's important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. "Fly two mistakes high" is an old adage in the radio control airplane hobby. It means, fly high enough so that if you make a mistake, you can continue flying with room to still make mistakes. In his session at 18th Cloud Expo, Lee Atchison, Principal Cloud Architect and Advocate at New Relic, discussed how this same philosophy can be applied to highly scaled applications, and can dramatically increase your resilience to failure.
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by sharing information within the building and with outside city infrastructure via real time shared cloud capabilities.
As Cybric's Chief Technology Officer, Mike D. Kail is responsible for the strategic vision and technical direction of the platform. Prior to founding Cybric, Mike was Yahoo's CIO and SVP of Infrastructure, where he led the IT and Data Center functions for the company. He has more than 24 years of IT Operations experience with a focus on highly-scalable architectures.