Slashdot Mirror
Bosworth On Why AJAX Failed, Then Succeeded
An anonymous reader writes "eWeek has a story describing a talk by former Microsoft developer Adam Bosworth, now a VP at Google, entitled 'Physics, Speed and Psychology: What Works and What Doesn't in Software, and Why.' Bosworth depicts issues with processing, broadband, natural language, and human behavior; and he dishes on Microsoft." Quoting: "'Back in '96-'97, me and a group of people... helped build stuff that these days is called AJAX,' Bosworth said. 'We sat down and took a hard look at what was going to happen with the Internet and we concluded, in the face of unyielding opposition and animosity from virtually every senior person at Microsoft, that the thick client was on its way out and it was going to be replaced by browser-based apps. Saying this at Microsoft back in '96 was roughly equivalent to wandering around in a fire wearing matches,' he said. 'But we concluded we should go and build this thing. And we put all this stuff together so people could build thin-client applications... Now you hear about AJAX all the time, but this was built in '97,' Bosworth said. Yet, AJAX failed for a variety of reasons, including some 'big mistakes.'"
It was a browser standards issue...it didn't work the same for everyone a few versions ago, now it is fairly consistant.
The government can't save you.
And we put all this stuff together so people could build thin-client applications... Now you hear about AJAX all the time, but this was built in '97,' Bosworth said.
I hear that this guy also invented the internet.
The theory of relativity doesn't work right in Arkansas.
Yep, I created an AJAX-like system as a pet-project in my high school web design course (boredom++) back in about 2000. I'm not sure if "AJAX" had really taken off by that point, but for fun, I decided to use JS to load remote pages, particularly of the scripted variety.
Ironically, I got a D- on my final project, which was a self-updating news feed reader (pulled XML news feeds from a few sites), because it "wasn't very user friendly."
... it has a name that people can easily refer to and brand as a technology. I'd seen/used AJAX implementations before, but now I have something to put on my resume. Simple as that.
"The need to build the internet comes from something inside us, something programmed... something we can't resist."
I apologize for being a grammar Nazi but I just could not help myself.
I think the invisible hand of the market has its middle finger extended
--A wise old fart named SC0RN
Having been there working on Asynchronous XML request long before the term AJAX was dreamt up I can tell you that it was just a bandaid for the plague that is browser applications, and still is to this day. The only thing AJAX has succeeded at is keeping the belief going that browser applications are a viable solution. The more we add to the web browser and the more dynamic and complex our client side scripting becomes the more we head toward having application clients and dumb terminals rather than PCs with Browsers. I only hope that someone with the influence to change things figures this out and stops this web based madness. There are other, better, solutions to the client server paradigm.
In Soviet Russia, AJAX succeeded, then failed.
AJAX is still failing for me, you insensitive clod.
Yeah, but does AJAX run Linux?
1. Invent AJAX at Microsoft
2. Use AJAX at Google
3. ???
4. PROFIT!!!
Ajax is still failing. Netcraft confirms it.
I, for one, welcome our new AJAX-inventing overlords.
Imagine AJAX naked, petrified, and covered in hot grits.
AJAX must be new here...
mod parent up
I implemented an app that recorded all of the browsing and events in a frame that generated Javascript to re-play the browsing session to a hidden frame and saved the script via a Java Applet that connected to a Servlet like java program on the server way before XMLHTTPRequest existed. Java Applets can provide even better functionality, but unfortunately no one seems to be able to develop responsive, multithreaded applets in AWT for any browser, hence applets gained the reputation of being sluggish and unresponsive.
What do real sites like myspace and suicidegirls use?
So, contextualizing the story a little:
Microsoft embraces and extends*.
One day, by mistake, Microsoft creates something new.
Microsoft then proceed to bury the mistake until the folks of Mozilla discover and implement it.
Having become a competing technology Microsoft embraces it and AJAX becomes a success.
* Bill's wife is in fact from soviet russia. She embraces and "extends" him.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
It doesn't seem to hard to be a Microsoft rebel. Oh, and Microsoft even - wow!
I predict that 90% of the comments here will be people saying the use AJAX things in the 1990s too.
People seem to constantly suggest that the future is either with thin clients or with thick clients, but they never really explain why.
I think this is a false dichotomy. Thin clients and thick clients each have their uses. Thin clients are great as some things (deployment, maintenance, cross-platform capabilities, client security, etc.), where as thick clients are great at others (leveraging the local machine, UI flexibility, speed, privacy, etc.)
The successful applications utilizing AJAX are those applications which really don't need to the capabilities of the local machine. Those that try to do what a local app is much better at are doomed to fail, at least for the time being. (AJAX office suites, for instance.)
I see the line between these two kinds of applications slowly but surely blurring. I really doubt that HTTP/Javascript/XML will take us a whole lot further than we're seeing now. It just wasn't meant for this kinda stuff. While the various implementations of "rich" web applications are quite ingenious, they're hacks, and hacks can only take you so far.
Instead, I see HTTP and the browser being the primarily delivery mechanism for rich applications running inside a sandbox on the client. Essentially the Java model, but done right. (And, perhaps more accurately, done at the right *time*.)
You can see the beginnings of this with technologies like XUL, ClickOnce, XAML, XBAP, and WPF/E.
It's just a matter of time before these things catch on.
The main problem was the browser support.Yes, I had it working in both IE and Netscape. But at that time IE 4.0 was still quite popular, and good luck making any AJAX (or even pseudo-AJAX) working there.
Ten years ago the web/HTML/HTTP concept was still based on request/response/full reoundtrip for each page, as it was originally concieved. DOM was not a standard (or at least was a standard on paper only), and using a browser as a thin client was not much better than developing a thick client - either you stick to a particular version of a particular vendor (a corporate application), or you go Java applet/activeX route which is essentially a thick client.
Both browser performance and network bandwidth are an excuse for bad design and poor coding. If done right, AJAX apps can use even less bandwidth, then a traditional full page refresh.
Bottom line - once the mainsteam browsers started to provide a decent and more or less uniform DOM support and other features like XMLHTTPRequest (although the latter was not really critical, but rather a convinient shortcut) - AJAX became feasible on the large scale.
I'm still waiting for AJAX to take off.
Try putting 100 users of said web app on your network and watch your traffic surge.
In a band? Use WheresTheGig for free.
...but Melinda Gates was born and raised in Texas. http://en.wikipedia.org/wiki/Melinda_Gates
"...then I'm happy and sad for it"
Sit, Ubuntu, sit. Good dog.
Most people agree that AJAX is a silly acronym. (I personally think DHTML is much sillier). Let's examine it.
Javascript can do a lot, but it wasn't originally designed for heavy application logic. Without getting redesigned to allow it to used outside the browser or web server, I believe Javascript will become a limitation for "AJAX" eventually.
Also, the folks at Mozilla have plans to allow application developers using Gecko to completely sidestep javascript with other scripting languages, the first being Python:
<script type="text/python">
When this happens, will we see a new "technology" called APAX? Embedded scripting with Ruby begets ARAX? When does it end? Or does AJAX become an umbrella term like LAMP?
"And" is only there to make the name pronounceable. It also just happens to leave us with a somewhat familiar word.
XML here implies that you can only work with XML formatted data, which is not the case. XMLHTTPRequest also maintains a copy of the response as plain text, so it's just as easy to work with CSV, for example. Except there's no CSV parser built into Javascript.
AJAX is a silly name, but we're probably stuck with it.
I've already mentioned this in another comment, but Adobe Flex is here today and lets you build Rich Internet Applications that compile down to SWF files that run on Flash Player 9. Unlike all the other technologies you've mentioned, Flash Player 9 will work on the majority of systems and browsers out there today.
What the fuck is a resume?
Are you doing something wrong if you got to sell yourself?
People buy me, like a pro
Ironically, AJAX should arguably be most useful for people with slow internet connections, as it allows one to send small chunks of data without reloading an entire web page.
But often, the apps which use AJAX are also using big graphics and video, cumbersome libraries and other bling that require high bandwidth to be enjoyable.
I find your use of the term Nazi in a prerogative sense offensive
Nazis are people too, just remember that
Huh?
Graphics can be disabled too. Are they only useful for toys?
Heck, I can telnet into a host and issue the HTTP request myself. HTML rendering can be disabled too. Is HTML only useful for toys?
If there's an application that needs Javascript, then the user will turn on Javascript or go somewhere else. If you don't care about the latter response, or if there's no alternative, then Javascript is a fine solution. The problem with "Javascript can be turned off" is if you don't take this into account for problems like security and validation. If not having it enabled can affect OTHER people, your program's designed wrong; if it only affects the person who doesn't have it enabled, that's fine.
Ditch HTTP and use XMPP.
"Ten years ago the web/HTML/HTTP concept was still based on request/response/full reoundtrip for each page, as it was originally concieved."
/>
Ten years ago we had frames and we still have them now. Although not that pretty as AJAX, they were used to reload only parts of the web page. The <iframe> tag is more common than ever these days.
Frames are easy to understand and they don't require any programming skills. I keep wondering why the W3C comission didn't extend this frame model for more HTML elements. Just read the following 'could have been' HTML code, no programming involved, and imagine the AJAX code you have to write to get such an effect:
<div id="container">
<div id="left_column">
<a href="some_page.php?id=1" target="right_column">link 1</a><br
<a href="some_page.php?id=2" target="right_column">link 2</a>
</div>
<div id="right_column"></div>
</div>
But no sir! They even had to remove the target attribute from XHTML Strict! Notice how my code would have been XHTML+CSS valid without this restriction that makes me write more hacks (rel="external" and an ugly JS to add the target attributes on page load).
Nobody in their right minds runs random Java applets or activeX controls off the web, the same should be true of javascript. The hand-waving about AJAX ignores the fact that not all clients fully implement the W3C DOM or scripting. Every time it's mentioned, graceful degradation is brought up but that's crap because it relies on developers most of whom do not write documents that degrade. Nobody wants to be writing large apps in javascript and neither was HTTP designed for the current crop of "we can do it in the browser" kludges. That leaves easy cross-platform deployment as the only thing AJAX has going for it.
What the AJAX thing shows is that the time has finally come for Java.
You cannot (consistently) bookmark a framed site, you cannot correctly print it, just to mention a few. Remember, I am not talking about "web applications", just simple sites with a navigation on the left and content on the right.
What you are asking for is a "nice to have" for applications (I would not mind having it that way, by the way, dojo toolkit provides something like that relatively inexpensively), the problem is that it encourages building those "frameset" pages.
AJAX is not for your regular "content centric" pages, although it may enhance them. And yes, I agree, you can do "AJAX" with just frames/iframes (that's how everybody was doing it before XMLHTTPRequest). That was not the point. It was DOM support that did not let AJAX to take off, and frames would not help you here.
Niiiiice. I'm pretty sure that is NOT how you spell nice! ;)
music lover since 1969
What the heck are you talking about? What is it that you're saying you should be able to do with this HTML that you can't do with frames in the same amount of code?
But besides the first point's incomprehensibility, the second point:
...is ridiculous. If you need the target attribute so badly, use HTML 4.0 Transitional or xhtml 1.0 Transitional. No problems. Better yet, if you're using frames, why not use the right doctype in the first place? iframes and target attributes are alive and well in xhtml 1.0 Frameset...
I can't find the talk on Google Video, and now I'm all pissed off.
Kudos to Google for raising my expectations this high, I guess.
Here is Ajax.
The rest are immitators.
Well, considering his sentiment is completely wrong, where does that leave you?
Let me tell you a short (but not so funny for me at the moment) story that happened two days ago when an saved me. Not my life, but a lot of trouble for sure.. I had to write an administration module for a website using PHP & MySQL. It was a trivial task to do the usual stuff (add, modify, delete entries). After that I had to develop an image gallery for the admin, with file uploading. An easy task which became a pain when I realised that I did not have permissions to write from PHP to any folder and I couldn't change the folder permissions by FTP on the server (I'll call it the "nasty server" from now on). No way to get to the nasty server administrator, so after some hours lost trying to guess by remote the admin password I had this idea: "but wait, I can copy, delete and modify files by FTP". I tried to FTP from PHP on the same machine but I quickly realized that I can't read the files from the temporary upload folder. I was dissapointed again. Later that night I remembered that I have access to another server (on another domain) where all the permissions are OK, I can upload files and go from there by FTP to the nasty server. So I wrote a little PHP script on the good server that made this "upload interface". How could I have included this file in the administration interface, other way than using an ? I don't know. With AJAX, no rights to load that script from another domain. the only Javascript used was to update the parent window to show the pictures after the file upload. I think that framesets are ugly, very hard to maintain, I had to convert a 12 (TWELVE!!!) frames website to XHTML+CSS and this task was a pain. But there are moments when they are the easiest and fastest way of doing something, and maybe even the only way. Extending their good things as I said in my first comment would have been a nice idea years ago. You could have changed elements from the web page with the "target" attribute just like with the .innerHTML property. I am a dreamer...
...are belong to us.
Adobe Flex is $750. The Gecko/XUL business is free. I don't know about the Microsoft stuff.
I was describing my (X^2)HTML vision and the particular case I have presented is heavily done these days using Javascript.
You shouldn't have resumed to the basic 2-column layout in the example, but to imagine the possibility to change more HTML elements content without using Javascript.
I'm not saying to replace Javascript everywhere, only in this kind of situation (let's call it the "innerHTML" case, maybe you'll get my point).
You could have done this using a mark-up language, not a programming language!
The Microsoft stuff is all free as well. All of it runs on either .NET 2.0 (ClickOnce), or .NET 3.0.
.NET is not on a large number of clients at this point. (Although that's changing quickly.) Windows Server 2003 was the first version of Windows to come with .NET pre-installed. Vista continues that trend.
But, as the previous poster mentioned,
Of course, this doesn't really help people targeting more than Windows. Mono helps that a bit.
AJAX, that's the thing that makes my PC freeze for 45 seconds every time I load a /. article, right?
The Flex IDE and the Charting package is US$750, the Flex SDK which includes the command line MXML -> SWF compiler and the whole component library (ie. UI controls, RPC, everything else) is a free download from Adobe. Excluding charts, which is a component library anyway and not dependant on the IDE, you can build everything with the free SDK that you can with the package. You could always write your own charting components or find an open source one if you needed charts.
The whole AJAX craze was a big bait and switch. Everybody oohed and aahed over Google maps. Then the developers ran out and added to their projects. And then the big ol' wait happened. Unless the data you're getting is miniscule, AJAX is pig slow. My business customers all assumed that every bit of data was free and so they all started asking for these post-less pages full of AJAX. I cursed the day they ever heard that damned acronym. Google maps is a super easy and uncomplicated implementation of AJAX. The way it works is: if you're about to go to a cell for which the image is not already downloaded, it is triggered to go get it. That's it. It just gets images as needed. No hard-core calculations or anything. So simple because the job it's doing is really simple.
> Flash Player 9 will work on the majority of systems and browsers out there today.
My AMD64-powered Ubuntu box disagrees. However, my AMD64-powered Firefox finds no fault with javascript. My cell phone doesn't seem to dig Flash, either.
For me the extra slow Slashdot is caused by their ?'s in their link URLs. Browsers and proxies are allowed to cache all GET requests, even with arguments, but so many web developers screwed up that idea that now browsers and cache proxies don't trust a URL with a ?.
So I have to reload EVERY SINGLE FREAKING JS and CSS FILE whenever I open a new browser to slashdot.
That's funny, I was writing AJAX-like stuff around the turn of the century, too... only my method for getting data updates from the server was to request JavaScript objects inside a scoopable, re-sourceable element. Actually, I remember working on this product in "proof of concept" around... 1998. It was shortly after I got my first ISDN line. Anyhow.
The biggest problem I found *wasn't* browser support. There was lots of great stuff to work with. Only, it was completely different from browser to browser.
Like, you could use IFRAMEs in IE to get Javascript objects. Or in Navigator, you used DIV with the src= attribute (man I miss that one)
In IE, you could modify what was inside an element with "innerHTML".
In Navigator, you could modify what was inside an element with element.write()
They both had lots of choices for how to do CSS (badly).
No, the problem wasn't browser support, at least not in my case.
My problem was filtering and rendering thousand-line tables.... I never could get that running fast enough to be useful. *sigh*
And, FWIW, the reason I was trying the AJAX-like approach was bandwidth and CPU. I wanted to use the browser as a remote caching + trivial computation engine.
Do daemons dream of electric sleep()?
Bosworth must be a vi user. We've been saying that for years!
"OWA". Exchange 2000 OWA.
www.voiceofthehive.com - Beekeeping and Honeybees for those who don't.
AJAX is going to be a buzzword for a couple years, then it's going to fade out just as quickly. Just like Java applets before it. Once the "new" factor wears off, people will more clearly see the limitations and problems, and stop bothering.
Let me ask this... who the hell WANTS to move their apps to the web? Web pages are a mess of inconsistency that is rather painful to navigate... As much as people complain about desktop apps, the biggest differences there are nowhere near the variations in web pages.
AJAX apps have to be perfect, because the baseline (the browser footprint and network response time) puts them at significant disadvantage, before you even start adding any features. From there, it can only get worse.
What's more, AJAX really only stands a chance of replacing the most basic programs (There's not going to be an AJAX version of Photoshop any time soon). So for all this overhead, you're still only doing what a tiny, lighting fast desktop program has been doing, and doing well, 2 decades ago. And my tiny, non-AJAX e-mail program is faster, better, more readable, more customizable, and has far more features, many not even technically possible via AJAX.
AJAX strikes me as the kind of thing that is popular, just because it can be.
And personally, I avoid any companies that go out of their way to remove backwards compatibility, for flashy new features.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
You may not get the timing just right, what you think is going to take 2 years might take 5, but if you bet on Moore's Law you can be pretty sure your time will come. Look at the rise of interpreted languages, virtual-machines, etc. over the past decade. It's not an accident, it's just Moore's Law playing out.
Still, it's not just that machines can now run "AJAX" apps fast enough that limitations in the underlying technologies are marginalized, AJAX is rising again because we've yet to provide a compelling alternative that combines the speed of development, speed of deployment, speed of maintenance patches, speed of market corrections, speed of "virality" (word of mouth), etc. that are supported by using a browser as a deployment platform instead of limiting it to marking up a few physics papers.
Clearly, once other languages get involved we'll need a different acronym.
I propose Asynchronous Scripting Embracing XML Using Any Language
ASEXUAL. It works to both describe the technique and many of the people who use it. Bah-dum-ching! Thank you, thank you, I'll be here all week.
It breaks my pluginses, my precious!
http://www.alexhopmann.com/xmlhttp.htm
The work to create what became known as XmlHTTP was done by folks in the Outlook Web Access, and it was a gradual development, it did not come in the form of a spec by a third party group, but some brainstorming and mixed ideas as those developers were trying to build OWA (they were using clever post backs at the time), he describes it as: The guy that implemented the feature joined Microsoft in 1997, and would not start working on it until 1998 and the work did not start until 1998 (he said "probably in late 1998"). In fact, according to that history, they had to scramble to get the feature into IE5 (finally released in March 1999): Which is at odds with Bosworth's claim that they helped invent AJAX in 96-97.
Like many people at the time, the idea of calling code on the server was around, Netscape even shipped in 1997 shipped a browser that contained an IIOP client (IIOP is a binary protocol, part of CORBA) that allowed the browser to communicate with IIOP servers on the other end:
http://cgi.netscape.com/newsref/pr/newsrelease389
At the time Netscape was touting the benefits of using this new API as a way of building rich applications. So the idea predated Microsoft and Bosworth, but never got mass adoption.
So who came up with the idea first is hard to tell. But it seems obvious that Ajax did not originate within Bosworth's own team in the 96-97 time frame, but in another team: the Exchange group in late 1998 to 1999.
As they say, "Success has many fathers, and failure is an orphan."
Also i beleive 'NOT' is not how i spell not. And that technicaly is a double negative, i guess.
Hivemind harvest in progress..
Flash Player 9 crashes on my Ubuntu box. More importantly, Flash is a highly proprietary technology in many ways. There's a plethora of licensing restrictions that make it impossible to produce a fully source-code-compatible OSS implementation of the whole Flash toolchain. The audio and video codecs it supports are also patent-encumbered in the U.S.
Find free books.
http://www.ajax-en.vesproshop.nl/domains/vespro_aj ax_en/content/productimages/large/307766.jpg ;)
-John Mark
Hyperic Community Outreach
http://www.hyperic.com/
Hyperic Community Manager
Yes, this was mobile computing 101:
1. Enterprise users == thick clients (installed)
2. B2B == semi-thick/JSF/Applet clients (downloadable thick clients)
3. B2C == thin clients (web)
Anyway, I thought AJAX was Microsoft's answer to Java Applets & Webstart--in the browser wars back then, IE/ActiveX was a natural competitor to Applets & Webstart. Of course, IE/ActiveX did beat applets since they ran at OS speed--and that's the main cause of derailing AJAX back then--why write javascript when you can have full [activeX] access to the OS stack!!
Funny thing is regardless of AJAX and ActiveX becoming dominant back then, we'd still had the security issues with IE today. Too bad cpus weren't fast enough for [gasp] applets back then.
Where exactly do you see it's deprecated? W3schools doesn't mention it, Wikipedia does neither, and on the W3 page for iframes nothing is mentioned about deprecation. If you mean the oh so hip use of using a hidden iframe to send all kinds of crap back and forth instead of the XHR object, then yes.
While I mostly agree with Bosworth's explanation, I have one thing to add. One reason that DHTML didn't succeed at first is that developers did not want to use it. I was doing DHTML in 1997 or thereabouts. Friends of mine have been doing it since at least 2000. All of us, at some point, came up with the plan to implement a desktop-like GUI environment using JavaScript and HTML. But all of us eventually backed out. The reason is that we realized we just weren't using the right tool for the job. Whatever you do, you're going to end up making lots of HTTP requests and sending enormous amounts of JavaScript down the tubes. Also, web browsers were and still are slow and lacking some controls and features one would want to use in interactive applications. I briefly campaigned for adding some simple, useful features, but, after ten years, none of them have been added yet. Eventually, I just lost interest.
The landscape changed when toolkits started to become available that hid all this madness from developers. Nowadays, you can develop DHTML apps in sane languages, and have all the crud that is needed to make things sort of work in browsers be automatically generated. Coupled with faster computers and faster network connections, both the developer and the end user get an acceptable experience. I think that's what really caused DHTML to take off.
And yes, I'm saying DHTML, rather than AJAX, because XmlHttpRequest is just one way to poll the server; the essential feature is dynamically updating the page.
Please correct me if I got my facts wrong.
The future is with fat bacon.
Says me, the common tit.
Today's thick client is tomorrow's thin client. The modern example of the "thin" client is pretty loaded with, what only a few years ago, used to be really processor intensive software. Stretching this trend forward into the future (probably not valid, but who cares this is slashdot), I forsee a time when "thin client" means you've *only* got *four* processors in your system instead of *eight* or something.
Furry cows moo and decompress.
Maybe it's better to have to use a programming language to do something that most people would expect you to have to use a programming language for. There's this thing called the Principle of Least Surprise.
Furry cows moo and decompress.
This is such utter tosh. My mother was using Ajax in the 1970's and I suspect it had been invented a long time before that. http://www.colgate.com/app/Colgate/US/HC/Products/ HouseholdCleaners/Ajax.cvsp
I believe i is not the way I spell I
> Bosworth On Why AJAX Failed, Then Succeeded
Oh what the hell does "Lois Lean" know, anyway? >:-(
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
Hi:
So you don't approve of AJAX. You don't like thin client web-based tools for end users. You have strong opinions about the direction of development that conflict with common wisdom.
I'm preparing to spend several million dollars developing custom complex AJAX based systems to track regulatory and scientific information, with one major system going into production tomorrow.
What's your real-world suggestion for how I should architect future systems, now expected to be built with AJAX?
Thanks,
JR
Think of the Irony!
Hello everyone, I'm a software developer at a company that develops training software for the government. Now some of the tools I've written in Java because I wanted to make sure they were cross platform and we are not binded to Microsoft tools if we ever needed to switch platforms 10 years from now, but for the most part our big projects will be web base. I'll give a little list why:
1. Create and fix lessons from anywhere - Like I said we submit changes to the client and when they want to rework something it can be done on site. Plus put in a request for changes when it comes to graphics for there lessons.
2. One location for using tools - As we get bigger more and more users will start using these in house tools. We look better just copying up our changes to a server, then to have users install/reinstalling software over and over again.
3. Community - Since it's web base when ever a user login the other users will see that person and what they are working on and will even be able to send messages. So if the Author of the lesson wanted to he/she could request a graphic or animation and it will be placed in a list for the Graphic Artist. This also makes it so the Authors of the lessons could create and borrow from other Authors. Plus the main thing...Communication and sharing!
4. Cross-Platform - The tools are build using the Dojo toolkit which support 5 different web browsers on the three major platforms I like to aim for which are Windows, Linux and MacOS X.
So there you have it! I normally don't post on Slashdot but I figured since some people are bashing AJAX/WEB 2.0/DHTML I had to step in and say something. Then again like my subject simply states, it's about using the right tool for the job. If I was building a 3D Engine, Video Editor or Sound Editor I wouldn't be using AJAX. I always do my best to keep an open mind when it comes to developing software.
From Zero to Hero... Starbuck Zero
i love that! what a good quote... feels like here that at my work too....
Hard work is just an accumulation of the easy things that you didn't do when you should have.
ahh come on. I always right my niices as niice...you can't go rong with a word like that :P
I think that this emphisises how niiice it really is...
Hard work is just an accumulation of the easy things that you didn't do when you should have.
3. Web apps can't be pirated.
Even if an application could be done somewhat better on the desktop than over the web, the fact that the company providing the web version doesn't have to worry about pirating can make the difference.
I don't know about you but I don't really see much of a place for Ajax in many types web enabled applications.
Nowadays its cheap and a simple powerful structure from a systems POV to simply reload a page especially if your also taking advantage of other technologies such as frames/css.
There are lots of places where a more interactive interface is warranted and where Ajaxish technology is a good idea but people have been doing the same thing with hidden frames and other technologies since the early days.
At some point if you really want your application to feel like an application you should just give up on the trying to turn a thin client into a thick client ajax kludge and write a java applet.
I have yet to find useful browser widget libraries that I liked and didn't over heavy daily use cause weird bugs to appear such as memory leaks, browser crashes or display flakiness. I'm assuming others have had much better luck than I have.