AJAX and IE7?

Moochfish asks: "Recently, my company took a brief look at AJAX to see if it was worth implementing on a few of our administrative pages to speed up certain tasks. I had created a demo that made an interesting use of live edit fields that showed some promise. However, after a little debate on the issue, we ultimately decided to skip AJAX implementations anywhere in our codebase due to concerns about things breaking when IE7 comes out. I haven't personally tried IE7, but I completely understand and mirror the concern. For you testers of IE7, does it successfully render current, non-ASP AJAX enabled sites without errors? And finally, does IE7 introduce any new functionality that may enhance the current capabilities of AJAX?" "Many of the AJAX libraries out there have tons of duplicate functionality to handle cross-browser support. Recalling Microsoft's history of IE quirks, it seems likely that the new IE7 will have its own set of problems with regards to JS implementation. With the AJAX craze only growing, how are other developers and IT departments addressing this problem? Is this even a valid concern? While this is probably not an issue with ASP developers - especially with the release of Atlas - is this an issue for sites that use non-MS technologies?"

Comments

I don't get the question, I think

[heinousjay]

Why not just install the beta and see how it behaves? I can't imagine they're going to change the interface to the XMLHTTPRequest object now, but even if they do, you can isolate that change. Bam, AJAX still works.

Seems your question might be more about DOM manipulation, but I have the same advice: install the beta.

Re:I don't get the question, I think

[ptlis]

They have. It's now identical to that used by all the alternative browsers (the team state the reason as being corporate users block all active X content, meaning that currently AJAX applications are unsuitable for corporate environments using IE).

Re:I don't get the question, I think

[heinousjay]

Even still, that kind of change is easily isolated, and is already covered by all the major AJAX libraries I'm aware of. The actually usage interface shouldn't have changed, and that's much more important since client code typically deals with that a whole lot more than simple construction.

Re:I don't get the question, I think

[MobileTatsu-NJG]

"Why not just install the beta and see how it behaves?"

There's a big difference between briefly tinkering around with it and getting responses from people who use it daily. "I was able to log into GMail, it works perfectly!"

Re:I don't get the question, I think

[poopdeville]

Yes. Testing is far more useful.

Re:I don't get the question, I think

[ptlis]

Indeed, and that is infact my point - I was intending to mention the fact the change actually benefits developers in the long term as it means that it will be a truely standardised interface, i'm not a fan of Microsoft or IE (I do a fair bit of development work for the web) but at least it seems like they're really trying to fix things up in IE7 (preferable imho to adding more buggy features).

Re:I don't get the question, I think

[hey!]

I can't imagine they're going to change the interface to the XMLHTTPRequest object now, but even if they do, you can isolate that change. Bam, AJAX still works.

I could imagine this.

The way MS products work is that they are integrated. That's the value proposition: use Visual whatever, IIS,IE, and MS SQL Server and it's wrapped up in a tight package for you. If they made a change that was useful to their toolchain, their developers would never see it except as improved features or performance. If it caused trouble for people who put together tool sets from their competitors, why should they care.

I don't think this is likely to happen; given the speed with which Ajax is being adopted, it would break too many web sites and be seen as a bad release by users. But it is not by any means unimaginable.

non-ASP ?

[LDoggg_]

For you testers of IE7, does it successfully render current, non-ASP AJAX enabled sites without errors?

What the heck does the tech creating the html/javascript have to do with the browser's usage of the generated code?

If you specifically mean ATLAS, they you should specify it in that question.

Re:non-ASP ?

[hey!]

What the heck does the tech creating the html/javascript have to do with the browser's usage of the generated code?

It has to do with how attractive alternatives to Ajax are. If you're in for hell anyway, then the argument that Ajax is going to be hell doesn't carry as much weight.

Context is everything in decision making.

easy solution

[chef_raekwon]

just have a popup on your page that automatically downloads, installs, and launches firefox.

Re:easy solution

[MikeFM]

Sadly, I wish that was possible. To bad Gecko can't be compiled as a downloadable Java applet or something. IE7 still sucks although maybe not as bad as IE6 but with the extra benefit of being incompatible with IE6, Firefox, Opera, and Safari. At least Firefox, Opera, and Safari are mostly compatible amongst themselves.

Re:easy solution

[Joe U]

IE7 still sucks although maybe not as bad as IE6 but with the extra benefit of being incompatible with IE6, Firefox, Opera, and Safari.

Oh great, your version of IE7 must be out of beta. Can I get a copy of the final? I've been wanting to try it, and since it's not due to be released until November, I didn't want to wait.

Re:easy solution

[MikeFM]

Beta means mostly feature complete. Or is supposed to. If IE7 is to have anywhere near the quality of CSS, DOM, and JS support as Firefox, Safari, and Opera then it really isn't beta quality software yet. If it improves that much by release I'll be happy. IE7, as of now, sucks though as compared to the testing version of Opera 9 which is very good.

Re:easy solution

[Joe U]

Beta means mostly feature complete. Or is supposed to.

That's really a company by company definition and in many cases a project by project definition. While I agree with you, it should be a feature complete program with bugs that need to be worked out.

Microsoft, however, doesn't always follow that guideline and that is their decision. It's not right or wrong, it's just their decision. It's most likely why they plan to abandon the general 'beta cycle' completely, it makes more sense from their standpoint.

That being said, the first rule of reviewing a product is that you can't write a review of an unfinished product. You can preview it, and if you're using a preview as the only guide as to how the finished product will look then you are making a mistake.

Re:easy solution

[MikeFM]

The definition of alpha, beta, etc is project by project but there are certain standands that exist as to the naming scheme. I agree that Microsoft isn't likely to follow such a standard, or any standard, but it's still the standard. I don't remember if IE7 was even called a beta though. They could have called it something else and I wouldn't remember. I wish they'd let you keep IE7 and IE6 installed on the same system without jumping through hoops. IMO all testing software should do that.

True, they could suddenly do something that makes IE7 rock. I hope they do. But history and their own claims about IE7 says that it isn't going to do that good. Maybe user feedback will convince them it's worth the effort though. Maybe the programmers will get so pissed at upper management, given the article about Vista and Office causing an uprising, that somehow they'll push through an IE7 with awesome CSS, DOM, and JS support. That'd be awesome. I'll keep my fingers crossed.

Re:easy solution

[Anonymous Coward]

Sadly, I wish that was possible

Well, of course it is. Just exploit the latest high-risk bug to run 'arbitrary code'.
This also frees you from having to worry about user agent detection.

Administrative pages

[Anonymous Coward]

Since it seems you want AJAX for internal uses, why do you care if it'll work with IE7? Seriously, maybe your organization should consider deploying Firefox...

Ajax will be better in MSIE 7

[BladeMelbourne]

If I recall, MSIE 7 has XMLHttpRequest - no more using MSXML. The same code should run on Mozilla and MSIE 7.

MS has also released their Atlas Ajax library/framework in the past couple of weeks.

I hate IE 7's interface. Tabs are ok, but the buttons and layout are not placed well on screen.

Re:Ajax will be better in MSIE 7

[bjpirt]

This is true. The only cross browser testing that should need doing is whether the browser is IE 6 or 5.5 (or 5?) in which case use the active X control. IE7 has the same XMLHTTPRequest object as all the other proper browsers

Re:Ajax will be better in MSIE 7

[masklinn]

If I recall, MSIE 7 has XMLHttpRequest - no more using MSXML. The same code should run on Mozilla and MSIE 7.

Yep, other than that I haven't seen any modification of the Javascript interpreter mentioned anywhere.

Re:Ajax will be better in MSIE 7

[Anonymous Coward]

IE7 has the same XMLHTTPRequest object as all the other proper browsers

You mean to say - when all the other browsers copied IE's XMLHTTPRequest support, they didn't implement it the same way that Microsoft had. For the history impaired.

Re:Ajax will be better in MSIE 7

[Bogtha]

Yep, other than that I haven't seen any modification of the Javascript interpreter mentioned anywhere.

Internet Explorer doesn't have a JavaScript interpreter. It has a JScript interpreter. JavaScript and JScript are both implementations and supersets of the ECMAScript language specified in the ECMA-262 standard.

Re:Ajax will be better in MSIE 7

[moochfish]

That is a very interesting update. Do you happen to know if a list exists anywhere on what Javascript-related updates they've made?

Re:Ajax will be better in MSIE 7

[GregWebb]

Largely due to MS implementing it in proprietary, insecure ActiveX it should be noted...

Re:Ajax will be better in MSIE 7

[Anonymous Coward]

It's their god damn innovation. They can implement it however they want.

Re:Ajax will be better in MSIE 7

[spectre_240sx]

And it's our choice to implement it in a more secure fashion if we see fit. That's what happened and now MS has decided to go that route as well.

Is there a problem with that?

Re:Firefox

[dpilot]

No. The answer is clear. They should postpone doing anything until Microsoft is ready for them to start, with IE7.

How DARE anyone think of innovating without Microsoft!?!
How DARE anyone think of doing anything with a computer that isn't the One Microsoft Way!?!

(That's sarcasm, for the impaired. Ordinarily I wouldn't think it necessary, but this IS Slashdot.)

Fine

[Kawahee]

It works fine. GMail runs smoothly, Outlook Web Access runs smoothly. IE7 is just IE6 + more features and better CSS support. And they're using the standard HTTP request object now, not the MS* one.

Re:Fine

[Osty]

It works fine. GMail runs smoothly, Outlook Web Access runs smoothly. IE7 is just IE6 + more features and better CSS support. And they're using the standard HTTP request object now, not the MS* one

The "MS* one" defined the standard. But yes, it required creating an ActiveX object rather than being a native implementation. That said, while IE7 does now have a javascript-native XMLHTTPRequest implementation, it can also still run ActiveX controls. That means sites that do stupid things like parse UA strings for browser compatibility rather than using object detection will still work fine even though they'll go through their ActiveX codepath rather than using the native object.

What this really boils down to is a fundamental issue in how you write javascript across multiple browsers. You should never parse UA strings, because they can change (across releases, or just because the user says so like with Opera or Firefox). Sites that use UA detection are broken, even if they do work on some subset of browsers. The correct way to do cross-browser support is to use object detection. For example, look at the following code (I hope this formats correctly):

function OnKeyPress(e)
{
if (!e && window.event)
{
e = window.event;
}
else if (!e)
{
// can't get an event object, so let's just leave
return false;
}

var key;
if (e.keyCode)
{
key = e.keyCode;
}
else if (e.which)
{
key = e.which;
}

// you can now use key, which should be the same value across all browsers
}

This is an event handler, where a browser like Firefox will pass in the event object but IE expects you to use the window.event global. So, you check for that. Once you have the event, different browsers use different fields to hold the key code (which will be the same across browsers), so you check for that as well. Nowhere did I check if this was running on Firefox, IE, or Opera. I just checked for what I needed, found it where I could, and bailed out otherwise. The above code will work on IE6, IE7, Firefox, and Opera, and should work in Konqueror, Safari, etc (I just don't have those available for testing).

Just to reiterate to make it clear, if you're using UA detection, or you're using a library that uses UA detection, your code is broken. Fix it!

Re:Fine

[Achromatic1978]

the standard HTTP request object now, not the MS* one

I love it. Not even 'inventing' a feature is enough for someone to claim it's 'nonstandard'.

Re:Fine

[spectre_240sx]

To my knowledge, there is no formal standard for XMLHttpRequest. Therefore, the next best thing is a de facto standard, which is what Safari, Opera, Firefox and now IE7 have created by sticking to the same implementation. Thus, the original ActiveX implementation is non-standard.

Re:Fine

[Achromatic1978]

Whilst I am very content with the concept of 'standards' and 'de facto standards', this almost sounds like:

1. Develop an implementation of something.
2. Watch as your competitor develops a incompatible implementation of same.
3. Watch further competitors mimic first competitor, building implementations compatible with theirs, but not yours.
4. Receive smacks for having a 'non standard' implementation from elements of the public.

Of course, if I am projecting, please feel free to point that out, too.

Re:Fine

[spectre_240sx]

You definitely have a good point. I think one thing that makes this complicated, however, is the fact that Microsoft used ActiveX to create the functionality. Being that it was implemented on a non-standard base from the getgo, I think it's somewhat fair to call their original implementation non-standard.

There's definitely a grey area there and I'm a bit unsure how I feel about the situation myself. In the end, though. I am glad that Microsoft has chosen to go with the de facto standard that has been created.

Re:Fine

[Achromatic1978]

Agreed. In the end its better and simpler for all if a standards based approach is taken, I just thought it a little unfair that of all the things Microsoft could be berated for, this would be one of them - and not necessarily you, I've seen this argument several times.

IE7 Browser Usage and Design Decisions

[alstor]

While this doesn't exactly answer the question posed, the question made me consider the impact IE7 will have on browser usage, and Microsoft's design decisions for IE7. Given the current market of browser distribution basically mandates that web designers and programmers fix IE6 issues, I am not so sure that IE7 will be considered in such forceful terms, or, that Microsoft will be forced to try harder to make the browser standards compliant and have fewer idiosyncrasies. Should web designers and programmers be forced to make frustrating fixes for so many generations of the same broken browser? From the numerous times I have been pissed at IE6 because it rendered something just slightly off, I know I might advice organizations I program for to tell users to use Firefox or Mozilla or Opera or nearly anything aside from IE6, or in the future, IE7. For Microsoft's sake, I hope they have considered the possible backlash from the generally non tech savvy users of IE6 when they get an update to IE7 and all the new AJAX applications break. I know that if I were trying to use Gmail or Flickr, and they just stopped working when I moved to IE7, I might just switch to Firefox or Opera if I hadn't tried before.

Re:IE7 Browser Usage and Design Decisions

[Cycnus]

I don't think that's going to happen like you said.
Like it or not, MS still dominates the browser market, and whatever decision they make is the benchmark which web sites and web applications have to reach if they ever want to hope to be successful for the majority of their visitors.
Big organisations may control which browser they install on they PC, but the immense majority of home users can barely use copy and paste effectively, so asking them to ditch IE in favour of Opera or Firefox is never going to reach beyond the more tech-savvy who understand the issues at hand and are capable of making that decision.
That leaves us with whatever version of IE still being dominant because Windows is the dominant OS and most users do not have the sufficient technical skills to assess -or even have an opinion on- security and standard compliance.

At any rate, it's really unlikely that MS would break compatibility with IE6 in a big way. There will be compromises and some minor things and bugs may break some particular implementations, but the stakes are sufficiently high for MS to ensure that the new browser adoption is not going to let down all those intranets and websites that their large customers currently use. Doing otherwise could slow down the adoption of Vista and that's certainly not something MS would wish.

I think that we're looking at an age of better interoperability between browsers as they converge to support a rich common set of features. They are and will always be differences in the way some of the details are implemented, for historical or standard interpretation reasons, but overall, there is sufficient common ground to built applications that behave in the same way on multiple browsers, and IE7 is certainly going to be a better replacement to IE6 as it becomes more standard compliant.

Re:IE7 Browser Usage and Design Decisions

[jessejoe]

I'm sure they have considered the backlash, and have decided that the best thing to do is to do their usual nothing: assure their customers that nothing is wrong with IE7 and that the website in question is broken and will need to be updated. End of story. Not their fault. They just made the web browser, not the content you cannot view with it.

It's a non-issue

[AnamanFan]

I think you're a little confused about what AJAX technologies are and where they run.

AJAX is a presentation philosophy (AKA: a client-side issue). It runs independent of the server technology used. On various projects, I have implemented AJAX on servers running PHP, ColdFusion, and static HTML. AJAX is server platform independent.

As for the particulars of IE7, I can say that using script.aculo.us and Prototype libraries run the same if not improved on IE7 in comparison to IE6. The fact that the libraries themselves are actively being tested for IE7 as new beta comes out means that I don't have to do anything extra for the changes; It just works.

I understand the initial concern for IE7/IE6 compatibility, but sticking with a popular library solve this problem and make the concern a non-issue.

As for the server-side of AJAX, what you'll be coding are pages that output either HTML, XML, or JSON. Any server platform can create this kind of output, so questions of server compatibility are moot.

But my word of cation is this: Know why you are changing a component to an AJAX philosophy and how best to implement it. There are good reasons to use AJAX as there are bad ones. Please proceed with cation and purpose.

Re:It's a non-issue

[Anonymous Coward]

I think you're a little confused about what AJAX technologies are and where they run.

Hello alien friend. Welcome to our green planet. On our world there is a big company called Microsoft who ties users into their products by such techniques as selective bugs and embrace and extend.

Its actually an insightful question to ask if any AJAX use in IE7 is tied to ASP.

Re:It's a non-issue

[Homestar Breadmaker]

No it is not insightful, it is a senseless question. ASP is server side. "AJAX" is just javascript, its purely client side. Nothing about IE7 (or any other IE version) has anything to do with ASP.

Re:It's a non-issue

[Osty]

No it is not insightful, it is a senseless question. ASP is server side. "AJAX" is just javascript, its purely client side. Nothing about IE7 (or any other IE version) has anything to do with ASP.

A useful question might be whether Microsoft's Atlas library (ASP.NET 2.0 client-side AJAX stuff) works on browsers other than IE. And the answer is, "Yes!". If you don't believe me, head on over to Live.com in Firefox and tell me if it works. Yes, yes it does. And Live.com is running on an older version of Atlas than the CTP that was just released at MIX06. Live.com does support IE6, IE7, and Firefox, and supported the Opera 9 betas at one point (it seems that the early-March site re-launch broke Opera support), but not Safari. However, as I understand it the Opera and Safari non-support are problems which Live.com needs to solve on their own and not something inherently wrong with Atlas.

Shannanigans

[Fhqwhgadss]

Let's see: The poster has an in-house web application and has gone so far as to prototype an AJAX-ified interface. After all of this work is done, it appears that the new interface may improve productivity, but the idea is scrapped wholesale over some ephemeral fears that IE7 _might_ break their site, and an Ask Slashdot is posted.

How hard is it to download the IE7 beta? The app is in-house so if it breaks tell IE7 users to fuck off until support is added for it. Is moochfish totally inept or just trying to fan the 'IE7 is the suck' flames? My guess is the latter.

Re:Shannanigans

[moochfish]

My company is involved in consumer web traffic and thus many users in the company use a variety of browsers to test both in-house and partner web pages. The rest of our administrative software works fine in the main browsers we use and it would be rediculous to force everybody to start using a specific browser for one or two pages.

Secondly, my prototype was a demo for something I wanted to expand to our clients and partners. And trust me, coding a 20 line AJAX script is not that much work and you might think.

Finally, telling people to "fuck off until support is added" is the exact reason the project was canned. That is not possible in the business world.

The decision was made without my direct input. I though it was an interesting issue and was curious how other departments handled it. I wasn't asking for ways to convince my management to reverse their decision.

But thanks for the trolling/flamebait.

Re:Shannanigans

[Fhqwhgadss]

Ah, I was too hasty interpreting "administrative" to mean "non-customer-facing". That was foolish and you certainly can't tell your customers to use a supported browser or fuck off (at least not in the case of IE). That said, I fail to understand how posting a question to Slashdot is expected to provide better insight than running the beta. It probably involves more actual effort as well.

Re:Shannanigans

[Compholio]

Is moochfish totally inept or just trying to fan the 'IE7 is the suck' flames? My guess is the latter.

Probably, and I'm totally cool with that. I say he should convert his company over to using Firefox or Opera, the more people that use "alternative" browsers the better it is for everyone.

Re:Shannanigans

[mattyrobinson69]

Im in the process of adding some Ajaxy goodness to fone-me.com, this to give the users instant mail notifications works fine (although i should point out that the number 1 on line 20 is printed by a php script)

http://rafb.net/paste/results/YYjERl90.html

This works fine in IE6,IE7,Opera,Firefox,Konqueror, although i'm going to reduce the interval (every 5 seconds is very excessive)

Re:Shannanigans

[delus10n0]

Until such a time those "alternative" browsers become the mainstream, then suddenly they're the enemy now..

Try it yourself you tool

[Fweeky]

Runing IE7 Beta 2 Preview next to IE6.

Re:Firefox

[BoomerSooner]

That's what my company does. We support Firefox. If you're having a problem and it's IE related or Safari or Whateverbrowseryouwant, we try to help but if the functionality is not as good we don't worry. Granted our site is designed for speed and not beauty so we have few if any problems.

Eventually we'll reimplement and my goal is for us to have a good looking and fast site! I'll be long since retired from programming before that happens...

Cheers!

Re:Firefox

[tomhudson]

If they're going to wait for IE7 to come out of beta "just in case", by the same reasoning they should also wait for Vista to come out of beta.

Seeing as Longhorn/Vista was originally supposed to be out in 2003, oops, 2004, sorry 2005, for sure 2006, now definitely Januar 2007, the question is "Which will be out first - Vista or Bush?"

Re:Take it from someone who knows...

[TheComputerMutt.ca]

"Take it from someone who knows..." from personal experience? You suck too?

Re:Firefox

[paugq]

He's talking about a intranet application for his company. To state it clearly: it's an in-company application, so you have full control.

Where's the problem telling users to employ Firefox? Hell, most companies oblige you to use Microsoft Word to write your documents and Outlook to manage your e-mail. What's the difference when telling people "you must start Firefox when using the accounting application"?

Re:Firefox

[dpilot]

You truly understand.

There's simply a general misunderstanding of the statement, "Microsoft sets the pace for innovation." At face value, it looks like they're bringing us along, instead of slowing us down.

IE7's not done untill gmail won't run?

[Anonymous Coward]

Is it going to be "IE7's not done untill gmail won't run" all over again?

reverse the questioning please

[icepick72]

I got an idea ... YOU have the Ajax script that you want to test. Why don't you download IE7 beta, test it on your script and YOU tell US how it works by posting the answer to this thread. Thanks from all of us. -- Slashdot users. (I speak for them in this case.)

When will people learn...

[Baloo Ursidae]

...that people will not stop using IE until you stop supporting it? Fuck IE, code for the standard, if it breaks IE, tough crap, they can get another browser.

Re:Firefox

[Bert64]

And how many places tell you to use IE.. That's far more retarded. And boils down to laziness on the part of the developers.

I don't believe in forcing people to use particular apps either, however there's nothing wrong with demanding people use apps which comply to a certain set of standards.

This happens with cars too, if you go into a garage with a particularly old car in a really poor state of disrepair, it's highly likely they will recommend you replace it, cars can often get to such a state that repairing them is not financially viable and it's much cheaper and easier to buy a new car. This is the same with IE, it's horrendously outdated compared to other browsers and unlike a car, you can't get someone to fix it for you.

Apps should be written to published standards, and require any browser which complies with those standards, so long as the app complies with the standards then any browser that fails to render it is at fault. After all, there are many things which simply can't be done in outdated browsers like IE, and many other things that require lots of nasty kludges for IE but can be done easily and cleanly in modern browsers.

dumb

[namekuseijin]

"does IE7 introduce any new functionality that may enhance the current capabilities of AJAX?"

yes, it'll come with the almighty proprietary XAML technology M$ stole from Mozilla XUL. and everyone will bow to it and an html web will be gone...

You're really serious about waiting for something which you even fear might break your efforts? Talk about reasonable businessman...

There should be no wait or fear if you just coded for standards so that it would run on any browser. Or just go for Firefox, which is here now and works great, with great standards-compatibility which won't simply disappear in some future version.

If you're believing IE7 will be any close to Firefox in either standards compatibility or sheer top-notch features, you'll be severely letdown, as with most M$ products: it's nothing but a patched IE6 with some more much-needed uptodate css support, something FF has had for several years by now...

Works fine.

[Spudley]

We've tested IE7 with our Ajax apps, and they worked perfectly without any extra work. We did have some stylesheet issues, but no problems at all with Ajax.

IE7 replicates the XMLHTTPRequest functionality already found in other browsers, so if your Ajax library tries to use that as it's default, then it'll all work perfectly. On the other hand, if your libary tries to do browser detection before deciding which method to use, then you may need to update it. (Thus demonstating very nicely the reason why one should write feature detection code rather than browser detection)

Doubt

[WED Fan]

I am sorry, and I am apologizing up front and will probably have my karma slammed, but I do have to comment.

I really have to question the legitimacy of this 'Ask Slashdot' article, and am wondering how the editors let it slip through. The article is either a fake, or the person submitting it is a piss-poor tester.

How hard would it have been to install the IE7 beta on a single machine to check the rendering of AJAX elements?

I have IE7 installed on a test machine that we use to test web apps. I also use it for much of my daily browsing. As a result, I have a list of items that IE7 just won't work with, chief among them are SharePoint event calendar rendering, and Microsoft Producer. It has not broken against AJAX that I've run into, and I use Pageflakes as my homepage on that machine.

So, the poster is faking a "my-company-wanted-to-use-the-latest-greatest-but- we-are-afraid-MS-will-break" article, or his company is paying him much too much for his perceived skills.

Really, editors, you should have caught this.

Browsers Apps Suck

[Anonymous Coward]

Ever stop and think that maybe web apps, although a noble concept, are a waste of effort? Lets be honest here, the browser languages are for the most part, third rate and were never designed to work together seamlessly. The security problems have become so much of an issue that developing these types of programs become more expensive and time consuming than traditional desktop applications.
It seems everybody has now jumped on the web app bandwagon in the past few years, but I question whether people really stop and look to see if the problem they are trying to solve can be done effectively with a web app.

I've built a library on top of ajax.

[josepha48]

basically I have created an ajax object in javascript. That object then handles the differences between IE and gecko based browers and opera and safari and konqueror.

I've done this with several things as well: libjsevent -> event abstraction; libjsdom -> some dom manipulation abstraction; etc. The advantage to this, is that if IE7 supports ajax differently or through activex or some other means, then I can add it to the library and all things work again. If I have to develop some special IE plugin I can check for that in my object and have it prompt the user for a plugin download.

All applications that need ajax use libjsajax and then I update the library and they all work.

Seems simple to me, or am I missing something?

Re:I've built a library on top of ajax.

[josepha48]

here read this about their support in IE 7

http://www.microsoft.com/windows/ie/ie7/featuret able.mspx

New Words Please

[Anonymous Coward]

How about contributing something to this thread that wasn't already said in about 4-5 other (higher) posts.

Graceful Degradation

[TwilightSentry]

Other posters have pointed out that AJAX works fine in the IE7 betas, but if you're making a site that depends on AJAX, regular javascript, flash, etc., you should always just have a normal HTML fallback for browsers (Such as lynx) that only support the basic tags.

my experiences so far

[laan]

I'm leading some developements here on my company using big amounts of javascript/DOM manipulation/AJAX and I can say IE7 beta needs far less work than IE6 cause it's more DOM/CSS compliant but anyway the more javascript you make the more browser detection/dedicated code you need, no matter if it's AJAX/DHTML/Whatever you want.

AJAX and IE7 Question? My Results.

[LifesABeach]

I create software solutions; It's how I pay the rent.

Consider this Tensor: The more work the client does means less work the Server does; A classic example, "Initial Edits".

Consider the following senario:

1. HTML using CSS Posts a Form to a IIS web service,(because the submitter stated IE7 as the browser).

2. The reply comes back in the form of a XML response with an attached XSLT preprocessing instruction.
Notes:
    2a. This XSLT file will have imbedded in it the HTML using a CSS file, and a collection of Javascript files that are either cached or not on the client.
    2b. If the XSLT file is cached on the client, the result is faster.
    2c. If the CSS file is cached on the client, the result is faster.
    2d. If the Javascript file is cached on the client, the result is faster.

3. The client side performs any functions that the developers deem fit.

4. The reply is "Posted" back another IIS web service.

NOTE: Step 2 can be done on IIS; I know, because I've done it that way. Without having javascript handle the post reply.

Switch browsers

[Roadmaster]

With all the problems surrounding IE lately (and always), you'd be crazy to assume IE7 is going to be any better. If you're already expecting a lot of breakage from the new version, which it seems you do, given the concerns it's given you, why not start a planned Firefox rollout now, tackle any issues in a controlled manner with your old IE as a fallback, and by the time IE7 actually arrives, you no longer care because you're already running something else. I bet new versions of Firefox won't be as breakage-prone as new IE's.

To moderators:

[Baloo Ursidae]

Just because the truth hurts doesn't make it flamebait.