Simon Willison’s Weblog

Amen.

Infoworld called it the 11th biggest IT mistake.

You shouldn't call them "web apps" though - they aren't anything of the sort. They are in-house proprietary software.

Jim - 26th January 2005 03:05 - #

I'd still call them web apps, even if they're only in-house intraweb proprietary apps. I write in-house proprietary stuff, but it's still a "Win32 GUI app".

Adam Vandenberg - 26th January 2005 03:40 - #

Sing it, brother. I moaned about this myself; it's stopped us moving to Firefox at work.

sil - 26th January 2005 03:47 - #

I didn't know that anyone who's focused on a non-MS OS for any period of time, wouldn't understand why they've been doing that.

Devon - 26th January 2005 03:53 - #

This is clearly a case of "old habits don't break easily" (or even better, "you can't teach an old dog new tricks"). The only ways this is going to change is if a) People "see the light" of Web Standards and move away from proprietary stuff, or b) Mozilla gains 9/10 of the browser share, which if things keep going the way they are, should happen around 2009.

Dante Evans - 26th January 2005 04:01 - #

I think it's also important to note that IBM's inhouse web server, WebSphere is an excellent Java based server that could build via XML/XSLT standards compliant XHTML 1.1 Strict with very little effort. They've got an internal testing platform called BIAT that is based on XML+XSLT with servlets that is incredibly flexible. Surely they could redo their internal applications using their own technology.

Randy Peterman - 26th January 2005 04:38 - #

Randy, you miss the point that switching to Linux desktops is supposed to be a cost saver, and most companies have core business running on spaghetti-coded MSDOM apps. Replacing these apps is no where near free, no matter how you slice it.

Of course, this is no accident on MS's part. Don't look now, but they're doing it again with mobile devices, right now.

Jeremy Dunck - 26th January 2005 05:10 - #

I started to write a longer rebuttal, but it turned into more than a comment.

Excerpt: Bottom line: Firefox may be taken up by the home users and non-corp workers, but IE isn't going away in the business environment for a long, long time.

more

Jeremy Dunck - 26th January 2005 05:44 - #

This entire story is overblown. I can't tell you details, but I've seen the list of affected web applications and it's very short. One of them is quite literally a one-line fix. "Most internal applications" is a complete fabrication. The bit about the help desk only supporting IE is true but misleading; official support for Mozilla/Firefox will be added soon. This story is just your typical trade rag trash.

Mark - 26th January 2005 05:51 - #

Nice to see you're still lurking Mark. I hope you're enjoying your new hobby.

Thanks for the clarification, too.

Jeremy Dunck - 26th January 2005 05:57 - #

Whether this story is overblown or not, the message still remains the same. It makes sense to write any web application (internal or otherwise) in such as way that it works cross browser. Your motivations can simply be to keep Microsoft's monopoly at bay; or perhaps not all your users use Internet Explorer anyway (as at my work - most use Firefox and many use Macs); or maybe you have a commitment to accessibility.

With write-once DOM scripting available across the spectrum as well as wide support of the increasingly popular XMLHttpRequest it's hard to see why you would want to code only for Internet Explorer.

Richard Rutter - 26th January 2005 09:02 - #

In my experiance, it's more productive to get your web application working in anything *but* IE, and once its working then fiddle with it for IE.

Richard@Home - 26th January 2005 10:00 - #

"It makes sense to write any web application (internal or otherwise) in such as way that it works cross browser."

this isn't quite true, writing cross browser code is more expensive, simply because the QA requirements are considerably higher than writing for a single browser. To write an application 1 or 2 years ago, that works without modification on a newly installed mozilla was simply not practical, the costs involved in QAing such a product would simply be too high.

There's a sensible policy to avoid using any properties/methods etc. that are proprietary to your target platform (and in the above example, there was still going to be a target platform, it wasn't going to be a move to a free for all system) so that any future migration to a new platform will be as cheap as possible, but it does not make good economic sense to actually QA your internal applications such that they work under safari when there's not a single mac in the business.

On XMLHTTP object, is there really sound motivation to work around the Opera and Safari bugs in the object as you would on the web, is there really any motivation to even include the extra code to decide how to instantiate the object? I've been using the object for 4 years or so in intranets, was I supposed to predict how Mozilla would decide to clone the interface, before even mozilla existed? Should I not use other proprietrary IE features that halve the development and debugging time when in 3 months time other browsers will decide to ape those API's too?

"Your motivations can simply be to keep Microsoft's monopoly at bay" - This should never be a motivation when authoring for your intranet, you should be working to maximise your companies profits, unless your company happens to be an MS competitor, leave the anti-MS rants at home.

Jim Ley - 26th January 2005 12:15 - #

Simon, there's one problem with floating your post date to the top right corner above each post. If the title is too long to fit next to it, it breaks onto two lines, where it looks like the post date is part of the first line. So this post reads "Don't build web apps that only work [12 hours, 52 minutes ago] in IE". Just thought I'd mention it. :-)

Chris - 26th January 2005 15:45 - #

I disagree with this: "this isn't quite true, writing cross browser code is more expensive, simply because the QA requirements are considerably higher than writing for a single browser. To write an application 1 or 2 years ago, that works without modification on a newly installed mozilla was simply not practical, the costs involved in QAing such a product would simply be too high." We launched several major applications 1-2 years ago that work on Mozilla and other browers and had zero cross browser problems. We just used web standards. It is absolutely *THAT* simple.

Frank - 26th January 2005 17:36 - #

Normally I like to just lurk and the whole nine yards, but posts like this--while good, informative and justifiable (sp?) in a lot of ways--really piss me off as well. I would heartily agree with all of what Jim Ley said. Frank, you may be correct in some ways, but if your internal apps were based on XMLHTTP at all two years ago, then you *had* to choose one or the other.

Not only would I point at the QA costs, but I'd also point at the support costs. Do any of you really know how much it costs to run a help desk? Take those person's salaries, plus equipment, plus training and add them up. Now take into account the additional training it takes for someone--usually not the sharpest tack in the world (no offense meant)--to support more than one browser platform.

Now take the cost of the actual developers to create those applications.

Get the picture yet?

Developing cross-browser internal applications now may be feasible (although with the striking differences between MS's XML and the WWW's XML, maybe not), now that we have a 1.0 version of FF out there. But not two years ago.

Think about this before you (not you personally Simon, but the general you) go ranting about M$ and thier monopoly tactics. Businesses chose IE then because nothing came close to it in terms of app dev, and when it comes to documentation, no one comes close to M$.

If you really feel the need to promote web standards, I would submit that this is the next battlefront; go to town.

Tom Trenka - 26th January 2005 18:07 - #

In my experiance, it's more productive to get your web application working in anything *but* IE,

Yeah.

then fiddle with it for IE.

Or ... not. :)

Timothy McClanahan - 26th January 2005 20:39 - #

On my work placement as a software developer in a major investment bank, I was very glad that all the systems were locked down to IE. You had a cast-iron guarantee that your code would work over the whole user-base.

That was a corporate intranet, though. Since then, I've been trying to code web apps that are cross-browser compatible. I've had no end of strife trying to get HTML/CSS/JavaScript apps to run consistently in Safari (my main browser these days), Firefox and Opera. Whilst CSS support is -mostly- consistent across these browsers, JavaScript is a nightmare. On none of the browsers is it as expressive as IE's implementation. In addition, the level of support is completely different in each. At the end of the day I don't care that certain DOM objects and functions are proprietary or non-standard in IE - Microsoft have simply got the formula right, and it also performs a darn sight better than Firefox too.

Don't get me wrong, I think Firefox is doing a lot of good, and hopefully it will force MS to build in full PNG support and CSS2.1 into IE. After that happens, hopefully IE will dominate, and we won't ever have to test across 4 browsers again.

Chris Beach - 26th January 2005 21:34 - #

I work for a large software consultancy, where IE is rolled out as standard, and pleasantly powers all our web apps. I like how it loads quickly, how is acts solid, and how the cursor doesn't blink on the page like in Firefox. I also like how its not tabbed, so that I can switch windows quickly from an application to a browser window on my Windows taskbar (where I can see the page title), and not have to go back to Mozilla, and select the right tab I need - which is twice the effort. It's equivalent to spreading your papers all over your desk - you can get to them quickly. As opposed to stacking them up, where you must fiddle every time to the right page. The only (stress only!) good thing about Firefox is that you can "view source" in https mode, you can't do it in IE, something that helps defect fixing in my project doing a TIBCO Portalbuilder deployment, in which our iChain Directory product authenticates by default into https for the portal admin and portal content publisher. As a general concept, if someone hands over something for free (IE), and it works with everything else I use (which makes us bucketfuls of dough) - I find myself asking - do I want to be pedantic enough to waste time on standards? This seems a petty and academic exercise, compared to the objectives of our commercial deployments - to save costs, often into the millions. And lone programmer types should not forget that the browser is just one little part of a major systems integration, often a front end bonus. How different are browsers anyway? The answer is hardly. If one really wants something to do in their spare time, meeting the following objectives would make me reach for my wallet without hesitation.

• A way to share info and meeting data across mobile and fixed devices
• A better way to aggregate Outlook accounts which don't co-operate
• A way to stream a real-time terminal session (like Windows terminal server) through intermediate systems. Currently you connect or VNC into a terminal host.
• A way to completely integrate the recommendations of the Rational Unified Process (RUP) with a toolset that works with the fantastic IBM offerings of Rational Clearcase, Clearquest, etc. - giving us what these miss, and feeding open source plugins for Rational.
• I could write more of course ;)

There's more important problems out there, in computing as well as life, and one should think a bit bigger than the mundane soap opera of why one browser shows us something ever so slightly different to another.

Amit - 26th January 2005 22:27 - #

I also like how its not tabbed, so that I can switch windows quickly from an application to a browser window on my Windows taskbar (where I can see the page title), and not have to go back to Mozilla, and select the right tab I need - which is twice the effort.

Oh, please. If you're going to troll, at least do it well. There is absolutely nothing about Firefox that prevents you from being able to run it without ever using a tab.

As for there being more important problems, that's exactly the point. If you write your web apps to standards so that multiple browsers including IE can all run it from the same code base, then if you ever decide you need to switch platforms or browsers for whatever reason that's unforseeable now the most it will require is a bit of minor tweaking.

Considering the small amount of extra time that's needed to be cross browser with standards, compared to the time it can take to port a heavily one-browser-centric app, I think you'll have a lot more free time for your other important problems if you plan ahead a little.

Lach - 26th January 2005 22:50 - #

Venn diagram: an outer circle scribes what can be reliably done assuming IE/Win; 85% of its volume holds another circle, containing what will work within XHTML/ECMA standards.

We're not talking about an endless panoply of clients / interpreters / renderers. There are two: the set, and the superset.

Grownups may legitimately exploit the delta, but if they're later asked to explain why they did, "Dude, it was so confusing back then" won't be a good excuse. "Back then" is over.

LQ

Lou Quillio - 26th January 2005 23:56 - #

LQ, nice mathematical approach to a blog comment, heh. I think your venn diagram is missing a few circles though.

Most people here have more web dev experience than me - but even in my limited experience I've seen that Opera, Firefox and Safari do not present a consistent window on the web. The W3C's web-standards and the associated advocacy (read jihad) have led to the adoption of new browsers with bespoke rendering engines. It's inevitable they will have their quirks, and it's certainly been obvious to me. I think other developers will increasingly realise how counter-productive standards advocacy has become.

Chris Beach - 27th January 2005 01:35 - #

Simon doesn't worry about your bottom line though, his recommendation is more about bashing Microsoft, rather than helping you. He doesn't accept any responsibility when things go wrong or when you lose money because of his recommendation. The problem with Simon's recommendation is that, he has lots of facts wrong thus he wrongly concludes that you will be free when you do less. This means, for example, to write command line tools instead of GUI ones, so that you can easily port them to Linux or even Mac OS X, his favorite operating system. He doesn't give any damn how much money you are going to lose because his advice or about yourself. All he cares is that you pay more to his favorite companies, like Apple. Obviously he says this is a rant, and a rant is just a rant, nothing more.

Matt - 27th January 2005 02:42 - #

Wow, I guess that's me in a nutshell :)

Simon Willison - 27th January 2005 03:18 - #

You are more than that actually. You are someone who never should be taken seriously. You say

It's not inconceivable to argue that this was the main reason they added so many weird little proprietary DHTML extensions to IE in the following years - and it's those that are the root of the problem

but then here http://www.sitepoint.com/blog-post-view.php?id=222 195 you argue

Loading additional data interactively from the server has been a dream of client-side developers for years, and XMLHttpRequest finally provides an "official" method for doing exactly that (previous remote scripting efforts had revolved around ingenious hacks.

You are supporting XMLHttpRequest mostly because you want to believe that Microsoft lost the war or something, though even that is wrong. Facts:

• XMLHttpRequest is totally non-standard and is a proprietary DHTML extensions to IE
• XMLHttpRequest is first introduced in IE by Microsoft
• IE has a lot more proprietary DHTML extensions that people find interesting, useful and productive.

Simon either has no clue about these facts or simply want to deny them. In any case, following Simon's advice will only bring you doom. Because he was (and he is) saying that using XMLHttpRequest is bad, but when Google or your competition use it and get more customers, Simon changes his mind and simply forgets what he is saying. In other words he does not know what he is talking about at all.

Matt - 27th January 2005 06:06 - #

Hey, I recognise that breathless indignation and accusatory tone. It's Alex Almeroth, a.k.a. Keskos again, isn't it? I would have thought that you'd have stopped trolling when people put your parents' contact details up at Channel 9. Oh, and I looked for the book you claimed to have written on Javascript, but it doesn't seem to exist.

Having got the obligatory troll baiting out of the way, I can move on to my real point. I think people are confusing two separate issues. Jim Ley and LQ mentioned it briefly. There is a difference between writing to standards and supporting multiple web browsers. You can write to web standards and still only "support" Internet Explorer. You just have to use the subset of code that works in both.

Using support costs as a reason to avoid writing to standards is a non-argument.

At the end of the day I don't care that certain DOM objects and functions are proprietary or non-standard in IE - Microsoft have simply got the formula right, and it also performs a darn sight better than Firefox too.

You should care, even if you end up using proprietary Internet Explorer behaviour. Your action has locked you into a single vendor for everybody who needs to use that application, and that in turn locks them into the subset of software that works with it. That's a big business risk, and even if you end up taking it, you still have to acknowledge it exists. Sticking your head in the sand only makes the risk grow.

Jim - 27th January 2005 10:17 - #

Sorry if I have sounded like a troll, which internet seems to have many, but I am really angry at Simon, because the point should not be Microsoft bashing, if the goal is to prevent vendor lock-in. The only way you can prevent lock-in is by being better than or at least as competitive as the competition, not bashing them. There is a huge difference, because every time someone asks for a feature available only for IE, Simon makes conflicting statements, and the whole point becomes Microsoft bashing and we forget about those needed features because Simon depicts them as Microsoft proprietary solutions. This was my main point.

Matt - 27th January 2005 12:05 - #

I'm not sure why anyone should be angry at Simon; I don't see anything in the post that could reasonably be described as "Microsoft Bashing". Indeed, his central point is more reasonable than many commenters have given him credit for.

Presumably, the idea of intranet applications is that they should provide information and services required by (or at least avaliable to) all members of an organisation (if that's not a requirment then why are you using HTML at all? Something like XUL provides much more in the way of widgets and functionality). In any reasonably sized organisation, there will be heterogenous computing environments; most people using Windows, graphic artists using Macs, people doing scientific computations under Solaris, or whatever. Even if you're a windows-IE-only shop at this point, it is likely that your needs will diversify at some point in the future. So, it makes sense to try and make your app as browser-antagonistic as is possible and you should avoid using browser-specific features as a matter of policy - in the same way that users of every other standards-based development system try to avoid compiler/runtime specific technologies. That means both avoiding proprietry DOM functions and producing valid, easilly parsed HTML. Incidentially, the same thing applies to those parts of DOM that are well specified but poorly implemented. I would be concerned about using DOM3 XPath in a WebApp since only Mozilla supports it - better to work around the problem with simpler DOM methods.

Trying to avoid proprietry features isn't the same as running QA for every browser in the universe. It doesn't avoid the possibility that the app may only work on one browser. But it does mean that when the need arises to have your Mac users access it from Safari (or whatever), the modifications needed should be cheap and painless (or at least moreso than where no consideration has been taken of the likely need to run the application in a different browser in the future).

In the specific case of XMLHttpRequest, as of 2005, it is a defacto standard. The W3C may not be working on it but others are hoping to pick up the slack. It's very unlikely that a new browser (with decent DOM support) will be released without this feature. So, if you know that all your Macs will have XMLHttpRequest supporting versions of Safari and so on, it's OK to use (in the same way that the equally unspecified "DOM0" is OK to use).

jgraham - 27th January 2005 13:18 - #

In the specific case of XMLHttpRequest, as of 2005, it is a defacto standard. The W3C may not be working on it

They aren't working on it because the Recommendation that covers this functionality was published early last year. Gecko, Opera and KHTML all have implementations.

Jim - 27th January 2005 13:37 - #

So, it makes sense to try and make your app as browser-antagonistic as is possible

I assume you mean browser agnostic? Being browser-antagonistic is precisely what Simon is arguing against :).

Jim - 27th January 2005 13:39 - #

The only way you can prevent lock-in is by being better than or at least as competitive as the competition, not bashing them.

Actually, no. You can also be open, and argue that openness is a better long term proposition. Of course, it helps to be arguing on the side of short-term (as in, quarterly) economics, too.

Jeremy Dunck - 27th January 2005 14:00 - #

I assume you mean browser agnostic? Being browser-antagonistic is precisely what Simon is arguing against :)

Of course :)

They aren't working on it because the Recommendation that covers this functionality was published early last year. Gecko, Opera and KHTML all have implementations.

Of course, one could use that instead. In general, the W3C would be better off standardising technologies that have implementations rather than trying to foist new technologies on a browser market with a lame leg.

jgraham - 27th January 2005 14:07 - #

LQ, nice mathematical approach to a blog comment, heh. I think your venn diagram is missing a few circles though.

It is and it isn't. WRT IE-only functionality, ya makes yer choice and lives with it. There's always a platform/browser-agnostic way to get it done, but if in-house talent ain't hip, it may indeed be more expensive in the short-run.

Regarding rendering differences, there's also always a way — just depends on how much pixel-perfection you actually need. I'd submit that end-users rarely need as much pixel-perfection as UI designers seem to want. Jazzy DHTML expando-rollover-widget-things are rarely more effective than a well thought-out, styled list of links. But hey, everybody has a boss (and a budget) and every boss has expectations.

At bottom, one either cares about avoiding lock-in or one doesn't. I'll simply re-state that allowing it is a choice that's become harder to defend, within a context of honestly-considered needs. Your mileage may vary.

Which means I agree with Simon, and his implied stance that there's greater elegance (and portability, and freedom) in "less" than there is in "more."

LQ

Lou Quillio - 27th January 2005 15:39 - #

"Don't get me wrong, I think Firefox is doing a lot of good, and hopefully it will force MS to build in full PNG support and CSS2.1 into IE. After that happens, hopefully IE will dominate, and we won't ever have to test across 4 browsers again." - Chris Beach.

Firstly, there is no way IE will ever dominate again. The market has moved away from mostly-desktop (and MS didn't dominate fully there anyway, there were always competitors). Now we are facing a future based around mobiles (cellphones) and more. There is no doubt that MS do not own all these devices, so IE will not always be running on them. I also foresee things not yet invented, like wearable computers and bendable screens, that will allow true portable computing.

As for not testing on 4 browsers ever again, well there have (as I said above) always been more than just IE. Even at IE's height, there was a strong following for Netscape. Now we have dozens of browsers people could use. Can you see where this is leading?

You wish to develop for one platform only. Well make that platform "standards"! OK, there are lots of things that only work in IE, some of them damn cool, like DHTML tricks and image filters. But by following standards, you guarantee at least 90% of your code will work, probably first time too, in a wide range of browsers - and platforms like Mac and Linux! So there is a lot less to worry about, and millions more people can access your code.

I personally hate shopping sites that only work in one browser! What a way to lose sales.

The only cross-browser problem is, as you detail, poor JavaScript support in browsers. But this is improving all the time. Also, it pays to use code that does work for most browsers, not IE-only JavaScript, which is plain silly.

Chris Hester - 27th January 2005 16:02 - #

In general, the W3C would be better off standardising technologies that have implementations rather than trying to foist new technologies on a browser market with a lame leg.

The W3C's specifications are not aimed solely at the browser market, that is just one potential area that the DOM Level 3 can be implemented. The W3C's specification for Load/Save has much broader appeal and isn't tied to the HTTP protocol, it's not really equivilant.

It's also worth noting that the DOM Level 3 was planned before XMLHttp was introduced by Microsoft and has been under development for many years, it's not like the W3C chose to use their own instead of Microsoft's implementation because of 'not invented here' syndrome.

Mike - 27th January 2005 16:27 - #

Firstly, there is no way IE will ever dominate again. The market has moved away from mostly-desktop (and MS didn't dominate fully there anyway, there were always competitors). Now we are facing a future based around mobiles (cellphones) and more. --Chris Hester

Well interesting that you seem to have forgotten Microsoft's Windows CE, PocketPC and Smartphone OS's here. I've been using Windows / IE on PDA's for years, and IE on my smartphone for the last year. I've found it to be much more useable than the alternatives on Symbian based smartphones and my dad's Tungsten (PalmOS) PDA didn't even come with a web browser as standard.

I think it's very likely that MS will dominate the mobile device market (if they're not already) as well as the home entertainment PC market (Media Centre has been a huge success)

I think it would be foolish to ignore Firefox and Safari during QA. However, we musn't forget that "Locking oneself" to a single vendor is what businesses do all the time. It certainly makes sense to lock down to IE on a corporate intranet, since it's remote administration and COM extensibility make it a technically sensible choice.

Chris Beach - 27th January 2005 17:18 - #

Lol, my innocent comment is taken at face value. I guess I have to write in super-geek to make sense! I'd like to clarify I'm a hardcore developer, not merely a user. And yes, Firefox only has one benefit while I'm working - that of viewing source in https. The crowd has spoken - IE has taken over, a browse through the UserAgent referrals in your web access logs will clarify the same. If we're talking OS/closed source browsers, both have benefits. The simplistic notion that Mozilla adheres to open standards and remains open source doesn't mean it's elevated to Messiah status. The reason many good applications are closed source is because their inherent features are unique, and very useful. To support Chris Beach - a vendor gives you the power to create a baseline - and in anything other than browsers, licensing - to meet a contractual obligation which gives you dedicated and relevant patches and upgrades that enables you to be even more successful in a deployment of applications. Lach - you say standards-based browser code lets one switch platforms. LOL! What platforms!? It's just a presentation layer!

Amit - 27th January 2005 18:17 - #

Normally I like to just lurk and the whole nine yards, but posts like this--while good, informative and justifiable (sp?) in a lot of ways--really piss me off as well. I would heartily agree with all of what Jim Ley said. Frank, you may be correct in some ways, but if your internal apps were based on XMLHTTP at all two years ago, then you *had* to choose one or the other.

Not only would I point at the QA costs, but I'd also point at the support costs. Do any of you really know how much it costs to run a help desk? Take those person's salaries, plus equipment, plus training and add them up. Now take into account the additional training it takes for someone--usually not the sharpest tack in the world (no offense meant)--to support more than one browser platform.

Now take the cost of the actual developers to create those applications.

Get the picture yet?

Who ever said anything about XMLHTTP? I know I didn't. But I will agree that if we had been using it, then yes we would have had to choose. And yes I work very closely with our help desk manager (he used to work for me as a sysadmin). I can assure you I get the entire picture, considering in my organization I am responsible for half of this picture (development/QA).

We've got people using various versions of Mozilla, Firefox, and Safari on various versions of Windows, Linux, and Mac OS and I don't remember any serious extra QA or support costs that are related to this. Maybe we are just lucky or maybe we have SuperHuman(tm) staff.

What I don't understand (not trying to troll/flame here... am seriously asking) is how much does it really take to "support" a different browser? It's about the simplest piece of software there is. If you have to send your help desk staff to formal training on how to use say Firefox when they are used to IE (or vice versa), you just simply need to hire better support staff.

Maybe I just have higher expectations of people than is really feasible in other environments... either that or I need to start writing up a Firefox training session I can sell. I can see it now Day 1: Launching Firefox, Day 4: Tabbed browsing, etc... :)

Frank Wiles - 27th January 2005 20:10 - #

Frank, it's not a case of training users how to use a browser. That's not the issue at all. The problem is predicting how the various browsers will respond to different combinations of HTML/CSS/JavaScript. They don't all respond in the same way, since they all use different rendering engines and interpreters.

Web app development can be quite a rapid process, and unfortunately web browser development also seems to be a rapid process these days. The more browsers, the more testing needs to be done for each part of a web-based system, and that takes time and money. For lone programmers it's no problem, I'm sure. Maybe some consider it fun. For businesses it's a pain.

Chris Beach - 27th January 2005 20:44 - #

For lone programmers it's no problem, I'm sure. Maybe some consider it fun. For businesses it's a pain.

Take a hard look at what Holovaty (and Willison) have done at ljworld.com and related sites. Corporate and user-agent agnostic. An astonish achievement and proof-of-concept. Load it in a WAP phone or PDA. Still works. Not a layout table in sight.

This work doesn't get enough attention.

LQ

Lou Quillio - 27th January 2005 21:00 - #

My xmlHTTP RSS reader project. Any hints how I can make this work under FireFox? http://members.home.nl/cybarber/OPMLXMLHttp.htm

cybarber - 27th January 2005 21:15 - #

Any hints how I can make this work under FireFox?

For an intranet application, try this. Don't count on it for the public web, though. Hell, don't even think about it.

LQ

Lou Quillio - 27th January 2005 21:28 - #

Lach - you say standards-based browser code lets one switch platforms. LOL! What platforms!? It's just a presentation layer!

Huh? If you'll actually bother to properly read what I wrote, I said browsers or platforms. If you ever do switch platforms, and you're currently using IE, you will need to switch browsers, essentially.

In any case, the context of this entire discussion is applications development using web browsers, using technologies such as XMLHttpRequest, among similar JavaScript. In this context I fail to see how anybody could possibly think the browser is no more than a presentation layer.

I'd love to stay and chat, but I doubt a smug troll such as yourself really has anything to add, especially considering the massive revisionism you undertook in your last comment to refrain from appearing to be wrong.

Lach - 28th January 2005 02:23 - #

Sigh. Frank, let me point out the important bit of what I said:

...Frank, you may be correct in some ways, but if your internal apps were based on XMLHTTP at all two years ago, then you *had* to choose one or the other...

See, the point I was making isn't that "FF sucks, IE rulez! and all y'all suck 'cause you're hating on m$"...no, the point I was making is that two years ago if you were an IT manager dictating the direction of development, odds are you would take a look at the state of browser development, notice that while Moz had a lot of potential it was still in a basic beta phase, and decide that it would be prudent from a cost standpoint to limit internal application dev to IE. I didn't agree with it in the situations that I found myself in (for many of the same reasons Simon mentioned), but there you have it.

As far as best practice now, yes, absolutely--if you aren't dev'ing cross-browser, you're shooting yourself in the foot. But it's far easier to do that now than it was 2 years ago.

BTW, the SVG working group has slipped a spec into the 1.2 draft for a NetworkRequest object, which is essentially XmlHttp without some of the extraneous properties. And the reason why no one has implemented Load/Save is because it's a poor solution; XmlHttp is quite a bit more flexible because it doesn't tie the comm layer to the document.

Tom Trenka - 28th January 2005 04:52 - #

My xmlHTTP RSS reader project. Any hints how I can make this work under FireFox?

I only skimmed the code, but I didn't see any problems. You do realise that Firefox provides the exact same XMLHttpRequest object, and that the only difference is in how you instantiate it? Consult pretty much any XMLHttpRequest tutorial. I believe Jim Ley wrote a decent one.

odds are you would take a look at the state of browser development, notice that while Moz had a lot of potential it was still in a basic beta phase, and decide that it would be prudent from a cost standpoint to limit internal application dev to IE.

There are more than two browsers, you know.

And the reason why no one has implemented Load/Save is because it's a poor solution;

What are you talking about? Microsoft haven't implemented Load and Save, but all the other major browser developers have.

XmlHttp is quite a bit more flexible because it doesn't tie the comm layer to the document.

What do you mean "tie the comm layer to the document"? Load and Save works in much the same way as XMLHttpRequest.

Jim - 28th January 2005 12:54 - #

"The problem is predicting how the various browsers will respond to different combinations of HTML/CSS/JavaScript. They don't all respond in the same way, since they all use different rendering engines and interpreters." - Chris Beach

Regarding HTML and CSS specifically, if you code to the standards, you'll find browsers generally work in the same way. Yes there are minor issues that may require subtle hacks. However, if you were to code using things like 'bordercolor' and image filters, you'll only get satisfactory results in IE. The only way to code is by following the standards as much as possible. That way, future browsers will also work with your code 9 times out of 10. If they don't, it'll only be an odd line of code here or there to tweak.

I agree that each browser has a different rendering engine. But they become largely invisible when coding to standards. (Unless you code massively complex pages I guess.) The exception is JavaScript, where browser support isn't equal.

To make just one point about this, it's like asking yourself - do you want to code for the past? Or for the future?

Chris Hester - 28th January 2005 13:20 - #

This article on Evolt is worth reading: Why standards-compliant HTML matters. From it:

"In some cases, you might decide that the standards-compliant route is too expensive and too troublesome for your project.

Building for an intranet with a very controlled park of machines and browsers is not really an argument against standards-compliant building, but may only be considered in combination with other, more compelling factors. Indeed, while designing for one browser may save a bit of effort, or provide extra possibilities, it also increases the reliance of the site on external factors you have no control over: not only could the browsers change, following a company-wide policy reversal, but the company making the browser could choose to evolve the software's technical characteristics in future versions. With standards-compliant code, you're safe in both cases."

Chris - 28th January 2005 15:03 - #

See, the point I was making isn't that "FF sucks, IE rulez! and all y'all suck 'cause you're hating on m$"...no, the point I was making is that two years ago if you were an IT manager dictating the direction of development, odds are you would take a look at the state of browser development, notice that while Moz had a lot of potential it was still in a basic beta phase, and decide that it would be prudent from a cost standpoint to limit internal application dev to IE. I didn't agree with it in the situations that I found myself in (for many of the same reasons Simon mentioned), but there you have it.

I guess I must have been playing in a different casino! As I was the IT manager dictating the direction of development and went with Mozilla over IE. I still however find it hard to believe that IE development 2 years ago was cheaper than Mozilla and/or standards based development. It may have limited your feature set, made the applications a touch harder to use, less whiz bang, etc.... but it certainly was not enough to make the application a failure.

However, I will agree that most managers did not do this, and now they unfortunately are having to rewrite or stay with IE on their desktops.

Frank - 28th January 2005 15:11 - #

What do you mean tie the comm layer to the document? Load and Save works in much the same way as XMLHttpRequest.

Except that its a set of methods on a document. I don't know about you, but I'd rather have a communications layer that was not tied to anything but the communications layer when I'm trying to code an application. And I'd submit that this would be one of the main reasons XmlHttp is much more popular than using Load/Save.

There are more than two browsers, you know.

Once again, I will point you at the statement two years ago; while we have 3 major browsers available now (and a fourth poised to join them as soon as Opera gets it's sh*t together and fully implements the JS bindings everyone else has), two years ago we had IE, Moz in a perpetual beta phase, no Safari, and a very limited (as an app platform) Opera. Not to mention everyone's favorite whipping browser, NN4 :)

Tom Trenka - 28th January 2005 15:17 - #

Except that its a set of methods on a document.

You're complaining that you have to obtain the DOM implementation from a preexisting document object? I don't see how that limits you in any way whatsoever. Perhaps you could post some sample code to demonstrate what XMLHttpRequest can do that is difficult to achieve with Load and Save?

two years ago we had IE, Moz in a perpetual beta phase, no Safari, and a very limited (as an app platform) Opera.

Mozilla 1.0 was released two and a half years ago, so I don't see where you are getting the "perpetual beta phase" slurs from.

Take a look around at typical web applications. The typical web application doesn't need anything that an Opera of two years ago didn't have.

Sure, there are exceptions, like when you need to manipulate images on the client-side, but for the vast majority of web applications, all you need are a few forms and server-side smarts.

Four or five years ago, I was implementing dozens of cross-browser web applications that were working in Netscape 4.x, for a fairly diverse selection of clients. You can't tell me it's impossible.

Yeah, it's nice to not have to do page reloads to get more data and things like that, but it's hardly a good enough reason to lock yourself into a single browser and a single platform. And XMLHttpRequest was hardly revolutionary, you could do similar things with inline frames years beforehand.

Jim - 28th January 2005 16:49 - #

Inline frames were a very hacky approach to asynchonous calling.. hardly seems fair to compare them to the XMLHttpRequest approach.

Chris Beach - 28th January 2005 17:08 - #

I make GUIs for IE-based internal and external Web applications. A large scale x-browser move is not in the predictable future of the software development world.

Corporations do not make decisions for quasi-religious reasons such as "Web Standards." Software life-cycle costs are paramount -- followed by concern for predictability in the technical environment. On those reasonable counts alone, Windows IE will remain dominant for a good while.

A good case can be made that x-browser HTML and CSS standards could decrease development and maintenance costs in certain ideal circumstances. I am convinced this is true. But here are some stubborn, non-ideal circumstances...

• Costs of retrofitting: My team has over 20 internal and external apps to maintain. Bosses once asked me how much it would cost to convert and test to reasonable support for Mozilla. They choked when I gave the estimate for the structural HTML and scripting alone. Yes, even accepting that maintenance costs could end up lower, the initial retrofit expense can be a killer.
• Training and tools: Sure, I code to standards (as I understand them at any particular time) but has every GUI person and programmer on the team for the last 5 years done the same? No way. Tools also distort the picture since most of them still are optimized for table soup. We moved to CSS for positioning 5 years ago. The only competing browser then was Netscape 4 and anyone who placed bets on that POS got what they deserved.
• Future support: The last time someone on the team suggested support to Mozilla-based Netscape, AOL announced that it was abandoning the code base. No software manager anywhere is going to bet their career or company viability on a browser platform that does not have solid backing and solid prospects.

On the other hand, Microsoft's failure to update its ancient browser is probably the only factor that allows this debate to take place at all.

Brett Merkey - 28th January 2005 18:49 - #

Inline frames were a very hacky approach to asynchonous calling.

I agree. They work for many purposes though and are compatible with more browsers than XMLHttpRequest and DOM 3 Load and Save.

Corporations do not make decisions for quasi-religious reasons such as "Web Standards."

Conforming to published specifications and avoiding single-source solutions are reductions in business risk. Virtually every industry except the computer software industry understands this. Characterising it as "quasi-religious" is incorrect.

Costs of retrofitting: My team has over 20 internal and external apps to maintain. Bosses once asked me how much it would cost to convert and test to reasonable support for Mozilla.

This is Simon's point. If you hadn't written them to be Internet Explorer-only, there would be no retrofitting costs.

Future support: The last time someone on the team suggested support to Mozilla-based Netscape, AOL announced that it was abandoning the code base. No software manager anywhere is going to bet their career or company viability on a browser platform that does not have solid backing and solid prospects.

This is an argument against specifying Mozilla as the standard browser for an organisation. This is not an argument for or against writing software that depends upon Internet Explorer.

On the other hand, Microsoft's failure to update its ancient browser is probably the only factor that allows this debate to take place at all.

The issue is lock-in. Even if Microsoft released a web browser tomorrow that was twenty years ahead of the competition, it wouldn't eliminate the lock-in issues. IBM are having trouble switching to Linux because they wrote Internet Explorer-only applications. If Internet Explorer was better, how would that solve their problem?

Jim - 28th January 2005 19:08 - #

IBM are having trouble switching to Linux because they wrote Internet Explorer-only applications.

Please note that the supposed issue at IBM has been debunked by Mark Pilgrim above, who is an IBM employee.

Jeremy Dunck - 28th January 2005 19:20 - #

Yes, the issue here is that IE6 has been abandoned. (Egg on the face of all those who chose to support it only.) Meanwhile all the other browsers have a mountain-sized journey to get to the same market level. If IE6 had kept up, solved all its hideous layout bugs, implemented full PNG, CSS2 and HTML support, then I'd be a lot happier, as we could all code for the standards, no matter what browser we used. Instead we're stuck with a dinosaur for many years to come. Windows users aren't going to switch over to Longhorn and IE7 overnight - it could be a decade before IE6 becomes irrelevant. As Eric Meyer put it, "Great. Just great." (Or very similar words.)

Chris Hester - 28th January 2005 20:52 - #

If you hadn't written them to be Internet Explorer-only, there would be no retrofitting costs.

This does not conform to experience. Let's eliminate the real-world problem of retrofitting. Validated structural and presentational code and script will often look or behave differently in different browsers in ways unacceptable in a business environment. Work, work done by coders with an awareness and costly skill beyond the average, is necessary to attain this compatibility. The posts to the CSS-Discuss listserv daily expose the hidden reefs we sail into.

This reality cannot be ignored and it is not ignored. Thankfully, the Mozilla people who came down from the mountain and supported innerHTML and other proprietary CSS or script conveniences are numbered among these people.

If Internet Explorer was better, how would that solve their problem?

IBM's problems are not mine. A better IE would solve my problem by making work easier for me and application development cheaper for my many bosses.

Brett Merkey - 28th January 2005 20:53 - #

IBM's problems are not mine. A better IE would solve my problem by making work easier for me and application development cheaper for my many bosses.

Would it do anything for that myopia you appear to be suffering from?

Aankhen - 29th January 2005 06:55 - #

I think Firefox still lacks, like something as trivial as writing text vertically.

https://bugzilla.mozilla.org/show_bug.cgi?id=14550 3 is getting almost 3 years old, and excuses like the text layout spec of css3 is ambigous, so they cant implement it.

I doubt the web would have gotten anywhere if everyone waited until all the ambiguities of HTML, CSS etc were resolved by W3.

Just take a stand, and get something done. Like Microsoft did, IEs writing-mode isnt complete or perfect, but it works.

I presume also, that you also believe the reverse, that developing web applications with XUL/XBL and other single vendor solutions is also a bad thing.

Ren - 30th January 2005 03:03 - #

I doubt the web would have gotten anywhere if everyone waited until all the ambiguities of HTML, CSS etc were resolved by W3.

Instead we have browsers like Internet Explorer, every Web developer's nightmare.  Is that so much better?

I presume also, that you also believe the reverse, that developing web applications with XUL/XBL and other single vendor solutions is also a bad thing.

IMHO, the ideal thing to do is to not use a single-vendor solution.  However, developing an application with XUL/XBL is still much less limiting than developing an IE-only application for the simple reason that Mozilla is cross-platform and open source, and the Mozilla Foundation is a not-for-profit organisation which simply wants to develop the next generation of browsers, whereas Microsoft's (oft demonstrated) goal is to lock you into using their tools.

Aankhen - 30th January 2005 05:42 - #

I presume also, that you also believe the reverse, that developing web applications with XUL/XBL and other single vendor solutions is also a bad thing.

I think this raises a good point. Should XUL/XBL apps be considered web apps? How about apps that embed and interact with the web? Is a web app only one which adheres to the WWW Arch? While we're trolling the other guy (very similar to the MFL is better than YFL debate, here), it's useful to point out that intranet sites were rarely made because they're web apps, but rather because they minimized deployment headaches.

If Java WebStart had sucked less at the time, maybe it would have gone that way instead. Except that it requires you knowing Java, which is a bit higher knowledge than HTML and Perl/PHP(/...) requires.

Instead we have browsers like Internet Explorer, every Web developer's nightmare. Is that so much better?

Actually, it is. I expect we'll all agree that the web is useful despite the incompatibilities discussed here.

Jeremy Dunck - 30th January 2005 14:42 - #

Actually, it is. I expect we'll all agree that the web is useful despite the incompatibilities discussed here.

You're right, that was too much melodrama. :-P I have to say, though, everytime I try to adapt fully functional (in Opera and Mozilla, at any rate) JavaScript to work with IE, I find a new reason to hate it. Anyway, that's digressing from the point. I think. Right?

Aankhen - 30th January 2005 17:25 - #

Sure, there are exceptions, like when you need to manipulate images on the client-side, but for the vast majority of web applications, all you need are a few forms and server-side smarts.

I think we're getting into assumptions here about what constitutes a web application and what not; I (probably) have a much different opinion on this than most of the commenters here, so we'll just leave it at that.

Conforming to published specifications and avoiding single-source solutions are reductions in business risk. Virtually every industry except the computer software industry understands this. Characterising it as "quasi-religious" is incorrect.

I'll mention that the majority of other industries have two things going for them that the software industry does not: localized standards (i.e. by country or continent), and the force of law (usually) backing them up. The big example I'm thinking of right now is construction code, but IIRC there are plenty of other examples as well. If there's no law to back it up, there are other standards organizations that have somehow made it worth a company's while to conform to those standards (thinking UL here, although I'm sure others may have better examples).

The basic point is that the standards from the W3 are not enforced. We may think that writing standards-based code is a good thing, and usually it is; but there are times (especially in a closed environment, such as most intranets) where dictating the platform (whether that's IE or Moz, etc.) is the most cost-effective solution, simply because the implementation of those standards are not standard :)

As far as XmlHttp vs. Load/Save goes, if you have no issue having to establish an entire document in order to open a communications channel, then more power to you. Personally if I'm not operating on a document, I see no reason to instantiate one. Oh, and even though Moz 1.0 was out 2 years ago, it was still lacking in a lot of things (like XmlHttp, which wasn't there until, what, v.1.2?)

Tom Trenka - 31st January 2005 18:18 - #

hmm... this seems all too heavy. There is a time and place for everything.

bleeper cutie - 2nd February 2005 06:53 - #

With all of these other applications available, Microsoft is still a monopoly in most everyone's eyes. How's that? No one has a gun to my head telling me to use IE. No one's forcing me to use ANYTHING Microsoft. Same goes for everyone else. But, still, people love to call them a monopoly. I call it jealousy. FF is wonderful. I hope it succeeds. Thats the way the market should work. And its what Gates has said he feared all along -- anyone in a garage could develop something that CAN take down that company. Maybe we're beginning to see that. Maybe not. The mere popularity of FF right off the bat shows that Gates IS right again. People should switch to it because they like it and it works well for them, not because they think Microsoft has too big a market share. Thats the wrong motive. The sword cuts both directions people.

Anthony - 5th February 2005 02:58 - #

â??IBM are having trouble switching to Linux because they wrote Internet Explorer-only applications.â??>

As Mark pilgrim said above, this is highly over blown. Yes, there are a few applications that were designed specifically for IE, but most have been generalized for standards based browsers and tested in the browsers the company preloads on employee systems. A few stalwarts remain, but they are being changed one by one.

Our (Like Mark, I am an IBM employee) internal standards were updated about two years ago. They used to dictate designing and testing in IE, the only preloaded browser at the time. I drove a change in the standards to design for "any standards based browser." A short while later a visual design update, along with a move to structured HTML and CSS positioning, started a revision cycle for all applications. That cycle is now nearly complete, leaving the InfoWorld article sadly incorrect.

Yes, applications designed for IE have been an impediment. However, they are definitely not the barrier to moving to Linux on the desktop. That, dear friends, is another story.

Bob Easton - 5th February 2005 22:53 - #

Normally I wouldn't even bother saying anything but as the likes of Mr Trenka have (above) I will.

Basically; I would like to dissent and state that I make web apps for IE-only most of the time. There is no inherent reason a web application should conform to any standard whatsoever.

All this procrastination is irrelevant. In case you didn't realise (apparently not...) the only standard is the browser itself in this paradigm.

Tim Scarfe - 7th February 2005 00:25 - #

Tim, another Tim created the web because prior to that, computers (and their data) largely did not interoperate. The idea was that by giving a platform independent representation and protocol, research and the advancement of knowledge would be improved.

The web has grown far beyond CERN, but the value of the web is yielded largely by the interoperability it offers.

Fragmenting the web diminishes the network effects. There is an inherent reason a web application should conform to open standards.

Jeremy Dunck - 7th February 2005 05:18 - #

I think you are missing the point.

A web application is effectively a bespoke application (not unlike an application written in C++) and it can target any platform or standard. There is no inherent mandate whatsoever to support W3C web standards in a bespoke web application.

I don't want a platform independent solution, my platform is Microsoft. Is it really that difficult to understand?

Tim Scarfe - 7th February 2005 13:42 - #

Well, I don't understand what you mean by bespoke in this context.

I started to write something inflamingly strong: "But if you target a specific application, then it's not a well-designed web application."

Ah, well. I'm sure this is a software world issue. I will point out that if deployment is the only problem you're trying to solve by using HTTP and a web browser, .Net really does a nice job of solving deployment problems while providing a much better set of native features.

There are good reasons for writing internal web apps to a specific browser. I also think that many internal apps are needlessly browser-specific.

Right.. I'll go pour gas on a campfire now.

Jeremy Dunck - 7th February 2005 15:37 - #

"I also think that many internal apps are needlessly browser-specific."

I would actually say that people like you make applications needlessly browser-unspecific. You would invest all that extra development/testing time when you could just create a policy on browser usage instead. That's not a sound business decision.

Anyway just wanted to make the point, thanks for listening.

Tim Scarfe - 7th February 2005 16:21 - #

A web application is effectively a bespoke application (not unlike an application written in C++) and it can target any platform or standard.

You appear to have well and truly missed the point of a Web application, i.e. working anywhere which has access to the Internet and a decent browser.  It is unlike a C++ application.

There's nothing wrong with coding only for one platform.  That's the way applications have been written for years.  Just don't call it a Web application.

There is no inherent mandate whatsoever to support W3C web standards in a bespoke web application.

Neither is there any inherent mandate here to speak English rather than Pig Latin.  Would it benefit anyone here if I started?

Aankhen - 8th February 2005 08:20 - #

"You appear to have well and truly missed the point of a Web application, i.e. working anywhere which has access to the Internet and a decent browser. "

No. I haven't missed the trick.
I think here you are making the distinction between an in-house Business Management System type application and more publicly available applications. I was referring to an application where the users could be subject to a corporate policy on browser usage. I am not suggesting that something like friendster.com should be IE-only...

Tim Scarfe - 8th February 2005 10:40 - #

You would invest all that extra development/testing time when you could just create a policy on browser usage instead.

Indeed. However that doesn't play to the strengths of HTML-based solutions. The strengths of HTML-based solutions are cross-platform interoperability, rapid development, and vendor-neutrality. If you choose to enforce a standard browser, you throw away the third of these. If you choose to enforce a single-platform standard browser, you throw away the first too. Long term, your policy choice could make it difficult or expensive for some section of the company to use a new platform which might be much better suited to their needs than the platform your standard browser runs on.

As ever when making economic choices, there's a lot more to consider than immediate cost

Suppose you decide that what you want really is a single-vendor solution to your problem. Why choose HTML+javascript as a platform? There are other platforms that will offer a much better feature set (better GUI toolkits, better libs, etc.) compared to HTML. Using HTML but ignoring all the benefits of the platform in favour of a solution that exposes the weaknesses seems a little odd.

jgraham - 8th February 2005 14:15 - #

You're entitled to your opinion.

Tim Scarfe - 8th February 2005 14:25 - #

I think here you are making the distinction between an in-house Business Management System type application and more publicly available applications. I was referring to an application where the users could be subject to a corporate policy on browser usage. I am not suggesting that something like friendster.com should be IE-only...

Fair enough. Would have helped if you'd said so earlier. :-)

IMHO, tying yourself to one particular platform, even for a small internal application, is not a great business decision, but it's something that, ultimately, is a business's decision to make, not mine.

Aankhen - 8th February 2005 17:41 - #

Haven't read all the comments, but i disagree with "The wonderful thing about web applications is that they free you from being tied down to a specific platform" because; I can write a web application if i need a program to simply display simple data to the user, i.e. that doesn't require much interaction. Why the hell would i mess with a GUI toolkit if i could simple handle a http request and send some quick-n-dirty html back?

Gabriel - 27th February 2005 19:31 - #