 |
Ajax
Posted by davidrupp on May 23, 2005 at 07:23 AM | Comments (12)
Great. Just great. This is all I needed -- a technology that makes Javascript respectable.
When I was making the jump from mainframe assembler language to the wonderful world of Java (circa 1996), I, like every other Sun-worshiper, learned to sneer at the very mention of that monumental hack, Javascript. After all, it wasn't OOP, it was more like "oops!".
Now, almost 10 years later, I have to accept that I'm now playing catch-up to the rest of the right-thinking Internet world. You want to play Ajax, you have to play Javascript -- it's in the acronym.
So let's take a look at what I've been missing. Javascript, it says here, executes in a "Javascript-engine" that's baked in to my browser. Hmm. It's responsible for managing the presentation of the client side UI, event-handling, etc. 'kay. Ajax adds to that the concept of making a behind-the-scenes connection to the server to handle anything that can't be handled on the client side. Interesting. Now I hear there's a new concept in Javascript of a kind of "canvas" -- a generic component that will allow Javascript to draw....graphics! Whaddaya know.
Um, hello? Anyone ever heard of a little technology in Java called applets?! As far as I can tell, we've had the moral equivalent of Ajax available to us since the last century, and yet applets are now regarded with the same esteem as a sleepover at Neverland Ranch.
Where did we go wrong? The one key difference I can think of is that applets had the unfortunate requirement of needing to be loaded all at once. It's the "asynchronous"-ness of Ajax that's permitted it to evolve into the high-flying eagle of the Internet, while applets have sunk into the AWTar pit with the other dinosaurs.
Grumble. To quote the immortal Garth Algar: "We fear change."
To be continued...
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Well, one big difference between ajax and applets is that javascript can modify the html page model. Just look at google's new personalized home page, where you can drag and drop to change the layout of the page. The only way to get the equivalent behavior with java is to make the entire page one big applet. At that point, you might as well be using JWS. To basically rewrite the browser.
Posted by: richunger on May 23, 2005 at 08:54 AM
-
Would you care to elaborate how/who javascript is a "monumental hack"?
How much do you know about javascript?
Posted by: dumky on May 23, 2005 at 09:08 AM
-
The one key difference I can think of is that applets had the unfortunate requirement of needing to be loaded all at once.
Which is an unfortunate biggie.
As is the necessity of a JRE for the applet to run, whereas Javascript, being "baked in", is ready to go from the moment the browser is installed.
Very little messing about with security prompts, too. No need to sign your Javascript, no sir.
Seems applets have a bit more going against them than Javascript has, even before we get into the limitations of what can be done with either.
Posted by: aidan_walsh on May 23, 2005 at 09:34 AM
-
Ah, the limitations of the printed word for expressing sarcasm effectively. Dumky, to answer your question (and your implication) -- I currently know very little about Javascript and am attempting to rectify that deficiency. I do not consider Javascript a "monumental hack"; I don't consider it any kind of hack. That's where the sarcasm comes in. There was a time (back in 1996) when I did, but that was a reflection of my Java prejudice, not any actual knowledge. That phrase was meant to be taken in the context of my (in)experience at that time.My goal with this piece (as with most of my writing) was to express some "legitimate" thinking wrapped in my own (admittedly warped) brand of humor. I did not mean to offend, and I apologize if I have.
Posted by: davidrupp on May 23, 2005 at 10:34 AM
-
Besides load-all-at-once, to expand on Rich's comment the biggest problem with Applets is you can't control the size, layout, etc. of the "page" (ie, UI) like HTML can. UI scaling and layout have been issues since day one of UIs. We have variable screen resolutions and users who size their applications and/or browser windows differently or want larger/smaller fonts depending on our eyes and/or preferences. The nature of HTML has made it easier to do this than in applications/applets. Flash is partway to a richer UI than HTML but not close enough to layout/scaling nirvana. AJAX, DHTML, CSS and a good back-end make for a fairly rich experience while maintaining flexibility. I'd still like to make it richer, but that might take some re-thinking of the browser plugin model, dynamic scriptability of plugins from within a page, and maybe some standarization, de-facto or otherwise.
It would be cool if Groovy were an alternative to Javascript in pages. And if applets could be more dynamically part of the page layout (even aware of the environment, such as the page's and user's current font preferences, etc) and be scriptable by the page, that would make a huge difference. Part of the issue is deciding which pieces are in the sandbox and which aren't.
Posted by: gerryg on May 23, 2005 at 12:32 PM
-
Remember all the job listing that read:
Java (not javascript)
The other day, a VB programmer remarked, "I've done so much javascript lately, I'm sure that I probably know Java very well too." I cannot recreate the tone with which he said this, but it was truly bizarre. He really believed it. It is a strange world.
Anyway, as cool as javascript can be, I'd like to find better tools. After writing some event handlers with laszlo, I asked myself, "and where do I put my unit tests?". It seems so easy to set aside standards because after all, it's just javascript. But I'm sure someone has worked this out, I just haven't found the tools and methods yet.
What would a new Applet specification look like, given the new importance of flash and AJAX?
Posted by: d_bleyl on May 24, 2005 at 06:13 AM
-
Three things against applets:
What if the Java plugin's not installed? This was mentioned earlier. If Java were both smaller and open source, this would be easier (but not necessarily easy) to rectify. And either of those things seems very hard to achieve. And then there's the version issue.
For browsers (and ajax), people are in the habit of expecting to support things that came out a few years ago. Is that the same mentality for Java? And the more dynamic nature of js makes it easier to conform to whatever environment happens to be available. These issues can be addressed in Java, but the mentality and patterns are more in place for JavaScript.
And there's the load time (sort of mentioned earlier). Even if my applet is tiny, if I'm the first applet someone hits, the Java VM load time will grind the browser to a halt for what seems like forever. Do I want people to hate my web site that much?
Posted by: tjpalmer on May 24, 2005 at 09:15 AM
-
There are various reasons why applets never really took off, and Sun is partially to blame for that (and also Microsoft).
First there is the main problem of having to install a vm, which is the smallest problem.
Second the early applet security models were to hard to grasp.
Third, Applets still take a load time and half of the time the apple brings the browser to a griding halt (especially during vm startup). Yes I know about the jar cache, but the last time
I did some applet related stuff, the jar chaching did not work on half the browsers I tested, the other half did not follow the specs.
(The componend was a html editor which was started whenever there was no richedit control available in the browser)
To give an example: The richedit control in the browser took 150 lines of javascript code, started instantly, while the applet had starting times of 15 seconds and the jar cache was not activatable on half of the browsers.
There still is the sort unresolved problem of versioning the VMs within an applet.
I would have loved to go for applets, but all those problems prevented it 90% of the time and the 10% of the time it caused more problems than it was worth it.
In the early applet days there were banking solutions implemented on applet base, but those have moved to plain web interfaces, due to applet loading time, performance (back then that was a major problem) issues, vm versioning issues, and myriads of other applet related problems.
Face it, applets are an awesome technology, but Sun screwed it up majorly by never really fixing the main problems underneath it.
Posted by: werpu on May 24, 2005 at 12:09 PM
-
It seems that the best kept secret of applets is the API that allows the manipulation of the (Level 2) DOM that they are a part of. You should be able to do all that JavaScript type stuff in Java.
However that's all academic. I bet most Java programmers, like me, have the plug-in unplugged. I don't like the grinding when it starts. Mozilla is good enough on its own at eating hundreds of megs and then crashing out (if I'm lucky). Then again I'm unusual in refusing to read web pages with Flash animation going on in the periphery.
IMHO the only way applets could stage a comeback is as a hanger on to a wider wave of Java on the desktop. I'm afraid JDNC and supporting projects are too narrow, too shallow and have too many strings.
Posted by: tackline on May 24, 2005 at 05:50 PM
-
@d_bleyl ... get a real computer :-) - You can write unit tests for Safari to execute your client side javascript.
Has the advantage that (other than a little bit of Applescript to bootstrap) your tests are written in Javascript too, so you're good to go with the one language.
Posted by: rickcarson on May 24, 2005 at 05:54 PM
-
On the subject of Servlets storing state in the wrong place, I was amused to see the preview my comment on Blarg #14 get mixed up with the previous comment is this blog.
Posted by: tackline on May 24, 2005 at 05:55 PM
-
To be honest, I welcomed the demise of the Java applet. As a professional Java programmer from JDK 1.02 onwards, I've lost track of the number of people I've met who respond with something akin to "oh those tacky web animations?" when I tell them what I do. Applets did Java a big favour - they got it noticed, and in a big way. But they also did Java a big disservice, in so far as the Java name and brand is inexorably linked with naff waving lakes and bouncing text in the minds of the masses.
When Flash came along and stole Java's eye candy crown, I for one did not shed a single tear. We need to move forward, not back. I sense many users are beginning to tire of web browser apps, AJAX enhanced or not. As a means ot delivering a rich and fluid user interface experience, the web falls flat for all but the most trivial of applications. Its one great advantage is accessibility - a web app can be run anywhere without the need for formal installation - all that's needed is a URL. Sound familiar? (Do the words 'Start' and 'Web' spring to mind - although not necessarily in that order?)
WebStart, IMHO, is the panacea to the web browser app. It provides the immediacy of the web with the UI sophistication of a fully fledged desktop application. So why isn't anybody outside of the Java community talking about it?
Here's an idea: as Gmail is the most famous AJAX application, we should be pushing Google to develop an official WS Gmail client. Or even offering to develop one for them (assuming they are willing to open up some of their Gmail specific functionality to us). It will be worth the effort just to get WS's name on the map!
Posted by: javakiddy on May 25, 2005 at 06:28 AM
|
java.net RSS Feeds
