Slashdot Mirror
The Future of AJAX and the Rich Web
jg21 writes "This AJAXWorld Magazine article indicates how far AJAX has come since devs complained here two years ago that it sucked all the time. Eight experts were asked what questions we should now all be asking about where AJAX is headed next. The suggested questions are refreshingly hard-headed, including: 'How are we to fix the web?'; 'When will AJAX development finally be easy?'; and 'Do we really need JavaScript 2.0? Won't it be somewhat irrelevant by the time it becomes commonplace and thus usable?' One of the most interesting questions came from Kevin Hakman, co-founder of TIBCO's General Interface: 'On what timeline will AJAX skills become commoditized like HTML skills became?'"
Our Ajax overlords :^D
Couldn't resist...
If I had an Ass, I'd call it Fanny Bottom, then I could slap my Ass; Fanny Bottom, on the Arse.
It's slow and an accessability nightmare. I say it still sucks.
It already is. What is so hard about it?
As anything but a way to make webpages slightly interactive, Ajax will never become mainstream. Ajax as an application platform has no chance against Silverlight and Flash/Flex. The complexity of Ajax is inherent to the display control: HTML is simply too convoluted for application development.
Now why does slashdot eat my tags when I post as Plain Old Text?
Probably the biggest thing I see is that we live with a 'quirky' web where you write an HTML/CSS document and have to adjust for problems with one browser or another (or not support some because of such things), while the use of standard libraries and tools have provided automatic solutions for much of the quirks they still limit the possibilities.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
It seems to me that developers that can write decent HTML are still an extreme minority. I still see href="javascript:", "<div> s are better than tables for layout", a chronic amount of invalid code, and all kinds of other idiocy all the time. Sure, if you want monkeys to throw tag soup all over the place it's not hard to find them, but that doesn't mean they know what they are doing or that it's easy to find people who actually understand HTML.
Bogtha Bogtha Bogtha
In the beginning, there was client server.
Then, there was n-tier with the thin client.
Now, the client seems past the bout of anorexia, we've gone back to client/server, and AJAX has fattened it right up.
Next (mis)step? N-tier, repackaged as "federated", with an emphasis on thin, mobile clients. But you knew that. The real question is, what will AJAX for the hand-held be called? I say: BORAXO.
I will confess some guilt that this has not been reduced to a Burma Shave troll, but I'm still slightly under the weather.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Ajax *is* mainstream - Google, Yahoo, Microsoft, Apple - all using ajax in one form or another in their web applications. Now - as to your other claim, that Ajax doesn't stand up to Silverlight or Flash; I say Flash!?! Have you every built an application in flash? It's a nightmare to maintain. I can't speak to Silverlight, as I've not yet played around with it. But the design theory of ajax combined with a good JS api (like prototype) Makes it a much more maintainable and IMHO a nice way to build interactive web apps.
The secret to creativity is knowing how to hide your sources. - Albert Einstein
I claim first serious post.
Most of these questions appear to me to be either leading questions, whose intent is to foment desire in the questioners product(s) and/or service(s), or marketing questions.
Some of the questions are legit, however. For example, those questions concerning security, performance, unit testing, and analytics.
With regards to the question about which framework to choose, I have posted my favorites here.
I think a large part of the people's opinion on AJAX depends on what they're doing. It's difficulty depends in part on the framework/libraries you use. For example, script.aculo.us and RoR hide many of the details for you. On the other hand, if you do outside of what they do well, the difficulty level quickly rises.
I think one sign of this difficulty is that just about all AJAX libraries do the exact same thing. The same basic special effects, field additions, etc. The fact that none of the libraries go beyond these, points to what's hard to do.
Javascript isn't a great language. It's not robust, and it's difficult to really do good architecture with libraries using it. HTML is a pretty decent method to mark up text, but wasn't meant originally to ever be interactive.
Tying together a hacked together language with HTML doesn't make for the greatest programming experience. Especially compared to any real GUI framework.
Maybe most people don't want/need a real GUI framework, and AJAX covers all the bases for them -- in which you're probably going to say you like AJAX.
However, I suspect if AJAX and HTML were really so great/powerful/easy, many people would have stopped using flash already. I have no love for flash, but it can do things much more easily/faster than AJAX can for many tasks (disliking both technologies I'm pretty non-biased here).
What I would love to see is a standard *real* GUI for the web that is non-language dependent (i.e. whatever scripting language you prefer you can use). I'd even use something like Jython with newer/better GUI libraries. But we really need something written from the ground up with GUI in mind.
Flash!?! Have you every built an application in flash? It's a nightmare to maintain.
Screw that, flash is a disaster to *use*. Flash causes a reflex in me that causes me to mash the 'back' button ASAP.
Toss out JS, and put python on both client and server.
Toss out HTML and make an XML based form layout language, with a *proper* rich widget set, and GTK-style splitter based layout mechanics.
Toss out the request-response paradigm and go with a proper connection.
In other words, make it a browser based application framework, because that's what people actually seem to want.
All this AJAX malarkey is just a *huge* kludge.
Post extrans (html tags to text)
<b> <i> <p> <br> <a> <ol> <ul> <li> <dl> <dt> <dd> <em> <strong> <tt> <blockquote> <div> <ecode> <quote>
and perveiw.
Easy: when a WYSIWYG editor, a la Dreamweaver, can accomplish all basic AJAX functionality without having to mess with much, if any, code.
Yeah - sure - Dreamweaver is suboptimal, but for 95% of what you need in a site (and if your site is fairly simple, 100%) it does the job, just fine, and you don't need to mess with that messy HTML and javascripty goopety glop. you just treat it like InDesign or Quark, and design your page - no muss, no fuss, nothing too fancy.
When Dreamweaver (or some similar app yet-to-be-developed) can do Exactly That - let me do AJAX without touching code, then you know AJAX coding skills will commoditise and disappear. How many hear can read PostScript, raise your hands! Not too many. I figured as much... FreeHand, Fontographer, and Illustrator removed the need to know how to program a page description in PostScript. Dreamweaver ate HTML and trivial Javascript. AJAX is next... I'd say, give it 2 years. Tops. I'm sure the programmers at Adobe are hard at work mulling over how to do just that.
RS
Shoes for Industry. Shoes for the Dead.
It does suck.
As for the "refreshing[] hard-headed" questions, all I see are questions about performance and silly flitting about with their own buzzwords and pipe dreams about getting rid of real applications in favor of their toys.
Here are some questions:
I'm implementing Web-based applications as of this writing, and I plan to have some dynamic features to simplify some of the UI (such as cascading follow-up questions during user signup). But these will be an optional extra.
These jokers forget that the World Wide Web is a repository for mutual citation of academic-style documents. New stuff is good, just don't break the old stuff.
Every improvement on the Internet has been in the direction of better user controls, decentralization, caching, peer-to-peer, transport tunnels, etc. The AJAX people are swimming against the tide and they need to realize it and shape up.
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
...Ajax is a project in hype -- strip all the cruft away and it comes down to one frigging javascript command. That aside, it has its uses. That is, if it is used wisely.
The only thing I disparage in Ajax is its lack of a back button. All the rest is positive in my books -- time/bandwidth-saving partial page reloads, perhaps the elimination of the "disorientation factor" that can occur with total page reloads (That "Wha? What's taking so long to load? Where the hell am I now?" feeling that grows proportionally the shorter the short-term memory/attention span). I like the feeling of control it gives a user (he's selecting the information he wants without being bandied all over the place). I've built a website using a mix of php/mysql/ajax and it's working fine for our customers -- not one complaint -- au contraire in fact. Have a look here if you like. What I like the most (in that site) is the fact that our customers can always keep their "shopping cart" (rather "rental cart") always on hand, and add/eliminate things to/from it no matter where they are in the site. I'm not sure of the numbers yet, but this has been a big boost to our client base.
Another Ajax drawback could be its un-friendliness to search engines -- but there is a workaround for that (a liberal use of hard-coded links with added "onClick" functions), but this means that you have to build your website in two different-functioning levels. This takes a bit of thought beforehand, but it can be done.
As for Ajax's future: of course. But forget the buzzword and the technology behind it; it's what the technology does that will be sticking around in one form or another. For example, it is possible to build a full-Flash website that behaves exactly as Ajax - with even more search-engine limitations and added "plugin" requirements -- so I think more than a few see the merits of partial page reloading.
No, no sig. Really.
ThePromenader
i know alot of people here hate microsoft (duh!)
but i believe silverlight will be a large part of the rich web
now this is my personal opinion and heres why:
*it was designed with web applications in mind (XAML) unlike the current html/css/javascript mess
*its more or less crossplatform
*it brings C# to the clients browser (see javascript mess above)
*has vector and hd video supprt of the box
*is designed to be easily updated
Developing applications in Flash is old school. These days, you're supposed to use Flex.
What we still need is to continue moving towards full interoperability. Hopefully having a proper spec will help with that.
Behaviour such as handling of getResponseHeader(header) when no header exists still varies: IE returns null, Fx/Opera return an empty string. If you want to check if a header exists, claiming it is an empty string isn't helpful.
Lots of people seem to welcome AJAX, and it does provide a huge step in the interactivity of web interfaces without sacrificing platform compatibility or development time.
However, one thing that continues to surprise me is how willing most people are to having a third party store all of their data. All AJAX apps essentially require that you do not hold your own data -- it's held by the application provider. A big reason is because Javascript can't touch your local filesystem, but another is that Javascript isn't powerful enough to really be useful for all of the processing, so back to the server-side scripting it goes.
In fact, one of the things that scared me today was how excited a friend was to discover that Google's chat application logged all of their Jabber conversations -- even if they had been made with a 3rd party GUI client (Pidgin). This, to me, would just be scary.
--
Educational microcontroller kits for the digital generation.
>Have you every built an application in flash? It's a nightmare to maintain.
Yes, I do it all the time. My apps are easy to maintain, because I make them that way. What about yours?
It's not the code, it's the coder. It's not the language, but the skillful use of that language.
Well, as soon as search engines learn how to "read into" flash, for starters. Otherwise the web (for Google) will turn into one giant, blank page.
No, no sig. Really.
ThePromenader
Three of those four vendors have published their own AJAX libraries for outside consumption. This accelerates adoption which is important from the standpoint of going mainstream.
...can't speak to Silverlight...design theory of ajax combined with a good JS api...makes it a much more maintainable and IMHO a nice way to build interactive web apps.I have not used silverlight either. Those whom I have spoken with about it are jazzed about it because you don't have to use java script as the programming language. IMHO, there are serious problems with java script. Not that there's really a problem with the language itself. Rather, the problems show up in how the code engines are implemented. I have gone into more detail about this here. Good programmers can live with these shortcomings either by rendering most of the GUI via HTML and using java script only lightly (i.e. validating event handlers) or by using good libraries and debuggers.
How does that differ from regular web applications holding your data? There's been well over a decade of time for users to become comfortable or uncomfortable with the idea of entrusting a third party with their data. So far, users have been leaning toward "comfortable".
Javascript + Nintendo DSi = DSiCade
What kind of applications do you develop in flash? And who maintains them once you've released them, you or someone else?
The secret to creativity is knowing how to hide your sources. - Albert Einstein
Why?
Yes people that use flash for layout and menus are just as stupid as people that used Java buttons.
But Google doesn't need to read applications.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Checkout labs.digg.com for some cool FLEX/Flash apps. Try doing that in AJAX...
...richie - It is a good day to code.
when flash stops sucking? Flash is NOT a solution. Flash is a proprietary disaster in slow motion. AJAX is not a happy thing, either, but between AJAX and Flash, I'd choose AJAX every time.
RS
Shoes for Industry. Shoes for the Dead.
The main thing I know about AJAX is the traffic nightmare it's boom has created on 680.
I've made dozens of web video streaming applications and interactive web pages and right now am working on a multi-user video conferencing app. I maintain them myself, which I know is always easier than maintaining someone else's, however, I always try to write code (any code-HTML/CSS, Actionscript, PHP) very cleanly and clearly. Anyhow, I know Flash isn't the answer to the world's problems, but I do appreciate the advances in Actionscript 3 they've made, by turning it into a full-on OO language which resembles Java in many ways. In fact, I like the clean structure of AS3 so much that I wont program in AS2 or (defintely not) AS1 anymore. Peace.
You're referring to software as a service, not Ajax. An application ran as a service by an outside vendor can hold your data hostage, whether or not it uses Ajax, and an application running within your organisation doesn't, whether or not it uses Ajax. The key is who runs the application, not whether it uses Ajax.
Bogtha Bogtha Bogtha
A lot of people don't backup their data regularly, and know that their data is probably safer on some ASP's servers than on their own hard drive.
Of course, from your comments about Goggle logging conversations being scary (this is one feature I make sure to turn on in every chat app -- it's SO damn useful to be able to bring up the text of old conversations, especially given that my memory is not what it used to be), I'm guessing what surprises you is the privacy concerns.
I suspect most people have come to grips with the fact that they aren't James Bond. I'm well aware that someone at any of the companies storing my data could read it, that the NSA has probably already scanned it, etc. If there's someone at the NSA reading everything I write, my gods, dude, I'm sorry I've got such a boring life. I feel for ya, man...
But seriously, who really cares? And why?
"Convictions are more dangerous enemies of truth than lies."
That's not mainstream. That's four global players who have figured out a way to make use of asynchronous Javascript and XML. Mainstream is when Ajax is on more than 30% of new webpages. Not going to happen.
I see few recurring themes in the questions asked, so I'll try to cover them briefly:
Q1: How do you deploy an AJAX application offline?
A1: You can use integrated HTML/CSS/JS/Flash/PDF runtime, like Adobe AIR.
Q2: How do I deliver bulky complex AJAX applications over the net, if it's a lot of code?
A2: You don't. It's not a suitable deployment model, at least until we have a simple delivery vehicle for bundling multiple app elements into a single file, such as a browser downloading and directly reading a ZIP file with collection of resources/JS files (as with Java's JAR). Until then, and for complex UI-s in general, look into established compiled solutions like Flash.
Q3: Do we need JS2.0?
A3: No, we don't (right now), since JS2 delivers benefits for larger projects only (refer to Q2 why large online JS projects are not viable). If this is resolved, then JS2 will be highly desirable.
Q4: Hand-made AJAX or AJAX framework?
Q4: Framework. Cuts development time, provides consistent code, avoid wheel reinvention (Exception: very large projects may need custom code. Are you Google? Yahoo? If not, use a framework).
Q5: Is AJAX wide-spread / easy / hard / common?
Q5: It's easy, wide-spread, and accepted. Fallback is usually present, unless the AJAX is a component of a complex online app that can't have no-JS fallback (example: rich text editor).
Q6: Do I pick AJAX or Web 1.0 / iPhone SDK ?
A6: Apply common sense. In general, when a new technology comes around, people abuse it and try to shoehorn it into replacing everything before it. Then comes the backlash ("AJAX sucks"). Only then, people settle to use said tech in moderation, co-existing versus replacing, evolution versus revolution, and solving unique problems not solved before.
It's no different, and that is the problem. Plain web applications require all the processing to be done on the server by definition. AJAX apps are still not allowed to save data locally and Javascript is not fast/powerful/scalable enough to implement significant local logic (for example to encrypt most of the data that it stores on the server). Even wrappers like GWT can not fundamentally solve poor performance, non-configurable security restrictions or lack of threading in the underlying Javascript VM.
Even if users are comfortable with hosted data, they can not be thrilled over the fact that buying a top-of-the-line quad core computer does nothing to speed up their applications. Eventually there will be a backlash and people will once again start using downloadable thick clients that communicate to the server when needed.
Java applets should have been AJAX. It's too bad that Sun had crappy UI and browser integration and Microsoft quite possibly leveraged their monopoly position to prevent Java from being widely bundled by OEMs at the critical stage in web app evolution.
You missed out
*Is designed to kill the cross-platform web
Like Active-X before it and Internet Explorer, Office, Exchange email, etc etc, what seems at first to be a useful tool will quickly turn to being a 'Works best on Windows" genuine advantage for the users involved - herding them onto a platform where everything requires a payment to Microsoft.
I'd say users have been leading towards "don't care". Of course the solution is to host your own web/app server. Then your client talks to your server and stores your data.
Javascript and HTML are for content and presentation, not processing data. That's because browsers are optomised as display platforms, because they are built to display documents. Javascript is not a programming language its a script language to allow designers to customise your display, just like CSS.
Want a customisable, interactive, client-server GUI. Code one in a real language. Use C, C++, C# or even Java, then throw an XML over HTTP client comms library in. Easy. Well easy for programmers with a little training. Not easy for script monkeys who can't code. AJAX is just a bastardisation of what was easiest for most people to build with.
AJAX is to the Web what Lego is to the building industry. Useful in its place.
We do not inherit the Earth from our parents. We borrow it from our children.
How are we to fix the web?
If I had a dollar for every time I've seen that question bandied about, I'd have at least enough money to see a matinee. Maybe even the 9pm show. Ever since the commercialization of the Web started in the late 1990s, there has been talk of "fixing" the Web. Java was going to fix it. XML was going to fix it. But nothing will "fix" the Web. It's an inherently messy environment, because of its openness. The bazaar is never as pretty as the cathedral. It's more dynamic, and it adapts to change faster, but it's always chaotic, a bit difficult to deal with, and seemingly on the verge of breaking down.
Read the EFF's Fair Use FAQ
Mr. clean has ajax by the nuts
1 radical python fanboy modded you up, good job there bud.
Flex is not the same thing as developing using Flash. Yes, the end result is a Flash based application but the way you get there is completely different. Macromedia/Adobe has done a great job of making Flex based applications as easy to develop and maintain as any other UI technology. Even going so far as to Open Source the Flex SDK. That being said, they are also charging way to much for the technologies (LifeCycle) to hook it up to Enterprise components. Although, there are some pretty good Open Source technologies (OpenAMF, Granite Data Services.
AJAX is really easy with ASP.NET, if you have version 3.5 or an older version with the AJAX Framework installed. It's as simple as a few tags. If doing AJAX (or anything else, like database connections) in PHP was as easy as ASP.NET, I would never use ASP.NET.
No, they aren't. They are absolutely useless for layout.
I wouldn't go that far... there are times when positioned/floated divs are more convenient/more powerful than a table-based layout.
That said, if the sentiment driving that statement is utter frustration with the bitter taste of the CSS-positioning kool-aid, I understand perfectly. It was absolutely the wrong idea to try and get rid of tables as a layout tool, and the fact that it's been taken up as a mantra is a problem.
Tweet, tweet.
In the beginning html is simple.
Once upon a time, Mozilla want to create a platform to develop specific clients.
Now, comes the iphone:
You want to run ajax version to edit your document on-line?
What are web-services?
Why keeping to chase fancy interface and make the more and more complicate things?
I want to ask a question: What is the platform you want to develop for the next big thing: the handheld device.
What platform you want to develop for the device that have no display?
Can ajax suit a platform for voice only or more innovative interface?
KISS! with love.
"'On what timeline will AJAX skills become commoditized like HTML skills became?'"
Well HTML is a markup language for web documents, it became "commoditized" when HTML editors appeared. Some may not like the verbosity of the output over "doing it yourself in notepad" but they made it simple for people to create documents.
AJAX stands for Asynchronous Javascript And Xml. I ignore the XML part here since we can use JSON or even a custom format in its place, but the Javascript part involves a concept called "programming". As such it will become no more "commoditized" than Perl, Ruby, C++, VB6, C#, VB.NET or Java etc etc.
Not sure what you mean here. Javascript is more than fast enough to implement a stream cipher like RC4. Meebo, for example, encrypts your password rather than using SSL to connect. (An SSL server *is* available, but they ask people to only use it if absolutely necessary due to the high server load.) Having implemented several ciphers in Javascript, I'm not really sure what you're getting at here.
Here's a few cipher implementations: http://shop-js.sourceforge.net/crypto.htm
And here's a cool video game: http://java.dnsalias.com/tetris/ie/
(^^ Java required for those foolish enough to use Internet Explorer. MWHAHAHA! Oh, and click outside the block-dropping area before starting on IE. The Applet shunt for the CANVAS tag doesn't handle keypresses correctly yet.)
That's true. But not because Javascript is slow. Because your applications are only as fast as the network. And if the network is slow, the fastest processor in the world won't help you. On the other hand, I've seen webapps that are amazingly zippy when the server has low latency and fast response times.
Javascript + Nintendo DSi = DSiCade
No offense is intended, sir, but your comment reeks of inexperience. Javascript is far more capable than you give it credit for. And I say that as someone who's coded a variety of applications (including client/server) for well over a decade, in a variety of different languages. The number one problem I've found in Javascript critics? They have no idea how to actually code in the language. They don't understand that it's object oriented, they haven't given more than a cursory glance to the W3C specs, and they are blissfully unaware of where the WHATWG is taking HTML applications.
Want a customisable, interactive, client-server GUI. Code one in a real language. Like Javascript. If you know what you're doing, you'll actually find it a LOT easier than writing a comparable C, C++, C#, or Java GUI.
Oh, and Javascript was NOT designed as a "display customization language". It was originally designed to script (drumroll please...) Java. As in Java, Java. Not Java Applets (though that was included in the spec), but straight-up, plain-Jane, gosh-darn-that-looks-like-semantically-funny-Java Java. Mozilla still supports the full Livescript API in case you want to play around at some point.
Javascript + Nintendo DSi = DSiCade
I normally support sites by not visiting 'print' optimized pages (usually linked on digg) and going to their normal, ad-supported ones. After all, it sounded like an interesting article. But that site was just ridiculously ad-ridden and designed horrendously (not to mention being coded in tables...).
..?
And after that, it calls itself "The World's Leading Resource For Rich Web Technologies!"
-
The concurrency model is lame and buggy. Open Google Maps in Firefox 2. Roll the mouse wheel rapidly to zoom in and out. Watch the maps break up as the browser gets out of sync with the server and doesn't properly repair the window damage. It's like a window system from 1990 or so.
-
Firewalls and AJAX still don't play well together. Rewriting JavaScript source in the firewall is not the answer.
-
The conflicts between cross-site scripting, mashups, and security illustrate that Javascript's security model is inadequate.
-
The JSON concept opens security holes. JavaScript has the wrong primitives. In LISP, there's the reader, which takes in a string and turns it into an S-expression, and there's "eval", which executes an S-expression. In JavaScript, there's only "eval", which takes a string and runs it. Oops. Not the right tool for marshalling.
JavaScript itself isn't that bad a language, though. It's the integration with browsers that's not good enough.Flash has probably the worst dev environment I have ever used. Not a promoter, but Microsoft Silverlight 2.0 is just going to blow it out of the water. Microsoft is much better at building development tools than Adobe+Macromedia. Sun had the right idea with Java applets ten years ago but never fixed/upgraded the technology (slow, even today). Now there is some action on their part, most likely way too late.
That being said, I wouldn't use any of these tools for an internet facing website at this point in time, for internal intranet/extranet corporate apps yes, but not for use by the general public.
...in Internet Explorer. GlobalStorage works fine in FireFox. It's even a standard to boot.
The whole/only purpose of AJAX is to have your app work in IE6/IE7 without installing any plugins not bundled with the OS. If you require an extra download of Firefox, you might as well ask people to download Java or a regular native app which much better UI and performance.
Javascript is more than fast enough to implement a stream cipher like RC4. Meebo, for example, encrypts your password rather than using SSL to connect.
Oh, I have no doubt you can encrypt your password. Just try to encrypt the whole online word processing document with many images before saving it to hosted storage space. Oh, and RC4 is not a pinnacle of security.
On the other hand, I've seen webapps that are amazingly zippy when the server has low latency and fast response times.
Perhaps more people can invest in zippy servers if clients do 90% of the processing, cache all received data and changes and just connect to synchronize once an hour.
Not exactly true. Javascript was not invented to be a scripting environment for Java. It wasn't named Javascript initially and the syntax is similar to C just as Java syntax is similar to C. In fact the name Javascript was more of a marketing ploy than anything else. Javascript was developed by a Netscape engineer and indeed seems to be invented for the purpose of web-based scripting, not Java scripting.
Time makes more converts than reason
Assuming you're experienced with html forms, basically you're generating http requests from javascript and 'inserting' the results into a html tag that supports innerHTML . div tags seem to be the most commonly used tags. div tags are very powerful, when combined with css (commonly the display attribute) they can be used for many of the various ajax effects you're already familiar with as well. The main point of ajax is saving pixels and that the page should never have to refresh/reload. So if you're already an experienced web developer it's really just a matter of making the switch to submitting forms in javascript, a lot of other stuff goes with that being said tho. Also, if you think about it in it's rawest form, think about an http request; it has stages, which means it needs a handler function. There are 4 stages to a http request. The handler function is basically a callback. So as the http request progress, it is progressing stages (or changing state).
Here's some code:
do ajax(url,elementId);
function GetXmlHttpObject(handler) {
var objXmlHttp=null;
if (navigator.userAgent.indexOf("MSIE")>=0) {
var strName="Msxml2.XMLHTTP";
if (navigator.appVersion.indexOf("MSIE 5.5")>=0) {
strName="Microsoft.XMLHTTP";
}
try {
objXmlHttp=new ActiveXObject(strName);
objXmlHttp.onreadystatechange=handler;
return objXmlHttp;
} catch(e) {
alert("Error. Scripting for ActiveX might be disabled");
return;
}
}
if (navigator.userAgent.indexOf("Mozilla")>=0) {
objXmlHttp=new XMLHttpRequest();
objXmlHttp.onload=handler;
objXmlHttp.onerror=handler;
return objXmlHttp;
}
}
var lastDIV="";
function ajax(nurl,ndiv) {
lastDIV = ndiv;
var url="" + nurl + "";
xmlHttp=GetXmlHttpObject(stateChanged);
xmlHttp.open("GET", url , true);
xmlHttp.send(null);
}
function stateChanged() {
var divname=""+lastDIV;
if (xmlHttp.readyState==4 || xmlHttp.readyState=="complete") {
document.getElementById(divname).innerHTML=xmlHttp.responseText;
}
}
I see linux has all the compiler switches for "encryption cards". Aren't these designed to speed up SSL sessions? Does anybody use them?
Just curious. I always thought there was some kind of hardware trick you could pull if everything you do is SSL.
Please check thy facts, kind sir. Javascript was conceived of as a Java-like script language. A poor man's Java for those that found object oriented concepts a little too brain intensive. Thrown in the first netscape browser to allow a little customisation of the DOM on the fly, for things that then then HTML 3 couldn't do properly.
Javascript is not an object oriented language. It is at best what can be called object-based, but then anything that uses "objects" can make that claim. There is no polymorphesm or inheritance, strong type checking, nor even much encapsulation. Its all function based monolithic code. And even if javascript, per se, is capable of the above, examples of such are very, very rare indeed.
As for the W3C specs, they aren't worth that much as most of the javascript interpretors - aka browsers - haven't given much more of a cursory glance at them either. No point writing code to spec if the interpretor won't run the code in the same way. At least Sun managed to force JVMs to be written to a more standard standard.
My brother builds model planes in his spare time. According to your Javascript defence guess he can call himself an "Aircraft Engineer" now. Everytime I see recruitment ads for "HTML / Javascript Programmer" I kack myself. Well, at least it leaves the real programming jobs for those of us that can.
We do not inherit the Earth from our parents. We borrow it from our children.
"When will AJAX development finally be easy?"
Shortly after developing the same app for a traditional desktop becomes easy. If you want to write a spreadsheet app, the problems are the same whether you're building the interface with AJAX or Win32 or Java or QT.
0 1 - just my two bits
You can actually get away with inheritance using the prototyping model inherent in Javascript's "object based" programming model. There are some other strange and unusual things that can be done based on prototypes as well, like adding properties to an object or set of objects at runtime. The parent has a limited point, I would agree that Javascript is a "real" programming language as such things go. The problem in my experience is twofold. As you mentioned, the first is with inconsistent JS DOM implementations between browsers. The second is the kludgy syntax and these sorts of "hacks" to make objects try to work like they do in other languages. The C-like syntax is nice as most people are familiar with it but there's nothing I hate more than programming in javascript.
On what timeline will AJAX skills become commoditized like HTML skills became?
When you don't need to know fifty languages to make it all work.
The higher the technology, the sharper that two-edged sword.
Now why does slashdot eat my tags when I post as Plain Old Text?
Because nobody fed the Trolls today.
The higher the technology, the sharper that two-edged sword.
You may be surprised to know that I am well in possession of the facts. I used to believe that Javascript (formerly Livescript, formerly Mocha) got its name in simply a cross-branding deal. In fact, it was far more complex than that. Javascript was created to script Java as well as the DOM. The original concept would have blown today's AJAX out of the water in usability. Alas, it was not to be.
Here's more history for you: http://safari.oreilly.com/0768666775/ch01lev1sec1
Also, here's a bit of Javascript for you, demonstrating how powerful it was intended to be:
(That will work in FireFox with a recent Java plugin. I guarantee that it will not work on Internet Explorer.)
;)
You have to remember, Java already existed in the browser when Javascript was created. Netscape internally discussed just using Java itself for scripting, but decided that a new, more dynamic scripting language would be more useful. (Source) Thus the birth of Javascript. Eich described the first revision as "having gotten out of the lab a bit earlier than intended". Javascript 1.1 was much closer to his vision, and what we think of today when we talk about Javascript.
You also need to understand that the Javascript language went beyond just the browser. Much of its development was driven by its use as a server-side CGI language. So it became a "real" language very quickly, despite its slow start.
And if you think that's cool, remind me sometime to tell you about how multipart/x-mixed-replace could have been server-side push long before AJAX, Comet, or <event-source> ever existed.
Incorrect. Prototype-based languages are very much OO languages. They're different from class-based, languages, but that doesn't make them any less powerful.
I think you misunderstand the very meaning of polymorphism if you believe that.
Here's the "Runnable" interface implemented in Javascript:
The polymorphism appears to work fine?
Funny, Netscape's Client Guide has an entire chapter on that.
Strong typing is not a OOP requirement. It is a feature of some languages. Nothing more, nothing less. In any case, Javascript actually has quite a few typing fe
Javascript + Nintendo DSi = DSiCade
There's a lot of confusion over the origins of Javascript, but it basically went like this:
Self Java -> Mocha -> Livescript -> Javascript
Brendan Eich practically never talks about the Self Java/Mocha days of Javascript. Not all that many people even remember the working title "Mocha". (Implying its early relationship to Java.) Scripting of Java was the goal in those revisions. Javascript 1.0 was kicked out the door incomplete, but 1.1 addressed the initial issues. The JavaClass and Package objects were added, and it became possible to run Java code without an Applet. It was pretty darn nifty, and still can be if you have Firefox with a Java plugin. (See my response lower in the thread for more info.)
The branding concept was stupid, but there was solid reasoning behind it. And it was more than just because Netscape and Sun were partners.
Javascript + Nintendo DSi = DSiCade
Microsoft will cripple JavaScript on Internet Explorer if AJAX cuts heavily into Windows- or MS-centric GUI technology. This is the main reason I don't put much stock in AJAX. But I agree a real GUI-over-HTTP standard is sorely needed.
Table-ized A.I.
U SUX0RZ B1@TCH
Uhhh, no. The point of AJAX is to deliver rich applications over the internet through a standard delivery mechanism. Installing software is not network delivery of an application. Webapps generally provide a true network delivery of an application, but AJAX is a part of a toolkit that provides for a far richer set of applications delivered over the 'net.
I don't require the download of Firefox. Most of my apps require the use of a browser that meets standards. Which IE is failing to do. For that, the market should reject it. The sooner that pushes down to the customer level, the better. (IE is slowly dieing. I can't wait until it finally dies off altogether.) That being said, I make a rather huge effort to provide Javascript shunts to dynamically patch IE to the latest standards. Need CANVAS? Use the Google VML widget. No installation, just include the JS file. Need GlobalStorage? Create a hidden Flash component and map to the API to provide that exact functionality through SharedObjects. (Flash is bundled, so there's no installing extra components.) Need DOM2 Events? Patch the event system to wrap addEventListener around Microsoft's proprietary attachEvent. Need SVG? Use Javascript to render it through the VML system.
The key to these solutions is that they are forcing IE to be compatible with the standards, but in a way that's transparent to the user. It's a sucky solution when compared with getting Microsoft to fix their %$$#@ browser, but it's a forward compatible solution should Microsoft ever pull their head out.
I have done this sort of thing. It really is not that bad. You won't find any production implementations of it, though, because that's what SSL is for. Additional security is simply paranoia and does not increase security to any appreciable degree.
No one said it was. However, it works well enough for any situation you need a stream cipher for. If you need a block cipher or asymmetric encryption (been there, done that, what a major PITA), feel free to implement it. It will be slower than a native implemenation, but not so slow as to be unusable. (Assuming that the encryption you're using would be "usable" in *any* language.) Your example of "saving a document" might require a "Saving..." dialog for a few seconds, but that would probably be there regardless of the encryption.
That is the goal, actually. The richer AJAX applications become, the less bandwidth and server-CPU intensive they become. Which makes it easier to provide low-latency results to clients. Of course, a badly designed AJAX app can do the exact opposite, so it's not a panacea.
Javascript + Nintendo DSi = DSiCade
I am kind of curious about your understanding of standards. Microsoft implemented Javascript with full DOM access at the time Netscape Navigator had rather limited and tedious Javascript support. Now a bunch of folks came together and declared that Microsoft got it all wrong and has to re-implement its browser with 80% market share to conform to minority's opinion of how a web browser should behave. I say punish Microsoft for illegal use of its monopoly power, but otherwise let critics develop their own software and let the best program win.
I don't think the last part will be easy for standard XHTML+CSS+Javascript. The thing is, IE's implementation is enough to add some animations to a home page or add some form validation for a shopping site. On the other hand, even the standard is a lousy platform for writing apps that actually do something significant on the client side. Java+SWT+a security manager could be a step forward for that, but a really solution should support a free choice of languages and UI toolkits. Perhaps instantly created virtual machines that provide native performance but still maintain security is the answer.
while it's not the most difficult thing to use it can be quite frustrating.
mostly cause of J in ajax. Javscript can be a nightmare to use. I never know if a certain javascript will work on all browsers or even all versions of a certain browser. Most frameworks have solved this by have different code for different browsers, which is another thing I don't like about AJAX, very messy code.
AJAX is not unusable but it requires (or even demands) a very organized approach from the developer side, something that is not always easy if you are working on tight deadlines.
If you want to use AJAX, sit down and think about it, understand what it is, because AJAX (again mostly due to Javascript) can produce some of the most unusual and frustrating bugs. Which are usually easy to fix, but at times almost impossible to find.
HTML is simply too convoluted for application development.
Html is not the problem. The differing javascript APIs the browsers offer is the biggie,
and secondly the roundabout way you have to use to get from server response to a change in page state. And he of course CSS is just bananas even if implemented correctly and consistently, which it never is.
sudo ergo sum
The thing that surprises me is that somehow, people seem to think that javascript is a nice language to write software with. It's an atrocity! It's a scripting language at best! Years ago, we had java applets, and now, somehow, people have decided that javascript is a better way to write a spreadsheet program? That's maddness! It was never meant to do that. I bet these AJAX apps are full of dirty hacks to get around the language's limitations.
"It's too bad that stupidity isn't painful." - Anton LaVey
Anyway, "wanted"... Now, comes the iphone: So? You want to run ajax version to edit your document on-line? Why do you care? And anyway, "ajax version" what? What are web-services? Try Wikipedia, ignorant. Why keeping to chase fancy interface and make the more and more complicate things? Why chasing fancy web page write with English is not Ok and complicated text? I want to ask a question: What is the platform you want to develop for the next big thing: the handheld device. Two colons, up my colon! Anyway, do you really care what platform I'll choose to develop the "next big thing"? What platform you want to develop for the device that have no display? Why are you asking these questions? Do you even want answers, or just write weird shit on
'How are we to fix the web?'
Replace HTML with a real programming language which includes security and distributed computing primitives, and you're done.
Correct. And what happened to Netscape's market share?
I hardly think that a "minority" of the development community are the ones mad at Microsoft. Anyone who has used IE to any appreciable degree is mad at them. When 5.0 came out back in '99, it was incredible. The best browser, bar none. Microsoft released a fairly insignificant update called 6.0 in '01 and that was where the browser sat. For about 5 years. Then when everyone had almost given up hope that Microsoft would keep developing their browser, they announced 7.0. They also announced how they were going to meet W3C standards and make developer's lives better. 7.0 came out, and it turns out that Microsoft couldn't even be bothered to add support for simple things like DOM2 Events or SVG. (Things which they effectively already had support for, just in a proprietary-yet-not-quite-dislike manner.) In reality, they stamped out a few CSS bugs, screwed up the IE interface, then developed a new certificate scheme that was practically the same as the old one but made more money for all involved.
The funny thing is, the only reason why IE hasn't died out is aforementioned monopoly power. I have met very few users who prefer IE over Firefox or Safari. However, I have met managers who force the use of IE (thus leaving themselves vulnerable to IE's massive security holes) for the purpose of 100% Microsoft "corporate standards". As a result, IE has lost market share in the home computer segment, but is not taking any losses in the B2B arena. And it's NOT because it's a good product.
Javascript + Nintendo DSi = DSiCade
This is *not* a good thing for American Web developers. They tried this with technical support, and while it worked well in some cases, it was a complete disaster in others. Not to mention the fact that you can't save as much money by outsourcing these days, due to the dwindling/more expensive supply versus increased demand.
I've talked to some very talented Indian developers and tech support reps. I've worked with some extremely competent IT workers from Bangalore. As demand rises, these high-quality workers will become scarcer/more expensive. It gets to the point where the extra overhead/infrastructure and annoyed customers isn't worth putting your own employees out of work.. not to mention when they lose their houses it aggravates the crisis in the housing industry.
Never underestimate the power of stupid people in large groups.
Thank you.
I learned something new today, always the best way to start a day.
Javascript + Nintendo DSi = DSiCade
(This post is a dupe, but it seems appropriate here, and I don't think many people have read the original.)
HTML was a great way to get things up and going back in the day, but we have reasons to move on. Moreover, I think we have a good way forward.
One of the problems with HTML is that it tries to be too many things at once. One, a semantic representation of data. Two, a page structure in which to present the data. Three, a description of how to render the data (this has been downplayed, but the fact to the matter is that tags like i and u still exist). It falls short on all three, and there is so much legacy code and mini-languages that writing a web browser is a total pain. So I really don't believe in HTML for the future.
Instead, I believe in a more rigid approach. Data formats that are simple and easy to parse, without all the exceptions and special cases that are in HTML. No more mixing of semantics and presentation. Different jobs, different tools.
So here is the proposal. For every kind of data, we invent a mini-language, specifically for that kind of data. It will have all the elements needed to represent data of that kind, and nothing else. These mini-languages can be standardized, but they don't have to be.
One such mini-language will be a presentation language. This one will be standardized, and it will be what "viewers" will implement. It will be a language with everything needed to make proper interfaces to information; formatted text, graphics, GUI widgets, the lot.
To add interactivity to the presentation, and possibly to perform the transformation from the semantic language(s) to the presentation language, there must be a programming language, which must also be standardized, as it will be run by viewers.
Now we have everything we need. A semantic language for representing data, without any presentation junk. A presentation language for _presenting_ data, without any semantic junk. And a way to transform data into presentation.
To ease the transformation from semantic language to presentation language, it would probably help if both used the same syntax. I would like it to be lightweight, perhaps s-expressions, but I could live with XML. As for the programming language, I am sure everybody has their favorites. ECMAScript would be one of the candidates. And there is no reason we couldn't have more than one of each language.
I think, technically, all challenges have been solved. The problem will be getting things adopted. I foresee endless debating about which languages should be in the standard, large corporations baking their own, and lots of people arguing in favor of just using an existing proprietary solution that accomplishes the same task. In the meantime, developers will keep plodding along with HTML.
Please correct me if I got my facts wrong.
AJAX Solitaire has come a LONG way too, as shown here: http://worldofsolitaire.com/
First, never ask the "experts" what questions you should be asking.
ASP.NET alone was enough to slow the adoption of the AJAX technique at the last firm I worked at. ASP.NET uses a component framework where every page is a form that uses POST DATA to maintain page state. Being bound to a framework that works like that makes AJAX development difficult if not awkward. Once Microsoft created an AJAX library for .NET we were able to start slowly adopting the AJAX method but it mostly happened on new websites.
ajax seems like a doomed technology. well, there are few good ajax application out there (gmail etc), but as a mainstream it is doomed. it falls somewhere between html and adobe flex (and possibly silverlight). it departs from pure html world but never arrives to what flex is capable of. ajax loses the simplicity of html, becomes slow and awkward and tied up by by legacy standards. why would one use it then? only monsters like google who can trow tons of money into building and using their own obscure development kits (i remember looking into google web toolkit, first thing that crossed my mind "what the fuck is that??! why all this hustle??"). i ran into client once who had invested into an ajax financial application. this application was a total disaster and perfect example of how developers high on technology drive project into the ground. site was slow, ugly and unusable. so we ended up rewriting it in flex at a fraction of original cost.
AJAX has two sides (assuming well developed code)
The user experience is awesome on a good site. AJAX apps look mostly as usable as any local desktop app and it generally works.
For the developer (and I speak as a hobbyist who taught themselves HTML in an evening in 1994, and can code some crappy PHP when pushed) is an arse tiring pile of dog mess.
HTML was simple to learn, did pretty amazing stuff with bugger all skill required, but wasn't quite as elegant to look at as all this XHTML+PHP+Javascript+Java+whatever-the-f***-is-the-latest-craze.
Too many technologies held together with string and gaffa tape is the usual approach boffins use to lock out non-boffins, and create artificial elites.
So, combine the user experience of AJAX, with the boffin factor of the developer experience, and how that boffin factor is used to lock out ordinary people, AJAX is here to stay.
"I hope you like Guinness, Sir. I find it a refreshing substitute for, er... food." Col. Jack O'Neil, SG-1
No, it's not pedantry. This isn't merely a case of wrong terminology, it's a sign that a developer is looking at something in a completely upside-down way.
You'll have to expound at length on what the correct philosophy a person who uses that terminology is missing, then, because I don't see it. My experience suggests the terminology is a poor test of whether a dev is doing so as an imprecise shorthand for CSS positioning or because they haven't realized that one can do CSS-positioned layout on elements other than divs. In fact, my experience suggests there are *very* few devs in that latter category.
And to be a little pedantic myself, it's also technically wrong to suggest that the div tag has no layout value... any block-level element does, even if it's not much.
Tweet, tweet.
I have met an problem Ajax make the browser work with more and more trouble. compare it when you use ajax and don't use ajax, and the browser have a high per to shutdown with ajax. so the browser may be a common client(linked to the c/s model), it do too much for us. it seems strange, and i think something will appear to solve this problem
Javascript is influenced by Self. Java is not. Java is very different from Self and Javascript.
Time makes more converts than reason
"Self Java" was a language that Mr. Eich worked on that allowed scripting of Java using Self syntax. That is about the sum of what I know about it.
Javascript + Nintendo DSi = DSiCade
The thin client approach is good, because it practically removes one tier from the architecture. Programming with multiple fat tiers is a mess, but programming with a thin client is very similar to programming single-tier desktop applications. Well, plus plus database tier, etc.
For example, IT Mill Tookit (http://www.itmill.com/) uses AJAX simply to turn the browser into a thin client or a terminal. The UI logic runs in the server-side in a Java servlet, with the thin client tier just passing most of UI events to the server. Only some very trivial logic that is usually not specific to the application is done in the client. The application development model is so simple that this approach is really the future of AJAX.
Doing big AJAX applications is not practical with JavaScript. You would need to do both client and server development, handle communications, and do that in two different languages.
Take the approach of IT Mill Toolkit, for example. You don't need to see a line of JavaScript. Actually, you don't need to code anything on the browser, but all the UI logic is done in the server-side application. The JavaScript running on the browser simply turns it to a thin client that does some trivial user interaction in the browser and forwards most of user events to the server-side application. And if you need some custom client-side stuff, you program it in Java with Google Web Toolkit (GWT).
Disclaimer: I work for the company.