Questioning AJAX
Two days ago at the OCI internal Java lunch, Mark Volkmann gave a presentation about AJAX, with the obligatory music collections browser, complete with speculative auto-completion and cascading child record table population (and a Ruby web server getting ActiveRecords from a MySQL database to boot.)
I have refrained from commenting on AJAX except for a gut reaction piece 161 days ago when Google Suggest hit the internet.
Several things happened since then: Google Maps was released and I dumped my previous internet mapping/driving directions provider within a couple of hours; And the term AJAX was coined by Jesse James Garrett to highlight the technologies that are involved, especially the XMLHttpRequest object.
Here's some of my impressions after seeing the demo in person and going through the code line by line:
It Works
The demo works. The response to key stroke events are instantaneous and screen repaint is fast. It feels like a desktop application. This may be the most important lesson I learned. With Google Maps, my reaction was different, something along the lines of "Google is a billion dollar company. Can the average IT guy handle this?" Apparently he can.
It's 99% DOM and JavaScript
Mark scrolled through the server side code really fast, saying something to the effect "This is all Ruby code. Had I written it in Java, it would be just as boring and much longer."
The focus, of course, is on client side code. It's all conventional JavaScript code. The thing to keep in mind is that there is nothing new in the JavaScript. You can add keyEvent handlers to text fields, dynamically modify the content list boxes, text areas, add and delete rows to HTML tables and change the content of table cells since forever.
The highlight of the entire presentation is the following few lines of JavaScript (pseudo)code:
// method="GET"; // url="http://localhost:8080/music/blahblah"; // asynch = true; var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function() { if (readystate == 4) { var domDoc = xhr.responseXML; // use it } } xhr.open(method, url, asynch); xhr.send(null);
XML Is Non-essential
XMLHttpRequest talks with the web server at the other end of the URL through normal HTTP. It sends a request and the web server sends a response. The data communicated doesn't have to be XML. But if the data sent back from the web server happens to be XML, XMLHttpRequest turns it into a DOM. As far as the web server is concerned, this request is just like any other.
Asynchrony Is A Queue And A Thread
If I have to implement something like XMLHttpRequest in Java, I would have used a queue and a thread. The caller pushes a command object that contains the data and a pointer to the callback onto a queue and returns. A thread constantly watches the queue and acts upon each incoming command object, performs it, either in its own thread or farms it out to a worker thread, and calls the callback handler when the response arrives.
Why Is It Such A Big Deal?
Apparently you cannot do this in plain JavaScript. Client side JavaScript does not provide the classes for thread or communications programming (except for calling into Java using the applet/LiveConnect mechanism.) As soon as people realized what XMLHttpRequest can do, they jumped on it.
AJAX Is Not RESTful
In the demo, all the XMLHttpRequests are done in the REST style: each request is a GET with a URL that contains the appropriate query string, and the response would be a simple XML that contains just the data, no SOAP, no fancy schemas to wrap around anything
That's all good and wonderful. However, I have a feeling that by using AJAX techniques, you have already made your main page non-RESTful. There seems to be a bit irony here.
XMLHttpRequest Is Not Standard
As far as I can tell, XMLHttpRequest is not a standard class. It just happens to be available in both IE and Mozilla/Firefox. The way to create an instance of this class is different in each browser. Mark used a JavaScript library called Sarissa to paper over the differences.
It's kind of odd to see the web developer crowd, who usually chants "standard based development" the loudest, to be so enthusiastically attracted to a proprietary class like this (and a Microsoft one at that!) I wonder if they mind that Sarissa is doing something like
var xhr = new ActiveXObject("Microsoft.XMLHTTP");
behind their back.
Come on guys, get the standardization process going. Someone write a W3C Note or something.
A Net Gain For Web Developers
From a web developers perspective, AJAX in an improvement from both the user interaction experience perspective and the network load perspective. So if you are already developing web applications by all means add the XMLHttpRequest class to your repertoire.
As your web applications become more like a traditional desktop application, the complexity will also rise. The current state of the JavaScript language dictates that the web application will always be inferior to a traditional desktop application in all respects except one—world wide deployment.
For example, Mark had a question about how to include one JavaScript file in another JavaScript file.
The Pendulum Swings Back
Alan Wang made a comment that the AJAX movement means the pendulum is swinging back to the client side after a decade of doing everything on the server.
But You Can Do This In Flash/Applets/Whatever
Yes, yes, and yes. But it doesn't matter. AJAX is the path of least resistance. For most web developers, learning a new class with a handful of methods is much easier than learning a new development/deployment environment and a new language.
What About GUI Thread Starvation?
If you are a Swing developer and have done your share of sophisticated Swing GUIs, you would cringe a little when I mention the word thread, especially ones that update the display. Add asynchronous events into the mix and you have a recipe for months long bug fix phases of development.
It would seem to me that AJAX would push web application development closer to all of those. Maybe it will become an issue when web applications start to create thousands of little XMLHttpRequests, fire them off at the same time and watch the response come back in arbitrary order. But right now it doesn't seem to worry anybody.
Should we? I don't know. Have you experienced a website that's not just slow, but also slows down the entire browser?
What About Thread Safety and Concurrency?
If you've done threaded programming a lot, some natural questions to ask are: "Can multiple asynchronous XMLHttpRequests be outstanding at the same time? In which thread are the callback handlers run? Are there any concurrency concerns?"
I don't know the answers. Client side JavaScript is full of event handlers, most of them asynchronous, so I assume the browsers have this one figured out.
Is It Still A Web Application?
Of course it is. It runs in the browser. But!
It will be harder to develop, harder to design, and harder to fit the application within the web browsing experience. The Back button will become less intuitive. The Stop button will cease to be an indicator of the presence of any web activity. The Refresh button will probably be disastrous if clicked.
In essence, you are developing a web application in name only. The expectations/experience impedance will be the down fall of AJAX.
From a development perspective, especially for new projects where I have a choice between Web vs. Swing (or some other GUI technology) the line needs to be drawn differently: Instead of dividing them up like this
- Web apps, including traditional (request/response) and AJAX
- GUI apps
I would divide them differently now
- Request/response web apps
- Rich apps, including AJAX web apps and GUI apps
What Else Is Already In The Browser That We Are Not Using?
If XMLHttpRequest has been in the browsers for a long time without us seriously using it, a natural question to ask is "What else is in the browser that we are not using?"
If we are happily using a proprietary class in IE (that is subsequently made available in other browsers), can we do the same for some of the Mozilla/Firefox features? After all, it's much easier to take a feature that already works in Mozilla/Firefox and make it available to IE (as an ActiveX object, for example) then going the other way around.
Can we? Can we? XUL? Trees? Menus?
JSR 274: The BeanShell Scripting Language
(Saw this on Eduardo Pelegri-Llopart's Blog, via JavaBlogs.com)
Patrick Niemeyer, JSR 274 Spec Lead: While there exist many scripting environments for Java, the Java platform currently lacks a standardized, "native" Java scripting language which supports dynamic evaluation of Java code as well as common scripting language conventions.
The inclusion of BeanShell in the J2SE will provide a standardized, dynamic language for page construction and web services that is implicitly understood by all Java developers.
You Think, You Lose!
Ever since I started programming, I've heard studies about how programming productivities vary among individuals. The fastest programmers are easily 20 times more productive than the average ones.
I believe I've found out why: They don't think.
Or rather, I slow down when I think, with no discernible benefits.
Thinking, especially the kind where no tangible output is generated, including developer meetings where everyone just talks (and talks, and talks,) is useless.
I made the connection when I was doing grocery shopping yesterday. When I shop, I have a list and go through the store picking up what I need. And I get out of the store in 30 minutes. But another couple I saw didn't do it this way. They would stop at, say the pickles shelf, pick up each jar and read the labels, probably comparing the ingredients and calculating the price per once in their head. They probably got the healthiest jar of pickles at the most favorable price. But they also spent 20 times longer than most people.
Just think:
- If you don't know what the customer wants, thinking won't help you
- If you are not clear about an algorithm, thinking won't help you
- If you don't know the consequences of some design decisions, thinking won't help you
- If your algorithm has multiple branch points as to make the execution scenarios hard to imagine, thinking won't help you
- If your thinking is along the lines of "writing pseudocode in your head and interpret it with your brain," you are wasting a perfectly good computer sitting just in front of you
What we do every day is to make decisions. You either have enough information to make the decision, in which case you should make the decision immediately. Or you don't have enough information to make the decision, in which case no amount of your thinking will generate that missing information.
So, stop being thoughtful. The answer should be "Yes" or "No." Clearcut. Immediate.
If you can't answer it, get a hint, poll the audience, or ask a friend. Just don't waste your time thinking.
Stupid Dialog Box
(This blog entry is contributed by WeiqiGao.com correspondent Dale Wilson. —Ed.)
Blogger won't let me post images without jumping through hoops, but I thought you might appreciate this one for your "stupid dialog boxes" series:
The following message appears when you try to log off while running the Adobe Reader 7.0 plug-in.
Java 7 To Gain Native XML Data Support
Propogating a bit of Sun press hit:
InfoWorld: A key feature being considered for Dolphin is native XML data support.
I reported on a similar feature called E4X in the Rhino implementation of JavaScript 226 days ago.
While adding native XML support, it would also be nice to add native regular expression support (so that I don't have to escape all those backslashes when I write a regular expression in Java code.)
Does It Work?
This conversation sparked itself spontaneously today:
Jonathan: If you see a piece of ugly code, what do you do?
Me: Does it work?
Jonathan: Yes.
Me: Then let it work.
Jonathan: Then why do we refactor?
Me: Does it work?
Kevin: The meaning of work here is more than correctly executing an algorithm. If a piece of new functionality cannot be easily added, then the code does not "work" in a broader sense.
He Invented Ant, But He's Writing Makefiles Now!
James Duncan Davidson: And writing a Makefile the other day was a hoot. Yes, me writing a Makefile! Turns out that they are good for some things!
Java Regular Expressions At St. Louis JUG
This month, the St. Louis JUG went back to basics. In yesterday's JUG meeting Dean Wette talked about Java Regular Expressions, a feature that was introduced in J2SE 1.4.
Dean is a veteran speaker at the JUG, having presented there five times over the last eight years.
"You should really learn and use the Java regular expression API. It is so powerful it will save you a lot of time from iterating through a String character by character," said Dean.
The full presentation can be found at the St. Louis JUG Knowledge Base.
There Is No Such Thing As A "Java Architect"...
...Unless you are talking about the architect who designed the Java platform, like James Gosling, or the other six guys who designed the thing with him way back when.
An architect is an architect whatever the implementation platform. Anyone who claims to be an "Java Architect" is no architect at all.
An architect can specialize in Java based systems, just as an architect can specialize in Windows based systems or Unix based systems. But an architect who knows only Java run the risk of proposing inferior systems.
That's why the pragmatic programmers suggested to learn a new language every year.
But what language do you learn? And to what extent? I'm tired of people saying "Ruby is so OO," and following up with "Everything is an object, even blocks." I'm sorry, when "everything is" something, nothing is. And blocks are not objects no matter what the syntax.
Likewise for all the talks about closures, lambdas, and continuations. These are cool concepts but no OO. Just learn Lisp and be done with it already.
Another reason we learn new things is out of fear: the fear of obsolescence. New things come out every year. They all claim to be the ultimate solution to every problem. But you can't possibly learn all of them or you don't have time to work and live.
The trick is learn the essentials of the art and science of the programming trade, and distinguish the new new thing from the new old thing. The technical press is no help at all for their constant hypes of one thing after another. Big commercial vendors are even worse.
I did not witness this but Dale said yesterday that Cobol was to be the ultimate solution back when it was introduced. The press hyped it just like they are hyping SOA today and (the next big thing) tomorrow. The same thing happened for SQL—the SQL that we all want to wrap, hide, map, and otherwise remove from view today.
I salute the person who took one look at the SOAP spec, said "This will never work," and moved on to other things.
By and large, the problems we want to solve in our daily works are solvable and have been solved many times. Recognizing what the problem is and provide a road map to an efficient solution, both in terms of man-months and in terms of CPU-seconds, is the job of the architect.
If that road map says "Cobol!" so be it.
Truly revolutionary things have the habit of quietly sneak up on you. They are usually done by a teenager or a college kid. They never present themselves initially with a bang.
How do you find them out? I don't know.
Now back to work. Boring, tedious work where error handling cannot be omitted to "limit the length of this article" or "left as an exercise for the reader!"
Sun Endorse(?)s Apache Harmony, Will Participate
Graham Hamilton: Sun is a big supporter of Apache (this includes making donations of hardware and storage) and we're always very glad to see them participate in Java development. In many ways launching a J2SE project is the obvious next step in Apache's work around Java. Personally, I am very curious about how the Harmony project will work out - creating a full scale implementation of J2SE is a mammoth task, as the Sun J2SE team knows only too well. However I wish Apache success and we'll certainly be tracking this as it develops. We'll probably participate in the project at some level, although most of our efforts will continue to be focused on building Sun's reference implementation of J2SE.
Simon Phipps: I'd like to add my welcome to the Harmony project, a proposal (which I assume will be approved) over the Apache Incubator to grow a new, independent, up-to-date and 100% compatible implementation of v5 the Java platform. Things like this (and the new openness of the v6 - Mustang - work) renew my confidence in the promise of the Java community - read the FAQ to see more. This is just the sort of responsible, community-led evolution that the JCP rules were changed to facilitate.
Re: Who Are These People (was: Re: Open Source JVM Proposal On The Table At Apache Software Foundation)
Project Harmony =================== Motivation ---------- There is a clear need for an open-source version of Java 2, Standard Edition (J2SE) runtime platform, ...
Instead of offering my speculations as to the motivations and the genesis of this effort, let me draw your attention to the people whose names are mentioned in the proposal. I have added hyperlinks to the names based on the I'm Feeling Lucky Google search on the name:
These individuals have expressed an interest in participating in the architecture and design work. The information in parenthesis indicates other community participation or relevant experiences of that individual : Guy Churchward (individual w/ commercial VM experience) Joakim Dahlstedt (individual w/ commercial VM experience) Jeroen Frijters (IKVM) Geir Magnusson Jr. (Apache) Ricardo Morin (individual w/ commercial VM experience) Georges Saab (individual w/ commercial VM experience) Bruno Souza (SOUJava) Davanum Srinivas (Apache) Dalibor Topic (Kaffe) Tom Tromey (GCJ) Weldon Washburn (individual w/ commercial VM experience) Mark Wielaard (Classpath) and the following individuals have expressed interest in participating as committers for the Apache-licensed implementation : Jeroen Frijters (IKVM) Ben Laurie (Apache) Geir Magnusson Jr. (Apache) Ricardo Morin (individual w/ commercial VM experience) Bruno Souza (SOUJava) Davanum Srinivas (Apache) Dalibor Topic (Kaffe) Tom Tromey (GCJ) Weldon Washburn (individual w/ commercial VM experience) These individuals will participate as Incubator Mentors : Noel Bergman Ben Laurie Geir Magnusson Jr. Stefano Mazzocchi Sam Ruby Leo Simons Davanum Srinivas The following Apache Members will be the sponsoring members : Noel Bergman Jason Hunter Ben Laurie Ted Leung Geir Magnusson Jr. Stefano Mazzocchi Sam Ruby Leo Simons Davanum Srinivas The following community members support this effort : Danese Cooper Brian Goetz Doug Lea
Keyboard Shortcuts In Gmail: Time Saver
I've been using Gmail for 185 days now. And I stumbled into what I think is the biggest Gmail time saver yesterday—keyboard shortcuts.
It was disabled by default and you have to go to your settings page to enable it. But once enabled, you can navigate your mails, in two different views, with the keyboard.
The j key takes you to the next thread. The k key takes you to the previous thread. The Enter key takes you from the summary view to the detail view. The u key takes you back.
It's almost as good as the old rn news reader, by no other than Larry Wall.
(Just to show you how "web applications" takes the state of the art GUI development back for twenty years. (Sorry I couldn't resist the urge to take a cheap shot at "web applications." (And I think I understand what Bill Gates meant when he said "Have you ever heard of Windows?")))
JARBUCKS.org: Just Like Del.icio.us, But For Java!
Steve Mallett: You can track the collective consciousness of a person, group of people, and the same for topics, like apache, java, news, article, sun, mustang, codehaus, theserverside, java.net, and any combination thereof via the site or rss. You could put your personal links in your roller blog via the rss feeds. So without further ado: JARBUCKS.org
If you know about del.icio.us, JARBUCK.org is a very simmlar idea. You don't have to do a lot, but you get a lot. And it's fun too!
NetBeans vs. Eclipse---Why Not Both?
The Eclipse vs. NetBeans flame war is heating up again, mostly because Sun has began a switcher blitz that included a fair amount of Eclipse bashing.
This can be looked upon from several different angles.
On the stages of winning scale:
First they ignore you,
then they laugh at you,
then they fight you, <-- you are here, Eclipse
then you win.
I'm a very happy IntelliJ IDEA user. But, there are things that IDEA doesn't do, like supporting C++ projects. I recently installed Eclipse (and started using it productively) at work just to take advantage of the CDT and the AnyEdit plugin. Thanks go to Dan Troesser for doing the CDT talk at the OCI internal C++ lunch, where we have Buffalo Wild Wings instead of pizza.
Eric Burke took another look at NetBeans:
I do plan to spend some more time with NetBeans, primarily to use the profiler. I may try to load it at work and run the profiler on a really huge project. That would be wonderful, but I'll probably continue my day-to-day work in IDEA.
You see, with IDEs, especially open source ones, it doesn't have to be either-or. You can have both installed and choose to use whichever one that will do the job at hand best. (I use both vi and Emacs. I use Emacs to edit my ChangeLog in its changelog-mode and vi the edit my README where I use the !!date command liberally.)
Obviously both the Eclipse and the NetBeans camp want to have more users. My general feeling is that there are way more Eclipse users than NetBeans users. The reason for this may be historical, but the implications are not. It's good that NetBeans 4.1 will be a lot better earlier versions, if you believe the NetBeans developers, and I do, but the fact remains that NetBeans 3, up to 3.6, sucked. NetBeans people need to realize that it is not enough to simply say "Hey, 4.1 is a lot better than 3.6. Come back!" Why should I believe you?
(By the way, I had the same experience with Ruby. The first Ruby book (the PickAxe) was so bad it left a bad taste in my mouth. And I'm not going back to it just because the authors say the second edition is much better.)
They need to become credible, as in delivering updates that address user issues version after version in short time intervals, even with a minority market share. They also need to stop bashing Eclipse because doing so gets them nowhere with current Eclipse users.
One thing that the NetBeans people have been pounding at against the Eclipse people is SWT. "Swing is right and SWT is wrong," they say. To which I say they are right, most of the time, most of the time when Java was the language of choice for the product anyway. In this fight, NetBeans happens to be on the majority side. By that I mean, more Java GUI programmers are Swing programmers than SWT programmers. It will probably remain so for the next few years.
At the end of the day, it is not the GUI toolkit choice that decides whether an application is successful. It's the application itself. One could argue that the most successful GUI applications are written in neither Swing (LimeWire?) nor SWT (Azureus?), not even in Java.
So, Java people, let's write a killer GUI application that everyone loves to use and the developers love to maintain. I don't care what toolkit it is written in.
The value of SWT, as I see it, is its usefulness in situations where Swing is not available, such as in GCJ+Classpath. Not all Java programmers are going to buy into this platform though. Another role that SWT is playing is to drive Swing development in a direction that increases platform integration. This is similar in nature to the role C# played in bringing autoboxing and the for each loop into Java.
So what does all these leave us? Well, we are entering the world of twos. Just like the "vi vs. Emacs," and "GNOME vs. KDE" wars, we now have "Swing vs. SWT" and "Eclipse vs. NetBeans" wars.
And I say, "let them compete." If IBM wants to pour millions of dollars into SWT, go ahead. If Sun wants to pour millions of dollars into Swing, great!
We'll end up with something better whichever camp we are in.