Slashdot Mirror
AJAX Buzzword Reinvigorates Javascript
samuel4242 writes "Javascript may have been with us since the beginning of the browser, but it's going through a renaissance as companies like Google create Javascript-enabled tools like Google Maps . There's even a nice, newly coined acronym , AJAX for "Asynchronous Javascript and XML". A nice survey article from Infoworld interviews Javascript creator, Brendan Eich, who says that this is what he and Marc Andreessen planned from the beginning. Perhaps AJAX will finally deliver what Java promised. Perhaps it will really provide a solid way to distribute software seamlessly."
cleaning tub
cleaning toilet
getting first post
Six months after a (not) new technique shows up, we get coverage.
By the way, am I the only one that uses the web with JavaScript turned off for almost every site?
urrrrrrrrr.....
Javascript may have been with us since the beginning of the browser...
Huh? I don't seem to remember seeing it until about '96 or '97. That's just a wee bit later than the beginning of the browser...
Isn't part of this due to Microsoft's non-complient browser API?
Go ahead and mod me as flamebait.
Top 10 Reasons To Procrastinate
10.
Since the ajax fans thought of a funny acronym to popularize their club, I'll introduce to you
Like the Greater ajax - java embodies the virtues of hard work and perseverance when my browser tries to load it.
Yeah, I meant that! No, really, I did! Honest! :D
Game dev and music blog
You're smoking crack. Client-Side scripting has always been in JavaScript or languages that look exactly like JavaScript.
Well yeah, that's what I'd say, too.
Ok, Frist P05t candidate away - time to RTFA now
Everything in moderation, including moderation itself
Fry: [talking fast] These languages are on the fast-track to the it list; blastfax kudos all around.
Leela: Uuh, hello! We haven't made one program since you two took over.
"That Guy": Programming has nothing to do with the Programming business. buzzwords, people, buzzwords!
Ruby on Rails has been working on this for some time, at least since the 0.11 release back in March. This is a wonderful technique for speeding up web applications. Browse around the web site, or hang out in IRC, and you will quickly see what all the excitement is all about.
Too bad it's so sloooooooooooowwwwwwwwwwwwwwwwww...........
Having to go back to the server again and again and again to get tiny amounts of data doesn't sound too nice to me.
What we need now (and Google has shown that it's feasable) is a Javascript based GUI.
Gnome and KDE can conquer all desktops once they are ported to this AJAX framework.
Where's the first javascript based window manager? Personalized Google is the first step in that direction.
DNA is the ultimate spaghetti code.
Perhaps it will really provide a solid way to distribute software seamlessly
:(
I'm just hoping this will encourage development tools to make it easier and more standardized in the way it is used. Slowly, but surely I'm building my own API to exploit "AJAX" (since before the term was invented). Unfortunately because of IP/NDA agreements I can't release any of the nice Visual Studio add-ons I've built
Unless standards are complied with fully there can never be "one programming language" for web scripting. Anyone who's had to debug Javascript in IE that works in Firefox knows this.
You have two hands and one brain, so always code twice as much as you think!
This has been possible for years. I've personally been using this type of scripting in web applications since 2001. Why the big fuss all of a sudden? Is it just because of the new XhtmlhttpRequest object (or whatever the hell its called)? You can do the same thing with an iFrame. Sure, its not as elegant, but it gets the job done. And it registers in your browser history.
For me, the crux of the usefulness and eventual adoption and finally complete embracing of AJAX lies in the article's paragraph:
I've seen what Google has done with AJAX (e.g., Google suggest), and it's stuff I never imagined could be so repsonsive in a web context. For me it starts to make programming fun again, and web programming an acceptable form of application development.
When browsers and web first emerged I could see the writing on the wall, but I wasn't happy about it. Browser application writing from the programming perspective was probably the single most giant leap backwards in technology for me (not including technologies introduced by Microsoft)....: you mean, all the years I've spent honing skills writing applications no longer apply? You mean I no longer have "state" as a tool for maintaining sanity in my application???? Hwaahhh??? I have to do what to change the web page???
While there have been some technologies (ASP, JSP, etc) to help with these issues, none have addressed the responsiveness issue with the web page round trip message loop. AJAX comes close. Now all I have to do is learn it.
For a great example of the responsive nature of this (I've referenced this before), go to Google Personal Home, set up your own home page, and play... Configure your modules by dragging them around... open and close your g-mail previews. This all starts looking alot like programs actually running locally on your own machine. (I'm assuming all are familiar with and have played similarly with Google Maps.)
Additionally, here are some very good resources to learn more about AJAX:
That's it, I'm done.
Uh, sorry dude but I don't want 50 languages taking 100 MB in my browser. Just ask get your favorite script to compile *into* javascript, a bit like f2c is a Fortran to C translator.
Then where have you been for the last 10 years? Seriously, those comments reek of those guys coming out of the shadows to hop onto the glory boat.
Finally, the reason I was looking for to disable Javascript is here.
Don't forget it is Darth Jobs who is carrying out Order 66.
Intel chips?...all part of the Master's plan.
If we had only known... We could have avoided ActiveX! :-)
If by seamless, you mean heavily hacked to get around platform/browser compliance/implementation... then yes, I agree.
Quite honestly javascript is a very poor language. The reason it is used so much is that it is basically the only alternative to client side scripting without Java. I would be excited by a more robust replacement for javascript, but this just seems like taking a bad idea and running with it.
Philosophy.
The Ajax concept is based around something called the XMLHttpRequest component. All you Microsoft haters get ready to yell because this was a Microsoft creation! Yes, Microsoft got something right, and did so before anyone else! Microsoft first implemented the XMLHttpRequest object in Internet Explorer 5 for Windows as an ActiveX object (ok, so they didn't get it QUITE right!).
Source
Have you ever been to a turkish prison?
Javascript and Java have nothing in common but four letters in their name, from a silly marketing decision by Netscape and Sun long ago.
Unfortunately, the alternative name that could have cleared up the confusion is impossible to pronounce: ECMAScript.
(Reality reasserts itself sooner or later.)
I can't get images from google maps to show up in mozilla. Either on windows or linux. Anyone know why?
It would be better if there weren't all these languages for web site developing. What we need is browsers to run EXE files natively without a sandbox, so designers have a bit more flexibility.
People keep talking like Java has failed and is now dead and gone.
:)
I have been programming primarily in Java since 97, and if you ask me, it's just *starting* to pick up steam.
The language itself is just becoming mature - with big strides (generics, etc) in Java 1.5. And only now are we seeing alternate implementations to Suns, with GNU Classpath approaching a million lines of code, and GCJ compiled applications shipping in Fedora Core 4. Java applications such as Eclipse are also just starting to become popular, and Java API's for things like GNOME are just appearing on the horizon.
So quit calling Java dead
All "AJAX" is going to do is sell a bunch more four-color glossies to those IT types with more stars in their eyes than substance in their heads. It's just another vaguely-defined acronym with a catchy ring to it.
For anybody who actually writes code, things like Google Maps are simply a happy marriage of time-honored techniques and modern browser tricks. They're cool, they're novel, they're useful, they're quite well-written, and they're letting us do things in the browser that used to require plugins--but there's nothing terribly eye-popping about the techniques themselves.
Obliteracy: Words with explosions
http://zeldman.com/goodies/dirt.m4a.zip
Zipped AAC file from Zeldman (requires iTunes)
I've never build web pages with any Macromedia project, and yet through the magic of style sheet and JavaScript, I've had all of these capabilities in my pages for years upon years. Am I misunderstanding the point? I assume I must be.
(insert flawed analogy here that will be mercilessly seized and picked to pieces by responding commenters)
"I have never won a debate with an ignorant person." -Ali ibn Abi Talib
It's called XUL.
Curl is another alternative for doing things client-side.
There is a need to standardize (as much as possible) the way that AJAX will work in the browser. There are a lot of code-writers and code-copy-n-pasters out there. When you visit one of these sites, you know because the browser may act funny due to poor programming/hacking of Javascript interacting with the server. AJAX is much bigger than just XML messaging, it's an opportunity to bring a more traditional application model to the browser via Event handling and dispatching. Notice that if you have an engine or framework that is well built, it's quite simple to add event handlers like key presses or mouse clicks or even drag-n-drop. If one was to script each element on a page, that gets heavy and can slow the browser. Which - btw, is why AJAX hadn't caught on until recently: computing resources were not sufficient in many cases.
.net. This combination of technologies has been around for a while, however, as people find them more useful and interesting, there is a need for good information and a solid foundation for folks to work off of.
That being said, everyone should look at http://www.sourcelabs.com/ajb/AJAX Mistakes. There's also a nice list being compiled at http://www.openajax.net/OpenAJAX
As a dialup user, I can say that AJAX is a massive improvement over a standard Javascript page. GMail's web uses AJAX, and, though it takes quite a while to load the page initially, not having to go through the server for something as simple as clicking on a thread is highly preferable to reloading the page each and every time a link is clicked. Hopefully, we'll see more Javascript applications that run on the client side as opposed to old-fashioned form-based applications.
Ride the skies
Running script direct from arbritrary servers is not acceptable from a security standpoint. Inline scripts (aside from event handlers) need to be depreciated and the end user permited to audit signed scripts on a site by site basis before running them.
* Bluechip client
.NET Experience on Linux
* Excellent Package
* London, Engliand Offices
Requirements -
* 5 years of writing AJAX apps for enterprise clients
* 5-10 years
* At least 15 years Linux experience
Call now or apply online by clicking here!
"It's not your information. It's information about you" - John Ford, Vice President, Equifax
Microsoft also has had DHTML+Time for years, which let you script actions based on timeouts, greatly facilitating animation and periodic update.
Of course, most people developing web applications have a little experience in the main technologies in AJAX, particularly DHTML and DOM, which are the critical ones. Only now we have a buzzword that HR an latch onto.
On the other hand, if they're looking at people who can architect something like Google maps, well, they're going to have to wait until the frameworks catch up. I've got my eye on Echo.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
2 syllables including X, I expect this is why the HURD is still unfinished and VRML petered out, X3D is clearly a foolish attempt to sound like mp3 and has too few vowels to take off.
Flash will fall by the wayside defeated by this superior floor cleaner, er web technology.
i have noticed in my own js/DOM hacking that somewhat simple operations are costly. simple resource allocation tools indicate firefox really starts hogging memory and cpu when i engage what i would consider straightforward DOM manipulation. has anyone else noticed this?
Perhaps AJAX will finally deliver what Java promised. Perhaps it will really provide a solid way to distribute software seamlessly... (emphasis mine)
The "promise" of Java (write once, run anywhere) is exactly the same as Ajax. A big implmentation difference is in the runtime. Ajax's runtime is native to the browser; Java's runtime is not.
If what you need to do can be done with Ajax, then Ajax delivers on the promise, today. Java? Sure, it delivers big-time, if you can live with Web Start and deploying the runtime to every desktop.
Ajax should be welcomed by Java advocates everywhere. The marketplace are finally "getting it" regarding write once, run anywhere. The limitations of Ajax are substantial, so it won't be long before people need more muscle.
"We receive as friendly that which agrees with, we resist with dislike that which opposes us" - Faraday
Try www.konfabulator.com. It's free to use (nagware, actually) and versions are available for Windows and Mac.
With Konfabulator, you can build cross-platform (no Linux yet) desktop widgets (similar to OSX Dashboard widgets, but more functional), using XML and Javascript. You can define the different components of your widget in XML, and then write the event handlers in Javascript. Optionally, you can have Javascript dynamcially create the components in the onLoad event handler. It uses the Spidermonkey Javascript engine, also found in Mozilla/Firefox.
If you give it a try, Check out my widget, ClipDrop (a clipboard manager), in the Gallery.
- Despite popular opinion, I am not perfect.
Great idea.
.EXE on my site that does some really cool things including encrypting your hard drive. But that's OK, you can pay me $200 and I'll send you the decryption key.
I've got an
Why doesn't Slashdot ever get slashdotted?
Ugh! "AJAX" is misleading (and rather dumb sounding too). I use the "XMLHttpRequest" object both in syncronous and asynsconous modes, and I DON'T USE XML..ever! Why parse all that garbage when I can send JSON (JavaScript Object Notion) or even plaintext back and forth? It's lightweight and does the job.
Google has people coding in something new, which they aren't saying much about. It's then compiled to Javascript and DHTML. They're not just writing Javascript by hand.
I don't recall remembering Javascript with my Lynx and the first Mosaic browsers. Funny that.
...never heard about AJAX before... ...seriouly, at this point, how is this newsworthy?
I would say that the popularity of Firefox and the fact that there is a good implementation of a javascript runtime which can serve as a reference from which to attack the shitty implementations(cough cough ... IE), that really made the difference. But hey we can blame it on a shitty acronym if you'ld prefer.
(For those who didn't bother RTFA)
Not having to refresh the frigging URL everytime you want to request some info from the server.
Think of it as "DHTML+minor server requests".
So, what car would you like to buy?
(select: Volkwagen)
(javascript then loads the currently available VW's from the server into a second combobox)
Ta-da!
Here's one.
I use Javascript for a lot of things, and I constantly hear things like "Wow! I didn't know you could do that kind of stuff with Javascript", which to me just goes to show how uninformed people are about the language.
/. doesn't just love their flash, of course. 8)
Additionally, anyone in the know is aware that a lot of the cool things you can do within OSX are attainable via Javascript(JS). Want to write a cool new Sherlock plugin? Use JS. Want to write a cool new widget for Tiger? Use JS.
As the trolls have already started pointing, Javascript is not Java. And who would want it that way? Not to feed the trolls, but to me JS is a great way to quickly get something done. Java on the other hand requires a lot more code to do the same types of things - Simple things that is. Java can scale better, and do things that Javascript cannot, but to me they're for two different types of applications. Plus, there's a helluva lot more overhead to Java to learn than there is for JS, and while those skills might come in handy, if I don't have to learn it, I'm not going to. Java's never been an overly "friendly" language to me. PHP on the other hand is, and it's an ideal backend for use with todays subject: Ajax!
But I digress... I was writing my own "Ajax" code until I came across this, which has allowed me to focus on my backend (typically PHP for me), and my front-end (The JS), and not have to worry about all the middleware that's making my dynamic app tick. I highly reccomend checking it out.
Also, it's worth noting that althogh Ajax is intended mainly for small bits of data to be sent back and forth, it does scale fairly well. I built an Ajax based random image slideshow, which has a PHP backend feeding the images to the browser one at a time, and it works great with multiple users!
Long story short, if you like the concept of Flash, but hate the overhead, and/or the spam/ad crap that Flash has given birth to, you should really check out the Ajax technologies... You can do a lot of the same types of things with Ajax as you can with Flash, but with the overhead of Flash, and without requiring that your users install Flash, and/or use a Flash-enabled browser. Not that everyone on
The #1 thing that will prevent the web from really replacing desktops as an application architecture has to do with the fundamental architecture of the web in terms of things being centralized away from the individual and internal organizations. What we really need is the concept of a "personal server" that serves as a starting point for all web applications running and personal information storage, where further interaction with other web sites can precipitate from this initial authenticated and private environment.
.NET My Services/Hailstorm, and it will definitely catch up with Google, Yahoo, Amazon, eBay and all others who want to do the same thing, but are just slowly creeping in the same process. Posession is 99% of the law, and having a stupid privacy policy that is all talk no substance is just stupid. There needs to be a base-line architecture that makes enabling and ensuring privacy feasible.
Otherwise, going to one big mainframe in the sky where one assumes Google's "do no evil" policy will be enough to enable everyone somehow to shift to the web as a primary application domain is never going to happen. The model of "trust us first" was the same thing that doomed
Let me ask you this, as great web applications are from the standpoint of availability, development ease, flexibility, adaptability, code reuse, ease of use, maintenance, etc., are major corporations going to abandon Exchange and Outlook and somehow start using Gmail? Clearly not. Does that have anything to do with whether the web paradigm is better or worse compared to the desktop paradigm? No, but the desktop will continue to be a anchor as long as the privacy issue isn't settled.
The semantic web or the web v 2.0 will run on a fully distributed and encrypted instant messaging-like network that blends a real-time messaging with a dynamic html display, where each person logs into their dhtml web interface running on distributed, personal dedicated servers.
By doing so you're kissing goodbye to 90% of security vulns in any broswer product.
Client-Side scripting has always been in JavaScript or languages that look exactly like JavaScript
Or Java.
And a few niche browsers had alternatives (e.g. http://grail.sourceforge.net/ allowed client-side Python scripts), but none of them ever got anything approaching critical mass.
rage, rage against the dying of the light
Ease of maintenance. Having an application centrally deployed means bug fixes and new features can be rolled out instantly, transparently, and uniformly. This can also ease development of other features, because developers can count on every user having access to the same version. In addition, rollbacks may be made if necessary in a central way. Architecture independence Thanks to open source software development, all major operating systems support webservers of one kind or another, and additionally there exist at least as an option very functional and uniform browsers. This means that servers and clients can be swapped as an organization's needs dictate, rather then becoming locked into any single architecture. Scaling/Economy benefits Additional clients added to the network have instant access to all available web apps, without the need to perform any installations or updates. Software can be deployed very widely and cheaply. *Control While the other factors have been positive, it is debatable whether this is a benefit or not; however, it is certain to be something developers consider. Having a functional, centralized software repository opens the possibility for time renting of access, and then shutting people off when the money stops flowing. Depending on implementation, and of course the user, this may be boon or bane: a very cheap way to temporarily access software you need, and never have to pay for it again, or a way developers extract endless money.
Personally, I always have wondered if Microsoft has purposely delayed adding features to IE for as long as possible in particular light of the second item, architecture independence. Microsoft Office is one of the cornerstones of their business, and enabling rich web languages would also allow a shift to be made away from requiring Windows. (This stance is also, incidentally, why so many of us who do professional web development are very frustrated with MS. I personally have to spend dozens of wasted hours for each big site coding up special versions for IE, in addition to standards compliant ones, and even then my possible feature set is much reduced. Cumulatively over the world, this must result in tens if not hundreds of thousands of wasted work-hours per year.)
Web apps have a lot of promise. Issues like GUI integration remain, but I am excited that the scene is at last gaining steam after stalling for the last 4 years or so.
I think maybe the slick apps like google maps is finally showing what good code CAN do, instead of the bloated bug ridden javascripting of yesterday.
Or maybe I'm just not transcending expectations by thinking outside of the box, and therefore my toolset isn't capable of brigding the information gap causing a chasm with my ability to think forwardly.
I'm struggling to identify which is worse: The day when we report that a buzzword has made progress, or the day a buzzword actually creates progress.
It certainly seems as if the world is moving the microsoft way (you will recall that MS put powerful scripting in IE as a response to Sun's propaganda campaign about Java applets).
Now, both companies seem to have abandoned the battle -- Sun found Java applets kind of embarrassing in the end (understandably), while MS declared the browser wars over and forgot about it (bizarrely). However, the conflict they started, between web browser as app host versus independant virtual machine + runtimes as app host, has continued to the present day.
It's interesting to speculate as to why the MS alternative, browser as host, has done better.
Well, it's not that interesting.
But I remember when the choice first became clear and people rushed to learn about Java applets... and 8 or 9 years on, the buzzwords are pretty much exactly the same, but the vendors (like Macromedia) never seemed to play Sun's game.
I think, in the end, I'd rather see a move back to 'proper' apps, Java or otherwise, and an end to seeing complicated interfaces implemented in text markup languages and browser scripting languages. Way too late for that, though.
Whence? Hence. Whither? Thither.
Ok, so the thinking goes like this:
* All major browsers support HTML.
* Most of those support XMLHttpRequest.
* Therefore, "write once, run anywhere" works.
It's not true. Browser implementations of javascript and DOM object manipulation methods vary wildly enough to make it easier to take your software to some other platform.
That's not to say that I am not terribly impressed by gmail, google maps, and.. well, other stuff, but no one seems to be doing it as good as google right now. It's not like they have a monopoly on the slick web app.
Set your content type to "text/javascript" and you can send data over the network and have it be perfectly legal and ready to use. NO XML PARSING!
JSON (JSON.org) just happens to be legal Python syntax... which makes me think...
hmmm.... Google has a huge server farm and is renowed for using Python... Google Maps talks client/server using Javascript, not xml... Python and Javascript shared JSON sytax for serializing objects... hmmm...
It is a very efficient combo: Python, Javascript, JSON, mod_python.
Being able to make HTTP requests from a client-side language without redrawing the UI is nice, although it is perhaps depressing that such an elementary capability has taken more than a decade to make it into standard browsers and that people are so starved for anything working that they celebrate something so elementary.
The problem is that the client-side language is still Javascript: a bad programming language and a bad target for compilers.
And on a serious note: Who was the moron who made the onreadystatechange event handler? Why couldn't you just pass in a reference to the XmlHttpRequest object so people wouldn't be forced to use global variables to store the reference? Is that so hard?
The thing that's different about an AJAX application is that the application has no file system hooks. About the only things it could read datawise are cookies, and if you're that afraid of webobjects, you've probably already got them disabled and you probably have a hard time with even the simplest websites (read: slashdot).
Note, this doesn't stop the annoyance factor. Those stupid flash ads will eventually become those stupid AJAX ads, as SVG matures into something usable, and people code more SVG-AJAX apps. But we've still got some time.
Besides, AJAX could do some good. I could think of it as possible to build a quick and dirty AJAX application to check if the packages on a system are out of date (yes, re-inventing the wheel is bad, but if you're changing the whole framework, sometimes you have to). Or any of the other millions of applications Dashboard widgets are already doing today.
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
Why does everything these days have to involve xml??
I am writing a website that searches bookings made, I have used this method to enable the results to be shown without reloading the page.
My first attempt was using XML as the data returned from the server, then parsing this using javascript's DOM. Slow does not even begin to describe it....Then add in all those Mozilla/IE differences (in parsing DOM), and you have a horrible mess.
I ended up sending out plain ol' csv to populate the tales, I know this is not applicable to every situation but 90% of them are better served with non-XML formats. Parsing the csv with 2 split() calls is very quick.
Please please can we forget XML for everything but inter-business communication.
I have told the PHB that it is XML because they want it sooooo much
Can someone enlightened tell me what the advantage is of using JavaScript over Java (with the assumption that Java would be installed on all machines)?
And don't flame me for using Java and JavaScript in the same sentence. I know that they are two different languages.
I'm guessing that the reasons are:
1) Java is actually not installed everywhere.
2) JavaScript is easier to get going with. You can use your existing web authoring environment and just add a few scripts that you copy paste from somewhere.
3) JavaScript is more light weight.
While, I understand these reasons, I think that they could have been overcome.
I feel as if VHS beat Beta.
The Internet is full. Go Away!!!
I read TFA, as well as O'Reilly's thick "JavaScript: The Definitive Guide", and I programmed a lot of JavaScript in the late 1990s.
But I am still not sure how to start with AJAX. Is there a good codebase, library or framework from which to begin work? Or do I have to go back and read all those line-by-line analyses of Google Suggest JavaScript that made their way around the Web?
In other words: Is there any way to get started with AJAX besides with a blank text doc and a browser?
AJAX is great and all, but it is going to turn in to the next Flash, being misused and abused by anyone and everyone. Alex Bosworth wrote an article a few days ago regarding the dangers of AJAX. The article can be found here. I agree with several of his points including problems with linking and the back button.
Google did a great job using this technology, I have seen many others fail. Just cause it's there to use, doesn't mean it should be used.
Just today I was looking at this page It's a list of ten easy to do mistakes in Ajax apps. Some of them are not that easy to avoid...
I'll do the stupid thing first and then you shy people follow...
You should stop smoking mate.
HTML/XHTML are still the base languages of the web, Javascript should only be used to improve the user experience, and when it's well used the website is not supposed to break when javascript is not activated (*) (then again 90% of the websites out there use shitty javascript in a shitty way).
Oh, and Javascript has always been the only scripting language that had a bit of cross-browsers compatibility (VBScript doesn't even come close), and the used server-side languages won't change.
(*) This is the base law behind the Graceful Degradation principle, which is even extended in the theory of progressive enhancement design: nothing should be necessary but the base data [HTML/XHTML] of your website, you should be able to desactivate anything that is added on top (style, scripting, whatever) without any *major* drawback (aka loss of some ease/speed is okay, but inability to use the website is not)
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
That being said, this does look like the least annoying of a lot of really annoying hacks to attempt to shoehorn stateful programming into an inherently stateless paradigm. Personally I think we should be rethinking the underlying infrastructure before we build too much on top of it.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Say that agine with a straight face.
Yes mod the parent up. The confusion between Javascript and Java is never ending.
There is one thing for sure though... nothing will finally deliver what Java promised. It's dead Jim.
JavaSCRIPT on the other hand...
...unfortunately no one can be told what The Mat^H^H^HGoatse is...they must experience it for themselves...
Like in
Whence? Hence. Whither? Thither.
I guess AJAX reinvigorates Javascript. It's a perfectly cromulent term. It sure did embiggen Google Maps
Schnapple
Messing around with XMLHTTP has already been possible for several years.
I don't see why this should be newsworthy. Is it that since Google uses it, XML with JavaScript is bright and shiny again? Or is it just that it finally has a name which can be pronounced by laymen?
One issue with Java or Flash applets that seems to also occur with AJAX applications is browser location getting out of sync with what the user sees as they manipulate the application.
That doesn't matter in the context of a single usage session, but if the user attempts to save their place with a bookmark or share what they've found by linking, they may fail. Their bookmark or link may reflect the URL of their entry point rather than the information they were looking at when they tried to "save" their place.
Google Maps has a special "Link to this page" link which resets the browser's location to reflect your manipulation of the map. If you bookmark/link without this step, your bookmark/link won't reflect your most recent scolling and zooming on the map.
The Back button can also be problematic for the same reason, if people start using it as a kind of Undo.
AJAX is extremely cool, but like anything else you need to know its pitsfalls and limitations.
org.slashdot.post.SignatureNotFoundException: ewg
Not too offend the open source community, but how exactly do you secure your codebase if your web-applications functionality is downloaded to the client (browser)? One of the features of server side applications that are so common on the web is the fact that only your presentation layer is presented to the end-user and your applications business processes is handled on the server.
Is it the same paradigm as applets in that your applet can still communicate with the server from whence it came to allow the server to handle business logic processing?
Speaking of applets, I still prefer their structured code format. I never liked working with javascript because there were so many different ways to do the exact same thing in javascript and it made getting all the developers on the same page, so that you are writing consistently formatted code, a bit more difficult... which leads to hard to maintain code... which, of course, leads to the dark side.
I looked at the generated Javascript for Google Maps and was completely daunted. Time to dust off the text books.
Ajax is a very simple technique. Here is a trivial example, with an HTML Client, an Ajax class library, and a PHP-based server. Click the button, and the server tells the Ajax engine to redraw a portion of the page.
g v="+escape(argv));
p lication/x-www-form-urlencoded');
) ;
... */
1 >You called method \"'
.$method.'\" on the Server</h1>";';
The trivial Ajax HTML Client:
<html>
<head>
<script src="AjaxClass.js" type="text/javascript"></script>
<script type="text/javascript">
function ajax(method,argv) {
var session = new AjaxClass();
session.getURL("server.php","method="+method+"&ar
};
</script>
</head>
<body>
<div id="componentA">
<h1>This is Component A</h1>
</div>
<p>
<input type="Button" value="Click Here" onclick="ajax('this_method','id=componentA');">
to replace Component A with text from the Server.
</p>
</body>
</html>
The Trivial Ajax Class (AjaxClass.js):
This class provides a wrapper for the XMLHttpRequest object, and handles some browser-specific implementation issues. It is a simplified version of the excellent DataRequestor Class, copyright 2005, Mike West, http://www.mikewest.org, Licensed under the CC-GNU LGPL, http://creativecommons.org/licenses/LGPL/2.1/.
function AjaxClass() {
var self = this;
this.getXMLHTTP = function() {
var xmlHTTP = null;
if(typeof ActiveXObject!="undefined") {
xmlHTTP = new ActiveXObject("Microsoft.XMLHTTP")
} else if(typeof XMLHttpRequest!="undefined") {
xmlHTTP = new XMLHttpRequest()
}
self._XML_REQ = xmlHTTP;
return self._XML_REQ;
}
this.getURL = function(url,qs) {
self._XML_REQ.onreadystatechange = self.callback;
self._XML_REQ.open("POST","server.php", true);
self._XML_REQ.setRequestHeader('Content-Type','ap
self._XML_REQ.send(qs)
return true;
}
this.callback = function() {
if (self._XML_REQ.readyState == 4 && self._XML_REQ.status == 200) {
try {
eval(self._XML_REQ.responseText)
} catch (e) {
alert("Error in returned JavaScript:\n\n" + self._XML_REQ.responseText);
}
} else if (self._XML_REQ.readyState == 4) {
throw new Error("Data Request failed with an HTTP status of " +
self._XML_REQ.status);
}
}
if (!this.getXMLHTTP()) {
throw new Error("Could not load XMLHttpRequest object");
}
}
The Trivial Ajax Server (server.php):
<?PHP
$method = $_REQUEST['method'];
parse_str($_REQUEST['argv']
/*
Some processing would take place here
$response = 'document.getElementById("'.$id.'").innerHTML="<h
header('Content-Type: text/javascript');
header("Content-Length: " . strlen($response));
echo $response;
?>
"We receive as friendly that which agrees with, we resist with dislike that which opposes us" - Faraday
again. javascript should be confined to alter style NOT content. else you exclude old browsers, phones and text only browsers.
just when i was feeling i could get to most sites in links safely - only one person arrested this year for donating to a charity in a text-only browser.
Ajax is a trademark held by Colgate-Palmolive. Any use of it will probably provoke the giant.
It's ok that there's a new buzzword for everyone to use, but it's taken. Pick another! Perhaps Jesse Garrett should have used TESS the trademark search engine.
Mozilla/Firefox browser uses a XML interface that is better than HTML called XUL. All the extensions for Firefox use XUL and Javascript. But signed XUL&Javascript Apps can be server over the web also. Why not use a better interface language than HTML? Yes it is not compatible with IE, but for better specialized applications it would be work.
I've played around with AJAX, and gotten it to do things I never though were possible, but I can't help but feel that it seems like a hack. I haven't been willing to put it into a production environment because I know that some customer will be using a browser that doesn't support it, or have javascript disabled. We keep adding layer upon layer onto HTTP to get it to do things that it was never meant to do.
With as much clout as google has, I wish they would come up with some new thin-client technology built from the ground up to do the sort of stuff they're using AJAX for--something that's not proprietary (Macromedia anyone?), but instead an agreed upon standard that isn't a bitch to use or implement (like SVG).
...and be all of client side scripting. There is another...
BLEACH (Bloatware + Leanware + Emacs + (x86) Assembly + C + Heroine) has been working wonders for my development. I usually start the day by shooting up in my office, then I start up all of the Office apps (bloatware) on my co-worker's PC to slwo him down. After that, I load up ACIDWARP.EXE (leanware. No DLLs, libs, nothing, jst one EXE and it's small for what it does) on my boss' PC which stuns him for a few hours so he can't keep track of what's going on in the office (usually play Purple Haze in the background). I then open up Emacs on my box and set to work redesigning everything (Screw WYSIWYG. It's overrated.) I also write a lot of my CGI in assembly language to keep the resource usage low and the code tight. C, when it's needed, which is almost never because of how well I can do things in assembly. And finally, another serving of heroine to keep the Jedi Mind tricks fresh. So far, this plan has worked so well, that I've been shuffled through about 70 different companies this year alone. My talents are in demand!
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
Can you explain what you think Ruby on Rails does that is so great, and I don't see it. I looked at the web page, I looked at a tutorial, and it looks fairly cumbersome to me (starting with the fact that any RoR project seems to involve a minimum of 12 subdirectories).
One aspect to RoR seems to be support for MVC and Ajax, but it doesn't seem to be implemented in a way that I would consider straightforward or that I would want to use.
The Adaptive Path web consultancy is making good progress in spreading the "AJAX" meme. Please do not give them indirect credit for "creating" something that has been around for a while just because they came up with a freakin' buzzword. What is this, the 90's? This just reeks of a marketing strategy...so typical of consultants.
(This is a repeat post...I hate it when this term gets greenlighted by Slashdot admins. It's almost as if they're paid to promote Adaptive Paths concepts.)
There is no gravity...the earth just sucks.
or most any other google goodies just don't play
in konqueror.
You either get an "unsupported browser" message or it just locks up tight if you try to change the browser ID..
I hope KDE gets this fixed. I hate to have to keep going back and forth between Konq and firefox.
There are many things I don't like about each of the two browsers. If they could both work it out and take the best of both browser and combine them into one, they could slaughter all the other browsers..
But for now, forget google goodies and konqueror...
It's quite possible to build powerful crossplatform applications for the web now - in Flash, Java or AJAX.
One way is AJAX. To make it work well, you essentially have to write a version of the page for each major browser - which is a lot of work. Of course, there are development tools that make this substantially easier. It is by far the most seamlessly integrated with the BROWSING experience, but is less suited than Flash or Java for real applications - like a game or any other datadriven mouse-interactive thing. I don't believe there is no OOP Javascript in a browser.
Another way is Java applets. Java has the advantage that lots of programmers learn it to do nonapplet Java work. The big disadvantage is that a big part of the installed userbase has broken M$ Java engines, and it's generally impossible to install a Java engine without computer-admin privs (as opposed to "browser admin" privs)
The final way is Flash MX 2004 or Flex. Like Java applets, it is a fully featured OOP programming language (Actionscript) It expects to deal with server information, and can innately request data from mostly-arbitrary SOAP Web Services. It also works innately on OSX, Windows and i386 Linux in most all browsers and on a variety of small devices. It doesn't work on more obscure platforms, however, and it's not OSS so it can't be ported by just anybody.
Summary: If you want to a supercharged browser experience, use AJAX. If you want an application that "just happens" to be projected over the web, use Flash.
Looking for freelance Actionscript (Flash/Flex) or ColdFusion work and/or freelance developers. Email me, put Slashdot
this a pretty neat article about some things to keep in mind when designing a UI with AJAX
It seems that user interaction activities like "saving", can run counter to the way people have been trained to use web sites. People don't believe an action took hold if it happened to quickly. The author of the article linked above actually had to slow down and give lots of visual response to indicate the user's data actually saved (or the user would repeatedly click "save" thinking nothing had happened).
It's not a bad thing, it's just an example of some of the new user design challenges AJAX presents at the same time it gives us a new approach to getting near synchronous web-UI response.
And just for giggles get your AJAX pixel fight on
e.
Build Your Own PVR/HTPC news, reviews, &
Even with AJAX, web-based applications are still giant kludges. HTML forms is a kludge put together quickly to make web pages interactive. It's still missing basic elements like combo boxes and modal dialogs. Javascript is the same thing, a kludge that some people try too hard to make into a real programming language while keeping it backwards compatible.
If you want to make real applications using browsers, you need to come up with native support for many more GUI elements, and you need to come up with a scripting language that is robust and geared towards programmers, i.e. totally unlike javascript. Create these two parts with no concern for backward compatibility, stop asking web "designers" to implement interactive applications, and you will have the start of real web-based applications.
More functional? Dashboard widgets have the complete OS X toolkit available - you can hook into anything. Konfabulator is javascript only. Try again.
"You can do a lot of the same types of things with Ajax as you can with Flash, but with the overhead of Flash, and without requiring that your users install Flash, and/or use a Flash-enabled browser. "
Except agree on standards. That's one of the reasons Flash took off. Anyway JS with all the other W3C standards is were the action is going to be. JS+XHTML,JS+SVG,JS+XFORMS,etc.
Very cool demonstration of what AJAX can do for interactive web applications: Anyterm - an ssh-like web-based terminal that doesn't rely on a java applet. Needs apache2 to run, though. Also, have a look at "livepage," which is part of the asynchronous python web development framework called nevow.
First of all, Java on the client-side tries to solve a completely different set of problems than AJAX does. Java's goal is to provide a platform independent way of running rich applications. It provides its own libraries, UI toolkit(s), client-side business logic, and is self contained inside a virtual machine. AJAX on the other hand is just a cleaver way for browsers to provide asynchronous communication with servers. It provides nothing that JavaScript can't do already, it just spares you from having to submit a form every time you need to push/pull data.
Now, as for providing an easier method of deploying rich applications, take a look at Java Web Start. Applets are frankly awful; they're slow to load, have limited functionality, and sit inside a browser window (which is NOT where a desktop app belongs). Web Start solves this by providing an extremely simple deployment and update model, while maintaining the user experience only a rich app can.
"Perhaps AJAX will finally deliver what Java promised"
Java IIRC promised something else.
AJAX might deliver what Javascript promised.
Lost count how many times I've had to explain the difference.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
The problem with the Graceful Degradation principle is that it makes the same assumption that the designers of HTML made: the only thing people are going to want to do on the web is publish books.
When you're trying to create a full-fledged application on the web, base HTML just doesn't cut it. Hell, even for most websites, Basic HTML doesn't cut it.
The problem is that HTML was never really thought through. Creating sites in HTML (or any derivatives like XHTML) just doesn't work. HTML is a good model for the Gutenberg project but a bad model for everything else.
What we really need is a new language that has nothing to do with HTML that can create complex interactions. Unfortunately that doesn't seem to be happening. Even movements in that direction like XAML borrow too much from HTML.
Why doesn't Slashdot ever get slashdotted?
One thing I've found is that AJAX can be a very nice way to easily deliver random content to a user. Witness this:
The iPod bartender shuffle.
Choose your categories, and the notes are loaded seemlessly, and displayed onscreen. Then you can download a zip file.
(Oh, and I do agree with the goofiness of this terminology. Flash remoting? Invisible iframes? Anyone remember these? Bueller?)
concrete5: a cms made for marketing, but strong enough for geeks.
IE also supports client-side VBScript. The only time I've seen it used is in IIS's remote control pages and dynamic code generated by javascript specifically for IE (to check for Flash player, etc).
Do you even lift?
These aren't the 'roids you're looking for.
"Slow to catch on" eh? No pun intended?
...unfortunately no one can be told what The Mat^H^H^HGoatse is...they must experience it for themselves...
A ajax is based off of XMLHttpRequest which is not standardized, firefox cloned Microsoft's ActiveX XMLHttpRequest object. XMLHttpRequest will eventually make it into the DOM, well hopefully. There's been discussion on the mailing list about it.
Have you ever been to a turkish prison?
A great site for Ajax is http://dev.fiaminga.com/ It is a Ajax portal with plenty of links.
There is an article of the use of Ajax for distributed computing. Really refreshing.
We've been able to add a "Live Search" to This food and nutrition database search that is extremely responsive (Swish++ used on the back end to conduct searches).
We've also used it over at celebrity flicker for when visitors add tags to celebrity images, bookmark images to their account, and add comments to the discussion. It allowed us to make an interface that did not break the back button functionality while doing significant activity on the current page.
The guys over at JPSPAN are to be commended for their work on an easy to use library that works well with PHP.
Newsfollow.com
thought...
Ajax and Jason combine forces to rid the world of evil SCUM... (like certain (among but not all of) politicians, world figures, rogue secular/organized religious zealots, baby snatchers, paedophiles, embezzlers, larsonists, arsonists, FUDmasters, ms, and others...
Wow, "To confirm you're not a script,..."
Now, that's reminiscent of the cleanser Ajax, hehe...
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
Have a look at Anyterm for a fun "AJAX" application. It combines Javascript and an Apache module to provide a box on a web page that behaves like a terminal. So you get ssh access to your server from almost anywhere, even when there are firewalls etc. in the way. http://chezphil.org/anyterm/
good ole javascript... add to that the asynchronous http request component for client server communication and you have ajax, the problem still persists, that basically you run into limitations of the browsers.
To the worse the async http request component is not w3c conform and only works in some browsers (namely mozilla, IE, maybe konqueror safari..)
So you run into the same old javascript problems again, you run into a simple mess of having to target the IE and everything else, which follows the standards (even teh http request component cannot be accessed similariy over browsers)
So what is the difference? Well yesterday everybody hated javascript, today everybody loves javascript because it has a different name, but the same quirks.
THe "big deal" for a lot of web developers is that you can avoid annoying refreshes to update content. Using XMLHTTP you can retrieve your information in the background and use the XML DOM/DHTML to update only what needs to be updated - instead of redownloading an entire page (and flickering). I wrote a chat app a few year ago that worked this way and it was amazingly responsive.
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
http://www.omnytex.com/articles/ is a nice little introduction to Ajax. It includes a Struts-based example app.
... the AjaxTags project... if you are developing with Struts, this could be a nice thing to use.
http://struts.sf.net/
So I assume that you updated the map, founda crime, clicked on it, and read the text? Because the last part at all does not work in Safari 2.0.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
can any one venture a guess on the (testing) effort required to make ajax work seamlessly across all (reasonably recent) browsers?
IE first had the XMLHTTPRequest object (even though it is implemented via activeX *shudder*), and counts as one of MS' few legitimate innovations.
Now that other browsers have implemented it, the web has the potential to do what MS may not be able to adapt to: make the OS less important. Rich web apps can't replace everything, but the more robust they get, the less software people have to install. What they do have to install will have another layer of resources available.
The XML part of XmlHttpRequest is a bit misleading - you don't have to use XML and parse it in the client. If you use a server process that generates an HTML fragment, you can replace the innerHTML of a target id easily.
I made a JAH example to show how easy this is.
JAH stands for Just Async HTML
After setting
null = None
true = True
false = False
There are two remaining incompatibilities:
1. Comments
2. \uNNNN escape sequences are legal in python strings only if string is a u"unicode" string. But the u prefix makes it invalid JSON.
But it doesn't matter anyway - you'd never want to parse JSON in a Python server by passing it to eval() since it's horribly insecure.
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
Please, do tell me how vanilla HTML + good server side dev "doesn't cut it" for a web application or a website.
The only things that HTML frontend + server handling lack are reactivity and interactivity. They're not fast, and you get loading inbetween two pages.
And security, too, but you don't use webpages if you need security either.
CSS or JS do bring things, but 95% of the time they're not *needed* to achieve the goal, they merely improve the user's experience (which is nice but far from necessary, aka the user may do without when he needs to).
What else? Flash and Java applets? well, the needs of using them fit neither in "web applications" nor in "most websites".
The only thing i'm wondering about is what you mean by "complex interactions", and why you'd need them in a regular website
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
It is the nicest language I have ever programmed with and it can do wonders in the browser.
XmlHttpRequest is handy, but the same could be done long ago (IE4/NS4) if you were ready to put your sanity in jeopardy.
I developed a multiplayer online board game back in 2000 using only javascript. It is fully multi-threaded (yes) and the server-side is only for message passing.
Check it out (click on the apple) (NS4/IE4|5|6 only. Sorry, it hasn't been updated since 2001).
http://www.groupe-auffray.com/index2.html
I have been working on a dynamic application in Javascript, and have run into a problem that I haven't seen a solution to anywhere.
When animating something, it seems that modifications to the DOM are non-blocking, unless the previous changes to the DOM are still being layed-out, in which case the whole javascript engine (in fact the whole browser) ceases to redraw anything until the layout engine is idle again.
What this means is that setInterval(fn,delay) causes the browser to lockup if any frame of animation takes longer than (delay) ms. setTimeout(fn,delay) called after the animation frame to schedule the next frame of animation doesn't work either, because DOM changes don't block on page layout completion.
Any ideas of how to fix this?
Interviewer: "I'm here with Brendan Eich, the creator of Javascript. So, Brendan, it looks like some companies are doing some pretty awesome stuff with Javascript these days! Word has it this was what you envisioned for Javascript from the beginning."
Brendan: "Yeah... um, this is exactly what we envisioned! Awesome tools like what Google is doing with the maps thing, and the... uh... craigslist + Google maps thing! Yeah.. these companies are finally doing exactly what we had originally planned, so... just wait until they come up with--I mean finally catch on to our big picture and we'll let you know what else we had envisioned! You'll just have to wait and see what we take credit fo--I mean, the other ideas of ours they catch on to!"
Personally, this game would be my favorite, except it doesn't work in Firefox/Mozilla (sorry, IE only) - I have tried to email the author about this, and I am sure others have as well - but either the problem is something he needs is IE specific, or he just doesn't give a damn. I hope it is the former...
Reason is the Path to God - Anon
Why is it so hard to understand? Java and Javascript are totally different. They have similar syntax and such, but Javascript has absolutely nothing to do with the Java foundation or Sun. It is merely a client side scripting language. You don't need a JVM to run it. It uses the Document Object Model of HTML pages to allow your browser to do fun things like the great stuff that google maps does. Seriously... Get it straight! (And shame on slashdot editors for not correcting the poster in the first place.)
Anyway, AJAX seems pretty cool. I wish I could devote a few months to study it because I think it is the future. Technology like AJAX is what is going to make web-based operating systems (and useful thin clients) a reality. IMHO.
1, 2, 3, 4, 5... That's the combination on my luggage!
Comment removed based on user account deletion
Netscape had some cool demonstrations of this, and they were pointing that out you could do "style sheets" with this .. "javascript style sheets" or JSSS (or sometimes JSS).
However, at about that time w3c and msft got together to push CSS style sheets instead, partly in order to torpedo netscape. (There was a lot of bad blood between w3c and nscp; I was at both CERN (on TimBL's team) and nscp, so I saw both sides.)
But CSS sucks, so this whole thing fell off the radar for most people.
REPEAT!!! THIS IS NOT NEW!!! IT'S BEEN AVAILABLE FROM THE INCEPTION OF JAVASCRIPT!!! AAAARRRGH!!
Yeah sure, considering cross-browser compatibility and web-standards compliance is at an all time low i don't think its going to happen. I've been writing javascript and its an absolute bitch to do anything that will work on a decent range of browsers while still falling-back neatly for non-javascript viewers, although it does have some decent features in that you can check if a particular object is supported with an if() it still has to much variance between implementations. This is why things like flash do so well, because you know that Flash, while not being a W3C standard in any way, does in fact have better consistency, rolled out, right now, than the W3C could ever even hope to achieve with the fucking crap browsers out there. Yes Flash isn't the best format, it's not as well structured, it has no text-based fall back, it's not easy to integrate or hack but it beats the alternative hands down if you want a platform independent program right now. If everyone dropped all these nonsense fads like 'KHTML'/'Safari', 'Opera' and 'IE' and started using Firefox then yes, maybe it could all work out, but as it stands, you simply cant rely on javascript.
This comment does not represent the views or opinions of the user.
Perhaps it's because of the bad karma you get from posting offtopic tech support requests for a specific web page in a thread discussing programming techinques on a completely unrelated other web page? Just a guess...
Of course you do not want to blindly eval() source from client-side javascript. Duh.
The Python JSON parser I linked to is very small, very fast, and handles None/null and true/True for you.
I did, however, have to edit the parser. I've found that client-side javascript does not like single quoted values when eval'ing a json string, so I modified the Py-JSON parser to change all values to double quotes.
JSON is vastly superior for this task than XML parsing.
In the days of NN4/IE4 it was called "loading another frame with dynamically generated pages containing data".
Give me a freakin try... catch block!
But what has Java (BTW Sun TM) got to do with A-J-A-X?
Or is this some sick twist how slashdot editors enjoy their power over the dumb masses of !RTFAers.
I don't know about you, but between all the nuances in the javascript, and all the newances in the DOM, and trying to figure out where one starts and the other begins, and have you ever tried to figure out which functions/properties work correctly for which object, and have you ever tried to figure out which DOM to use and how to make DOM's of different browsers compatable, or even simply trying to figure out which objects are really on your web page, and then trying to deal with things like XML parsing on top of that, and then now asynchronous communication, not to mention new things in the pipe like XUL, and franlky ....
Forget the toilets, AJAX is kicking my ASS and I can't imagine that other people who want to do more than copy cutie javascript tidbits aren't having the same problem. What am I missing here?
I have to agree also! Javascript can seem so damn cludgy when implemented for worthless stuff, yet so useful at the same time. The quote from the "World's Most Misunderstood Programming Language" says it all, "Most of the people writing in JavaScript are not programmers."
But, the problems are in developing applications based upon this scheme. Perhaps google should expend some effort in conjunction with Mozilla, to standardize some of this stuff. The mention of JackBe had intrigued me, with the possibilities of toolsets for developing across disparate platforms.
Good post.
I've built some tools that use XMLHTTPRequest object and I've found them to be complete hell to debug. As if javascript was easy to debug anyways. But with AJAX the only error message you ever get is InternalSeverError. Makes it not very enjoyable to work with at this point.
Java client-side scripting works, but the LiveConnect object is undocumented, unsupported, and buggy on Internet Explorer.
Actually, that's not a huge problem, because LiveConnect was poorly supported and buggy on Netscape 4.x series, too.
I have no idea LiveConnect even exists on Mozilla/Firefox or KHTML.
And yes... VBScript, PerlScript, PythonScript, etc. probably all work on Internet Explorer. I'm guessing you'll find very few developers who write pages that depend on them, though.
The Konfabulator site needs more categorization. If I took out all the clocks, countdown timers, single-purpose RSS readers, and webcams, there'd be like six widgets left. I've never seen so much useless junk in my life. Well I suppose I have actually, but not in this particular fashion.
I am no longer wasting my time with slashdot
If you read what the sentence is saying - here is a paraphrase:
"JS (in the form of the AJAX buzzword) may finally fulfill the promise that Java made" ie write once, run everywhere.
You know that promise, the one that hasn't worked out for various reasons, including anticompetitive practices by MS. -- Exhibit 97 (MS7 026935) DOJ trial, Microsoft's P. Sridharan 9/1/97 email.
- the nickname for a blackjack starting hand consisting of an ace and a jack
- the name of a mythical Greek warrior who fought against Troy in the Iliad
- the name of a swiss car built in the early 1900s
- an Italian word meaning "appropriate name"
What's your point?Here's one of the results of my reverse engineering so far:
... I decided to parse incoming messages for geographic locations and provide a way to view a map of the location...
"Ever since I'd been working on various Google Maps hacks I'd been thinking, 'Hmmm, I've done Gmail hacks and Gmaps hacks, what could I do that would combine both?'.
This page includes some very basic instructions for using an initial rough version of this functionality that only maps US State/Zip codes locations. (The current version is a bookmarklet, but it would be ideal for a GreaseMonkey script...)"
-- http://stuff.rancidbacon.com/gmailmaps/
--Phil.
More functional? Dashboard widgets have the complete OS X toolkit available - you can hook into anything. Konfabulator is javascript only. Try again.
Konfabulator can invoke the Unix shell scripts (on Mac and Win), as well as having a built-in AppleScript interpreter (Mac-only); anything you can access via AppleScript or a shell script can be accessed via Konfabulator.
With Dashboard, you can either display your widgets, or display your active applications; you cannot do both. With Konfabulator, you can have any number of widgets and active applications on your screen as you want.
You can't force a malicious widget upon a user under Konfabulator.
Dashboard doesn't run under Windows.
Konfabulator not only runs under Windows, but 99% of the widgets are platform-neutral and can be run on either Windows or Mac without any modification.
Konfabulator can interact with COM objects.
A Konfabulator 2-seat license costs only $19(US), even less if you don't mind nagware. Dashboard comes bundled in with a software package that'll cost you $140(US) per seat. Even then, it still won't run native on Windows.
- Despite popular opinion, I am not perfect.
The XMLHTTP object was introduced w/ IE5, and that has been around for awhile (pretty sure since 2001, maybe longer). I can see how this might make the Microsoft apologists bitter now that this 4 year old feature is now in vogue, but I think at the time there wasn't the critical mass (in spite of IE's market share).
Now that it's implemented on multiple browsers, and it has a Killer App (Gmail), developers are starting to see the potential.
"Don't trust the client?"
I'm still trying to sus the AJAX thing out but it seems like a horrible idea from a security perspective. I know the js is href'd from the server but there better be some serious validation server side.
I know I wouldn't want to try and hack at this for any nefarious reason but it could be done.
"Fighting the underpants gnomes since 1998!" "Bruce Schneier knows the state of schroedinger's cat"
I see a few sites that are replacing traditional navigation w/ Ajax components that update on-the-fly when users click on a link (for example, changing what's displayed on a multipurpose widget that appears beside your blog entries). Yeah, you're using ajax and that's neat, but once the user clicks the "back" button they go back to the site before they went to your site. Oops. Not what the user expects. It's 2005 and you've just implemented Frames. And not just the ugly Frames you see today, but the downright nasty frames of Netscape 2. Goodbye Back-button, and goodbye bookmarks.
On the other hand, using Ajax as part of a stateful transaction could be well-utilized. In some cases it improves back-button behaviour because it avoids letting user roll back to a page that reflects a state that doesn't exist on the server.
Soo... my humble opinion
The Back button's existence has long drawn the ire of web app developers, It's difficult to handle on the server side, and extremely diffifult to uphold the functionality that the user expects. For example, if user clicks "back" because they accidentally added something to their shopping cart... the implementation of the behaviour that the user expects ("if I click back, I won't have it my shopping cart anymore") could fill a book.
Still, it's a good metaphor, and I think developers should try as best they can to preserve it in their apps.
AJAX.NET!!
- completely incompatable with Mozilla and FireFox
- executes arbitrary code on the client machine!
- embraced AND extended
The problem with "AJAX", compared to NeWS or OpenLaszlo, is that imaging model sucks, because it's limited to the lowest common denominator of HTML across all browsers. NeWS uses the PostScript imaging model to render interactive user interface components (buttons, sliders, pie menus, tabbed window frames, etc). OpenLaszlo uses Flash graphics to render interactive user interface components (all the widgets you expect, including a full widget set skinnable with Frash graphics, supporting animation, transparency, color tinting, etc).
As a imaging model, Flash is nicer than PostScript in some ways, not as nice in other ways, but vastly superior to HTML. It's also interesting to compare Flash with SVG, which is also great for implenting "AJAXian" user interfaces, but doesn't have nearly the installed base. The best thing about Flash is that it's exactly the same across all platforms, and it's got a great installed base.
-Don
Newsgroups: comp.windows.news
From: don@BRILLIG.UMD.EDU (Don Hopkins)
Local: Sat, Feb 6 1988 5:38 am
Subject: Comparing Display PostScript and X11/NeWS
[...]
NeWS has extensions to the PostScript language that allow for programs (light weight processes), running in the display server, to receive input events on behalf of NeWS clients (other programs running on the same computer, or at some remote site). They may process input locally (on the same machine and in the same process where the events are happening), without consuming any communications bandwidth. This is a big advantage, if you want fast, responsive graphical feedback.
NeWS processes can communicate with each other by manipulating shared data structures, and by sending messages through the event queue. They can receive low level input events ("The left mouse button was released at location (X,Y) in window W at time T"), and give graphical feedback ("erase the old slider, redraw it at its new position, and fill the border with bright red"). They can translate input from the user into high level, application specific events, which are sent to the client ("set the volume of the CD player to 100%"). NeWS processes can run autonomously in the server, without a connection to a client, providing "desk accessories" such as a calculator, event journaling, menus, and control panels.
According to the fellow from Adobe who talked at the PostScript BOF at the X conference, Adobe's Display PostScript provides output capabilities, but has no facilities for receiving input directly from of the X event queue. As I understand his explanation, the X server must send X events over the IPC link (network, shared memory, modem, or whatever) to the client, which must then translate the events into PostScript commands, and send them back over the link to be executed by Display PostScript. Because there is no way for PostScript programs to read events off of the X event queue, the client must process input events behalf of the display server. Messages must go on a round trip, from the X server, to the client, and back to the Display PostScript extension in the server, to produce any graphical output on the screen.
[...]
The NeWS "Lite" user interface toolkit is written entirely in PostScript. Menus, buttons, windows, sliders, scroll bars, and even terminal emulators, are implemented as device independent PostScript programs, in NeWS's object oriented PostScript programming environment. Since the toolkit can run in the server, clients can share the same code, and a copy of the toolkit does not have to be linked into each client. It's easy to mod
Take a look and feel free: http://www.PieMenu.com
I modded him as flamebait because he asked me to :)
http://en.wikipedia.org/wiki/Showstopper
It's possible the latest version has caught up by now, but I found quite recently that I couldn't use a function as the replacement in String.replace() (like perl's s///e).
The only conclusion I could reach after banging my head against a wall a lot about that browser is that if to do serous Javascript programming, you just have to forget about Safari.
One day they'll catch up, I'm sure ... but there need to be apps out there which people want to use before Apple realizes that their precious browser is broken. Let's go ahead and put them out there.
-- Only unbalanced people can tip the scales.
What's your point?
:P
I'm just getting tired of all the bogus IT slogans.
What does it even stand for anyway? And why is that different than Slogan X? Really? Why? Why???
Sweet, sweet irony.
[%] Cingular Ringtones
Perhaps it will really provide a solid way to distribute software seamlessly.
Given how many of the recently discovered vulnerabilities were in the JavaScript or ActiveScript part of the browser, this indeed seems to be a good idea for seamless malware distribution.
OS Reviews: Free and Open Source Software
Yes/yes and yes (all 3 have liveconnect support).
rage, rage against the dying of the light
JAVASCRIPT IS NOT JAVA YOU DOLT! And it never will be, think ECMAScript
EDITORS! Do your jobs!
Laszlo used to cost about ten thousand dollars per license, but it is now fully open source and free. Flex costs more than ten thousand dollars per server license, and has restrictions on how you can modify and redistribute Flex components.
Macromedia has a spotty track record supporting their server software over the long haul, and now that Adobe's bought them, Flex is in Flux. Laszlo is here to stay because it's available now, free and open source, and you're not restricted in how you can modify and reuse Laszlo and its components.
Flex is a lot like Laszlo, because Flex is Macromedia's imitation of Laszlo, but Flex is intended to lock you into Flash instead of giving you independence from it.
The most important difference between Laszlo and Flex, is that Laszlo is not tied to Flash, it "just happens to" use it right now, because that's the most practical target platform at this point in history. Laszlo is a high level JavaScript/XML based language which currently targets the Flash player as its initial platform, with more to come.
Laszlo abstracts away Flash dependencies, so it will target other runtimes than Flash in the future, as they mature and shake out: Java (Rhino/Java2D), C# (CLR, GDI+, Avalon), C++ (SpiderMonkey, CGI+, Quartz, Cairo, AGL), SVG (Adobe, Batik, Firefox), DHTML (web browsers, JavaScript, AJAX).
But right now Flash rules, and Laszlo is the best way to develop rich web applications that run on Flash.
One really interesting possible target platform for Laslo is an open source Flash player, that can easily be integrated into applications and games, and uses OpenGL with hardware accellerated rendering.
-Don
Take a look and feel free: http://www.PieMenu.com
Wouldn't it be great if this worked:
<script type='text/python'>
So someone hurry up and write a Firefox extension to allow this or else I'm going to have to do it myself.
If other reasons we do lack, we swear no one will die when we attack
You're still programming in a brain damaged environment. The browser provides a tiny fraction of what the entire system is capable of and a tiny fraction of the refinement of the programming interfaces that have been around since the '70's. The only way that programmers will be able to cope with these shortcomings will be to increase the scope of the browser until it pretty much becomes the OS. At which point we will have gone full circle.
Interesting point, and that's probably Google's long term business plan - the browser becoming the OS. And that's exactly what Microsoft is afraid of - removing the need for Windows altogether.
I for one would love to see that come to pass - just to create some competition (and better quality) for your OS purchasing dollars.
If you're writing the javascript for this stuff yourself, you're already broken. You really need a framework which makes interacting with server-side stuff easy. Check out Direct Web Remoting (DWR). DWR allows you call methods ON YOUR SERVER within javascript, using the same names and classes as on the server side. Very cool.
Too big to fail? Does that make me to small to succeed?
With Dashboard, you can either display your widgets, or display your active applications; you cannot do both.
No, with Dashboard you can bring up your widgets without having to free up screen real estate or move windows, which happens to be about 1200% more useful. You hit f12, and its there! You hit f12 or click somewhere that isn't a widget, and its gone! As an added bonus, the widgets exit their run loop when they aren't active to free up resources.
I've been mostly ignoring JavaScript for some time now. With many useful [browser-side, modify web pages locally to suit your presentation desires] Greasemonkey scripts available, however, and the relative ease of creating my own scripts to customise web pages I view, I'm suddenly very interested in JavaScript.
What about you?
I think it stands for Asynchronous Javascript and XML.
Battling Beasts
Otherwise there'd be tons of lame Wheel of Fortune jokes due to the SAJAX mention.
Great blog post by Ian 'Hixie' Hickson (of mozilla.org, Opera, W3C CSS-WG fame) on making new names for existing technologies
http://ln.hixie.ch/?start=1111339822&count=1
You know, Microsoft's street address also says a lot about their mentality.
Why is JAvaScript a poor language? Is it because the language is so concise the spec for it is readable in one sitting? Is it because of how robustly simple it is?
Perhaps what you're refrrign to is inconsistencies in browser's and old-skool problems from the days of Netscape and IE 3. NOw-a-days JAvaScript is the laymans name for ECMAScript which is a clean, standard, robust, simple but powerful language. It can be used in web pages, server-side components, embedded in dozens of other languages, etc. Heck, any WIndows guy worth their salt would prefer WSH with ECMAScript instead of batch files.
Do not confuse the language with its origins.
I'm developing a proprietary database application (back-office type thing) for a business. I am using PHP and the Smarty template engine to serve up XUL to Firefox. The client uses an XMLHttpRequest object to call certain server-side PHP scripts that will perform database (MySQL) queries, and reply back with a javascript code block, which the client executes with exec().
For example, you might save a record. If the save was a success, the server replies with the javascript code to make the GUI un-editable again. If the save failed, it will reply back with the code to show an error message. Lots of flexability -- I'm certainly enjoying it, and would recommend it to others (even though its not proper AJAX or XUL usage!)
If you want a responsive web application, would it not be better just to use Flash?
I believe flash can communicate to the server as well, so it would be able to do anything that a Ajax application would be able to do, plus you have these pros:
* Comprehensive debugging abilities (I think javascript only has debugging available in Mozilla)
* No cross-platform worries - flash plugin is available for all platforms, usually installed by default.
Multimedia support - you can make your apps a lot prettier with little effort in Flash.
The only disavantage is that Flash has no clipboard support (i.e. you can't select and copy text like you can in browser apps).
There's a nifty way to avoid having to maintain global references using JavaScript closures, which most people don't know about:
0 9835.html
c lMem
xmlhttp.open("GET", "test.txt",true);
var myObject = this;
xmlhttp.onreadystatechange = function() {
if (xmlhttp.readyState==4) {
myObject.doSomething(xmlhttp.responseText);
}
}
xmlhttp.send(null);
So, the onreadystatechange function can access the 'myObject' variable like its a local variable, so that it could call back to that object when things are ready. JavaScript has full closure support:
http://jibbering.com/faq/faq_notes/closures.html
http://www.forum4designers.com/archive22-2004-8-1
Very powerful feature. Make sure to read a limitation of closures on IE:
http://jibbering.com/faq/faq_notes/closures.html#
Some boundry conditions of using them on IE can lead to memory leaks.
Ajax give much better user experience for the general public, but if you develop for a intranet, flash or Java are just fine. Here is an example of AJAX at work. It is infact modified after the APPLE example. www.mobilityreview.com http://www.mobilityreview.com/
Really, it's not.
Yay me!
For those interested in examples of AJAX apps or interested in building them:
r chives/000385.php - comprehensive outline of AJAX for the beginner
- jpspan.sourceforge.net - PHP/Javascript object serializer
- www.dojotoolkit.org - Rich Web Application toolkit for AJAX apps
- www.feedtagger.com - AJAX based/tagging RSS aggregator
- http://www.adaptivepath.com/publications/essays/a
Like, think you can, um, like, view source? Man, that's the coolest. You can, like, see what your browser is, like, rendering and stuff. heh heh.
I forget what 8 was for.
links to great time wasters like AJAX magnetic poetry, AJAX magnetic letters, and AJAX Weboggle
anything you can access via AppleScript or a shell script can be accessed via Konfabulator.
.dmg files, meaning "modification" is required.
Ditto for Dashboard. osascript can be used to run scripts from the OS X shell.
With Dashboard, you can either display your widgets, or display your active applications; you cannot do both. With Konfabulator, you can have any number of widgets and active applications on your screen as you want.
I concede your point, but humbly suggest that some people like this fact.
You can't force a malicious widget upon a user under Konfabulator.
This is a bug in Safari, not a feature. I'm sure it will be fixed shortly. Mac users who run Firefox or other alternative browsers will be prompted before running the widget. In any case, Dashboard widgets run under more restricted permissions than Konfabulator. A Dashboard widget has to show you a dialog box to get permission to access the network. Running a Konfabulator widget provides no prompts or other warnings.
Dashboard doesn't run under Windows.
Conceded.
Konfabulator not only runs under Windows, but 99% of the widgets are platform-neutral and can be run on either Windows or Mac without any modification.
Konfabulator's widget gallery shows 569 Windows widgets and 1,024 Mac widgets - slightly more than a 1% difference. Windows users cannot easily download
Konfabulator can interact with COM objects.
Dashboard can interact with OS X however it chooses (with user permission).
A Konfabulator 2-seat license costs only $19(US), even less if you don't mind nagware. Dashboard comes bundled in with a software package that'll cost you $140(US) per seat. Even then, it still won't run native on Windows.
Unregistered shareware is a violation of the terms of the license, hence illegal. I could just as easily argue that Tiger is free if you don't mind spending some time to find the torrents. That $140 is not exclusively paying for Dashboard. There are plenty of alternative licensing arrangements, including a family pack that drops the price to $40 per seat. One could also argue that Dashboard comes with the computer, while Konfabulator is an extra you have to pay for.
Now, let me ask you:
1) Which software do you think has more installed seats, Konfabulator or Tiger? Which has more brand recognition among the target audience? Which is more likely to gain developer support (hence more widgets) due to the larger installed base?
2) It's dirt-simple to develop a Dashboard widget: it's a web page bundled with a simple instruction file. Konfabulator won't render HTML for you. You have to use their format and their JavaScript objects.
3) Which interface is more polished? Flipping over widgets for configuration helps keep your attention on what you're doing, and it also provides an excuse for not updating the widget on-the-fly. I found myself wondering why the colors on widgets in Konfabulator didn't change as I tweaked the settings. The fact that I saw both the configuration and widget at the same time made me think that updating one should affect the other. On my computer, pressing F8 for Konspose took about a second to render - about the same time as the entire Dashboard animation - without the effect.
I think Apple was wrong to copy Konfabulator, but that's over and done with, and they clearly have the superior product now.
kudos! simply replacing part of the xhtml dom is exactly what is most interesting to many.
Unfortunately, present online tutorials only show dropdown-menu exchanges, etc. as they are even simpler to implement.
what I personally would prefer is to use XSLt to translate machine-understandable XML (e.g., rdf) to html at the last stage of the pipeline. I'm pretty sure it's possible, but as webdev is not my forte I haven't looked into it yet.
It could seriously reduce bandwidth consumption at the cost of client-side CPU usage increase.
The No.1 library I'd like to see is some serverside code that automatically generates diffs between pages and the clientside to automatically apply the DOM changes. Diff support in HTTP was proposed (forgot the RFC no.), but never implemented. This could implement differential updates through a backdoor
Agreed. The gallery is a nightmare. Several users have mentioned this on the forums. The developers are in the middle of revamping their site for the new release (v2.0). I can only hope they plan on fixing the gallery as well (e.g., display widgets by # of downloads, popularity, date, etc.).
- Despite popular opinion, I am not perfect.
With Dashboard, you can either display your widgets, or display your active applications; you cannot do both. With Konfabulator, you can have any number of widgets and active applications on your screen as you want.
I concede your point, but humbly suggest that some people like this fact.
Then you'll want to place all your Konfabulator widgets on the Konspose panel; this prevents them from appearing until you call up the panel.
A Dashboard widget has to show you a dialog box to get permission to access the network. Running a Konfabulator widget provides no prompts or other warnings.
A good software firewall will trap any outgoing connections and prompt you for confirmation first.
Which software do you think has more installed seats, Konfabulator or Tiger?
At this point, I'd say it's probably evenly split between existing Konfabulator users on both platforms and Tiger early-adopters. In the long run, Tiger will almost certainly have more users.
Which has more brand recognition among the target audience? Which is more likely to gain developer support (hence more widgets) due to the larger installed base?
Unless Konfabulator gets some heavy press in the near future, again, Tiger'll win hands-down.
It's dirt-simple to develop a Dashboard widget: it's a web page bundled with a simple instruction file. Konfabulator won't render HTML for you. You have to use their format and their JavaScript objects.
Konfabulator's XML is simpler and easier to use than HTML, frankly. If you want to set an object's position, you use object.vOffset() and object.hOffset(), as opposed to setting CSS properties via HTML. As for its inability to render HTML, that's what you have a browser for.
I found myself wondering why the colors on widgets in Konfabulator didn't change as I tweaked the settings.The fact that I saw both the configuration and widget at the same time made me think that updating one should affect the other.
Under Konfabulator 2.0, you can create a window to display HSL controls, allowing you to adjust coloring in realtime.
pressing F8 for Konspose took about a second to render
Check out Konfabulator 2.0. Performance has been improved.
- Despite popular opinion, I am not perfect.
Well, you're right in that regard. JavaScript lacks the nice message-sending utilities of other OO languages like Smalltalk, Objective-C, Ruby and Python.
But I disagree with, "This makes it difficult if not impossible to create object oriented applications using MVC and many other OOP design patterns." It's obnoxious, but it's certainly doable. This is one of the many reasons why the Command Pattern was invented.
Slashdot. It's Not For Common Sense
Check out Konfabulator 2.0. Performance has been improved.
Really? I'd hate to see what 1.x was like...
here is a cool AJAX site... http://www.ajaxadvocates.com/
By "compiled" I mean "converted to machine code" the primary meaning of the word for the last 50 years.