You're wrong, and you've completely missed the point of ActiveX and XPCOM.
They are both systems for defining interfaces that hide the way you implement services. ActiveX says nothing about which API you use to implement the interfaces with. The whole point of ActiveX and XPCOM is to separate interface from implementation.
ActiveX runs on MacOS, OS/X, Linux, Unix, without any Win32 api dependencies, and on Windows, where you can develop ActiveX controls with or without Win32 and MFC dependenceis.
I don't understand your argument about "making use of the windows api in linux is about as good as using POSIX on windows". Haven't you ever heard of cygwin? That's pretty good, and I use it all the time.
I also don't understand your argument about "To add activeX to gecko's windows codebase would just spilt the userbase".
You sound like those Loki appologists who argue that Wine is evil because it discourages people from developing games for Linux. If it solves some people's problems, then what's your beef with it?
You really should read the article -- you're totally missing the point.
Old browsers didn't support 128 bit encryption, so Korean banks developed their own encryption algorithm (SEED), which all their financial services now use. Firefox does not support SEED, but Internet Explored does support SEED via an ActiveX control.
If Firefox supported ActiveX controls, then Firefox would support SEED, but it doesn't. The 128 bit encryption built into Firefox will not solve their problem, because they need to use SEED. They developed SEED because the US government prohibited the export of strong 128 bit encryption at the time Korea deployed their online banking system.
They can't just decide to change their encryption algorithm overnight, so using SSL is simply not an option right now. The ActiveX control solution already exists, and works just fine for 95% of the people. It's nice that they finally support Firefox via XPCOM, but if Firefox supported ActiveX as an option in the first place, then all those Firefox users who needed to do online banking wouldn't have had to wait till now.
ActiveX and XPCOM are similar technologies, and they both have the same security problems and limitations, but they're different enough that somebody has do some programming to repackage the encryption module as an XPCOM control instead of an ActiveX control. If Firefox had an option to support ActiveX at the user's request, then extra effort and delay would not be necessary.
It would take a lot less work to make Firefox support ActiveX, than it would require to rewrite every ActiveX control so it supports XPCOM.
In case you haven't been paying attention, the whole point of this plug-in is to work around the problem that 128 bit encryption is NOT provided via SSL.
Please read (and understand) the article before posting, next time.
By the way, AJAX is not the solution to every problem.
Thanks for trying out, but you can't be a cheerleader if you don't do your homework.
The ActiveX Specification is freely available for anyone to implement. In case you didn't know, XPCOM is just an open source knock-off of ActiveX, with enough gratuitious changes to make them incompatible in practice. But essentially, they're the same thing.
XPCOM is no more secure than ActiveX. They both have total access to your computer. It's irresponsible of you to spread the misinformation that XPCOM is more secure than ActiveX, when it's not. It doesn't help anyone to have a false sense of security based on well meaning hype and uninformed cheerleading.
You're right that both ActiveX and XPCOM are more functional than AJAX (for some definition of the word "functional" -- in the sense that it has more client side functionality).
Perhaps Firefox should include support for ActiveX? There's nothing stopping them, really.
So then it wouldn't have been necessary for to write a special XPCOM control, since they could have used their original ActiveX control.
Oh yeah, I forgot, it's more important for Firefox to make a rhetorical point by excluding ActiveX support, than to serve the needs of its users. That's called cutting off your nose to spite your face.
You have completely missed the point, which is to use 128 bit encryption over the wire, because the encryption built into the browser is not strong enough.
Are you proposing implementing the encryption on the server side, and sending passwords over the net unencrypted?
Or are you suggesting they implement the 128 bit encryption algorithm in JavaScript?
By the way, before somebody tries to point out that you can wallpaper over the deficiency of Array's push, pop, shift and unshift methods missing from IE Mac JavaScript, by dynamically defining new compatibility methods in array by going "Array.prototype.push = function (obj) { this[this.length] = a; }":
You should realize that adding a method or any other key to the array prototype breaks "for (key in array) {... }" so that looping over the keys in ANY ARRAY INSTANCE will return the method names you defined in the prototype as keys (although that behavior also varies between different browsers). So each and every one of your for loops have to get the value, check if it's a function, and ignore it.
Thanks a lot, JavaScript.
If you didn't realize that adding methods to array prototypes fucks up for loops in some browsers, then you're not qualified to program AJAX, because you're grossly underestimating the complexity of writing cross platform lowest denominator JavaScript that runs the same across all browsers.
AJAX evangelists are horribly hyping and outrageously overpromising the technology, strutting around like naked emperors, parading their ignorance of history and JavaScript programming.
I don't know where you've been for the past half decade, but Internet Explorer and most other major browsers and pre-installed operating systems are bundled with Flash, so Flash really is already installed on most browsers, thanks to the fact that it's so commonly bundled and easy to download and upgrade.
There is no other viewer more widely installed than Flash -- not even close. The runner up Acrobat is more than 10% behind Flash's installed base. Why do you think Adobe is buying Macromedia for so much money?
Flash Player Statistics:
Flash: 97.6%, Acrobat: 87.1%, Java: 86.5%, Windows Media Player: 84.3%, Quicktime: 64.1%, Real: 58.9%, Shockwave: 55.4%, Viewpoint: 49.7%, SVG: 12.5%. Flash Bundling Matrix:
Flash is bundled with Internet Explorer Win, Internet Explorer Mac, Netscape Win and Mac, AOL Win, AOL Mac, Opera, and with MacOS, Mac OS X, and Windows.
Your management is obviously stupid. My condolences. Not an unusual situation, but sad. Maybe you should look for another job.
You're totally wrong in stating that it's not that difficult to write code that runs in all browsers. Have you actually tried, or are you just saying that because you heard other people say it, and it sounds nice to repeat it?
Laszlo enables you to program Flash for free without buying any of Macromedia's tools.
The cost of trying to write cross-platform JavaScript that runs in all browsers is your precious time and the quality of your application. There are some things more expensive than money, and you're wasting them if you're trying to use AJAX without being aware of its limitations.
Flash is much more portable than AJAX, and it is much better technology, by far, and it's widely accepted, much more so than any other technology. Flash graphics are much higher quality and more capable than anything that's possible with dynamic HTML, and you know it. Just try to draw a diagonal line in DHTML.
I can't diagnose what your problem is with having to install Flash manually all the time on every computer you've ever used, but I've never heard of anyone else with that problem, so you're probably doing something wrong.
JavaScript is easy to learn as long as you only need to use one version of the language, which is the case with Laszlo. But the subtle and not-so-subtle differences between different JavaScript implementations are extremely difficult to learn, and you waste a huge amount of time finding those differences by accident and then having to test against every browser use a bunch of half-assed debuggers and popup alert statements to diagnose the problems and come up with work-arounds for each browser.
Were you aware that JavaScript in Internet Explorer for the Mac does not support the push, pop, shift and unshift methods on arrays? Instead of a.push(foo), you have to go a[a.length] = foo.
If that's a surprise to you, then you're not qualified to write cross-browser JavaScript code. If you're using Array.push, pop, shift or unshift in your JavaScript code, then it absolutely will not work across all browsers, because it will crash on IE on the Mac, so you are fucked.
So does any of your JavaScript code ever use Array.push? If it does, then you're not writing code that will work in all browsers, and there are probably other incompatibility problems you're not aware of -- you'd better go back and rewrite all your code!
Look at what you've written -- you just proven my point!
You admit your code doesn't run properly on all browsers, and that you have to write extra code to handle the case of browsers that don't support the features you require. You're telling me that you have to implement certain features at least twice in order to fall back to different methods for different browsers. That is my point exactly!
You say "so it's a matter of hoping it degrades gracefully in IE" -- that's only the most popular browser in the world, and you're "hoping"? You don't sound very sure of yourself that your code will work.
You're disenginuously griping about IE "doing its own thing" while admitting that you do know that Internet Explorer's XMLHTTPRequest object came first, and the other browsers imitated it.
Since you're well aware that IE had it first, you're being deceptive when you imply that there's some sort of standard that IE's failing to implement properly. The XMLHTTPRequest standard is defined by IE, and the other browsers are not imitating it properly. It's 180 degrees the other way around than what you're implying, and you know it.
Stop trying to weasle out of your original statement and twist the facts and to fit your distorted version of reality, when you know you're wrong. There are certainly enough problems with IE that you don't have to make up fictional problems just to make a rhetorical point.
You say you use "standards compliant code", but XMLHTTPRequest is not a W3C standard, it's a Microsoft standard. So you're using a Microsoft standard, and complaining about Microsoft's original implementation being incompatible with a mythical W3C standard that never existed, when it's the other browsers that incorrectly implement the standard defined by Microsoft.
You know you're full of shit, but you'd rather listen to yourself bitch about Microsoft than tell it like it really is.
Mad Merlin wrote (about incompatible XMLHTTPRequest implementations): "If they have, I haven't encountered it. Besides IE doing it's own thing like usual, every other browser has the same implementation. Unusually enough, in this case, working around IE is pretty simple."
Yes there are many incompatibilities, so the only reason you haven't encountered any incompatibilities, is because you haven't tested your application on every possible browser and operating system, which you have to do in order to be sure your AJAX application will run across any platforms you want to support.
AJAX requires you to test against all browsers, because all browsers are subtly and not-so-subtly different. If you're not doing all that testing, then you have no way of knowing whether or not your AJAX application will really work on other people's browsers, and it probably won't.
You couldn't be more mistaken about the XMLHTTPRequest implementation in Internet Explorer being non-standard. In case you didn't know, XMLHTTPRequest was invented by Microsoft, and Internet Explorer was the first browser to support it. Microsoft's implementation of XMLHTTPRequest defines the interface, and all other browsers are implementations of Microsoft's specification. Better do your homework next time, kiddo.
It's incorrect to say that AJAX is a new idea, and it's also incorrect to say that Microsoft invented the idea. It's been around for a long time, in systems like NeWS, the Network extensible Window System, developed in the 1980's.
It puzzles me why a consulting company like Adaptive Path would want everyone to think that they believe AJAX is a new technology. It sounds like they don't know their history, and haven't been paying attention to networking technology for the past couple of decades, so they were blindsided by a technology that's been around for a long time, and now they want people to think they invented it. Now they're totally overpromising and hyping it, because they lack the experience to know its limitations.
Coming up with a new buzzword for an old idea isn't rocket science, and using the term AJAX makes people sound like newbies to me.
NeWS was developed a long time before Java, by the same person working for the same company: James Gosling at Sun.
NeWS used PostScript throughout, as the imaging model (like DHTML), the scripting language (like JavaScript) and the data model (like XML). It was like AJAX in that it sent asynchronous messages over the network and used a dynamic scripting language on the client side (called the NeWS server), so it could implement local graphical user input feedback, and efficient application specific network protocols (using a binary encoding for PS data).
NeWS was much more consistent and better designed than AJAX's amalgamation of accidental technologies (DHTML, JavaScript, XML). NeWS also has many other advantages over AJAX, such an excellent imaging model, wysiwyg printer compatibility, shared modules, multithreading, synchronization, a programmable event distribution system, a fully developed Open Look gui toolkit, and graphical interface builder (HyperLook).
Writing NeWS PostScript is a lot like directly programming byte code for the Java or Flash virtual machines, which are both object oriented stack machines a lot like PostScript and Forth.
At the time, we were well aware that many people had a hard time programming in PostScript directly (although I love it), so several interesting compilers were developed. Rehmi Post wrote a back-end to the Amsterdam Compiler Kit (CScript: C for yourself, PostScript for NeWS), Arthur van Hoff (who later wrote the Java compiler in Java) wrote PdB (Pretty darn Brilliant), a compiler that translated object oriented C into PostScript , which supported subclassing PostScript NeWS toolkit classes. Dave Singer at Schlumberger wrote LispScript, a Lisp to PostScript compiler, which allowed you to take full advantage of Common Lisp macros to develop PostScript programs!
OpenLaszlo is a high level XML/JavaScript based programming language, which compiles into Flash byte code that runs in the Flash player, and works exactly the same across all platform. The inner loops and hot-spots of Laszlo are hand written in "flasm" (Flash Assembler), as hand optimized alternatives to the compiled JavaScript code. (Laszlo is a JavaScript compiler that currently outputs SWF code, but will support other virtual machines in the future.) Flasm looks a lot like NeWS PostScript code, with all the stack comments. Laszlo is open source, so you can grab a copy of the LPS sources and look at "LaszloView.as" to see what I mean.
Flash is installed by default on most browsers. 98% of all browsers already have Flash installed. So the number of people who can't run your application is miniscule, and it's easy for most of them to upgrade for free. No other platform comes close to Flash's ubiquity -- it's more widespread than Java, SVG, UIL, XAML, or anything else on the radar.
The harsh reality of AJAX (besides the obvious fact that it has sucky graphics) is that it's extremely difficult to write code that runs the same in all browsers, and you have to relentlessly test against each different browser on every different platform that you plan to support. Flash has no such problem, because it's identical across all platforms.
The lowest-common-denominator graphics AJAX can support across all browsers are crude and clumsy. Google maps has to bend over backwards and depend on the server to draw a diagonal line with transparent PNGs on Firefox, but it can't use transparent PNGs on Internet Explorer, so it has to use non-standard VML instead. It can't simply do everything in terms of SVG or PNG or VML: it actually has to support BOTH PNG and VML, but can't take advantage of vastly superior SVG since it's not commonly deployed nor well supported! All that rube-goldberg technology, just to draw a stupid line.
AJAX applications require a huge amount of extra work to develop, and even more to maintain, because of the necessity of dealing with evolving browser incompatibilities. And the end result simply isn't worth all the effort, since the lowest-common-denominator graphics and the resulting user interfaces are so crude and limited.
AJAX practices must balance on a randomly swerving rasor's edge: the intersection of what works on all browsers at the time of implementation. But all the browsers are constantly evolving in different directions, so today's hacks and kludges you're forced to use to work around bugs in today's various browsers will make your application fragile, complex and hard to maintain, and it will probably break in future browsers. AJAX forces you to artificially limit yourself and refrain from using technologies like SVG, VML and PNG, or else you have to actually implement simple things like diagonal lines with several different technologies at once, sniff the browser, adapt at run-time, and fall back to server side rendering!
Maybe Google has the resources to develop and matintain several different ways of drawing a diagonal line over a map, but most companies and independent developers don't have as much human and computer resources to flush down the toilet on such a simple problem of drawing lines. Flash already solves that problem quite nicely thank you, and it's the most ubiquitous RIA platform that exists today, with open source development tools like OpenLaszlo.
AJAX is a new buzzword for old (but not bad) ideas.
Don't take this as anti-AJAX. That kind of architecture is great, but it's the notion that the new AJAX buzzword describes new ideas that annoys me.
Of course Microsoft has been supporting it since the 90's, but it goes back a lot further than that.
For a long time, I've been evangelizing and more importantly implementing interactive applications that run efficiently over thin wire (dial-up modems, ISDN, early internet before it was fast, etc), which are locally interactive and efficient because there's a programming language on each side of the connection that implements custom application specific protocols and provides immediate feedback without requiring network round trips.
Now I develop distributed applications with OpenLaszlo, which embodies all the great qualities of AJAX without the horrible compatibility problems and shitty graphics. Macromedia though OpenLaszlo was such a great idea that they made a proprietary knock-off called Flex, for which they charge $12,000 per CPU. The future of Laszlo is secure since it's free software with an open source license, but Flex is in Flux since Adobe is buying Macromedia.
I'm quite happy to have found OpenLaszlo, since it's got all the advantages of NeWS, it runs beautifully and consistently on all platforms, the people developing it really understand what they're doing, and most importantly it's open source. NeWS was a technological success, but a commercial failure, because Sun refused to release it like X11. But OpenLaszlo applications really do run everywhere consistently, support XML standards and rich dynamic graphics vastly superior to anything you can do in DTHML, and they're great fun to develop.
Here's a message I wrote on the news-makers mailing list (a mailing list about NeWS that I started and maintained during the Window System Wars of the 80's), discussing the difference between Adobe's approach to Display PostScript, X11's inherent deficiencies, and Sun's approach to NeWS.
Perl is great for desparate low-skill sysadmins who need to extort their employers into keeping them on because nobody else can decypher their code.
If that's your problem, then you should instead improve your skill set by learning better languages, instead of digging yourself deeper into the grave with Perl.
There are good reasons why people shouldn't fill airships with hydrogen, paint walls with lead paint, kill bugs with DDT, insulate homes with asbestos, glow watch faces with radium, treat medical problems with leaches, and develop software with Perl.
All of those technologies seemed to be a good idea at the time, but they turned out to have long term unforseen consequences. Now that the consequences are understood, it's criminal to continue using those technologies.
If you don't understand Perl's problems, then you certainly shouldn't be using it. If you don't think it has problems, then you're dead wrong, and should educate yourself.
So do you agree that you should reject XML for the same reason you reject Lisp: too many parentheses? Or do you claim that it's easier to read twice as many XML angled brackets with repeated tag names, than Lisp parenthesis? If so, then why's that?
A schema is like a stigma: when you have more than one of them, they're called stigmata (schemata).
Could you possibly think of a worse example of a hard-to-read XML application than RDF??!
XML is like electricity: it's a great way to transmit information (power), but a horrible way to store it. Often it's much more efficient to store it in a traditional database where it can be efficiently indexed and manipulated (chemical potential energy like hydrogen or batteries), and only convert it to XML when it hits the wire.
Print statements with embedded output strings are absolutely horrible. You have to deal with all the quoting and formatting issues, and that introduces all kinds of special case bugs and security holes in your code. What's even worse is half-assed regular-expression based parsers that don't fully or correctly implement proper XML, like Perl programmers love to write.
There's no reason to discourage discussion of language A versus language B versus language C. That's what the Portland Pattern Repository Wiki is all about.
Programming language design is not just a matter of style or personal opinion: some well designed languages actually are qualitatively superior to others, and some badly designed languages (like Visual Basic, Perl, PHP and TCL) are fatally flawed in ways they needn't have been, if only their designers had been wise enough to learn about other languages (like Lisp, Python, Ruby and ML).
If you made a bad decision and invested a lot of time and effort in learning an inferior language like Perl, then there's no reason to cover your ears when people discuss its problems and the advantages of better languages. Not knowing what's wrong with Perl will only cause you more problems, if you still choose to continue using it after learning how bad it is.
Zope is like the space shuttle in a lot of ways. A totally amazing heroic effort, well worth studying, but much too complex, and the result of many trade-offs, compromizes and backroom political deals. It would be foolish to design your own Python CMS before learning about Zope, its history and evolution. But it would also be foolish to blindly imitate it, the way so many frameworks just ape other frameworks without understanding their strengths and weaknesses.
Parrot is still a joke, and the butt of the joke are the people who took it seriously and are actually wasting time on it. It's being driven by the Perl fanatics who lack any kind of perspective, while the Python community smiles quietly to itself, knowing that those people can't cause as much trouble if they're tied up with Parrot.
If you'll remember, the whole point of the Dead Parrot sketch is that the Parrot is DEAD, but the pet store owner just won't admit it come hell or high water. The irony is delicious.
You can't make a false statement true by writing it a lot of times, but you can make a bunch of fools believe it.
Lisp is a programming language and also a data description language. Lisp programs are exactly the same stuff as lisp data, so Lisp macros operate directly on lisp programs as well as any kind of Lisp data (S-Expressions), which makes them extremely powerful, in ways that C-preprocessor-like text substitution based macros and type system based C++ templates simply can't approach. Lisp is the original floor wax that's also a desert topping, that both shines well and tastes great.
XML is a data description language, which has programming language applications, and many other applications having nothing to do with programmign languages. That is to say: There are many XML based programming languages, which are all applications of XML, not XML itself.
If you take the parenthetical arguments against Lisp seriously, then you have to dismiss XML and all of its many applications on the same grounds.
You said: "so the XML example would represent much more information than the LISP example"
They "represent" the same amount of information. Requiring you to repeat the same information twice is not the same as representing more information.
Each level of nesting in XML requires you to use a tag name, even if it's not necessary to represent the information required (a 5-deep array of a single string, in this example). So XML requires you to insert extra useless information, and then repeat it. It results in more text, which takes longer to read, and less information fits on the same sized page. That's why XML is less readable and more wasteful than Lisp s-expressions.
If you believe that XML Sucks, then what's wrong with it, how would you fix it, what would you propose as an alternative, and what do you use instead?
I like both Lisp and XML, and the way I use XML is deeply influences by Lisp. I'd rather be using Lisp, but XML (and JavaScript and Flash) are ubiquitous and well supported, so I'd be a fool to try to reinvent those wheels instead of learning to live with what we have and improving on it.
XML made the worst part of sexprs worse, by introducing lousy syntax. Then it failed to really capture the strengths of sexprs. Less for more cost, what a deal.
Slashdot Mirror
They are both systems for defining interfaces that hide the way you implement services. ActiveX says nothing about which API you use to implement the interfaces with. The whole point of ActiveX and XPCOM is to separate interface from implementation.
ActiveX runs on MacOS, OS/X, Linux, Unix, without any Win32 api dependencies, and on Windows, where you can develop ActiveX controls with or without Win32 and MFC dependenceis.
I don't understand your argument about "making use of the windows api in linux is about as good as using POSIX on windows". Haven't you ever heard of cygwin? That's pretty good, and I use it all the time.
I also don't understand your argument about "To add activeX to gecko's windows codebase would just spilt the userbase".
You sound like those Loki appologists who argue that Wine is evil because it discourages people from developing games for Linux. If it solves some people's problems, then what's your beef with it?
-Don
Old browsers didn't support 128 bit encryption, so Korean banks developed their own encryption algorithm (SEED), which all their financial services now use. Firefox does not support SEED, but Internet Explored does support SEED via an ActiveX control.
If Firefox supported ActiveX controls, then Firefox would support SEED, but it doesn't. The 128 bit encryption built into Firefox will not solve their problem, because they need to use SEED. They developed SEED because the US government prohibited the export of strong 128 bit encryption at the time Korea deployed their online banking system.
They can't just decide to change their encryption algorithm overnight, so using SSL is simply not an option right now. The ActiveX control solution already exists, and works just fine for 95% of the people. It's nice that they finally support Firefox via XPCOM, but if Firefox supported ActiveX as an option in the first place, then all those Firefox users who needed to do online banking wouldn't have had to wait till now.
ActiveX and XPCOM are similar technologies, and they both have the same security problems and limitations, but they're different enough that somebody has do some programming to repackage the encryption module as an XPCOM control instead of an ActiveX control. If Firefox had an option to support ActiveX at the user's request, then extra effort and delay would not be necessary.
It would take a lot less work to make Firefox support ActiveX, than it would require to rewrite every ActiveX control so it supports XPCOM.
-Don
Please read (and understand) the article before posting, next time.
By the way, AJAX is not the solution to every problem.
-Don
The ActiveX Specification is freely available for anyone to implement. In case you didn't know, XPCOM is just an open source knock-off of ActiveX, with enough gratuitious changes to make them incompatible in practice. But essentially, they're the same thing.
XPCOM is no more secure than ActiveX. They both have total access to your computer. It's irresponsible of you to spread the misinformation that XPCOM is more secure than ActiveX, when it's not. It doesn't help anyone to have a false sense of security based on well meaning hype and uninformed cheerleading.
You're right that both ActiveX and XPCOM are more functional than AJAX (for some definition of the word "functional" -- in the sense that it has more client side functionality).
Perhaps Firefox should include support for ActiveX? There's nothing stopping them, really. So then it wouldn't have been necessary for to write a special XPCOM control, since they could have used their original ActiveX control.
Oh yeah, I forgot, it's more important for Firefox to make a rhetorical point by excluding ActiveX support, than to serve the needs of its users. That's called cutting off your nose to spite your face.
-Don
Are you proposing implementing the encryption on the server side, and sending passwords over the net unencrypted?
Or are you suggesting they implement the 128 bit encryption algorithm in JavaScript?
-Don
You should realize that adding a method or any other key to the array prototype breaks "for (key in array) { ... }" so that looping over the keys in ANY ARRAY INSTANCE will return the method names you defined in the prototype as keys (although that behavior also varies between different browsers). So each and every one of your for loops have to get the value, check if it's a function, and ignore it.
Thanks a lot, JavaScript.
If you didn't realize that adding methods to array prototypes fucks up for loops in some browsers, then you're not qualified to program AJAX, because you're grossly underestimating the complexity of writing cross platform lowest denominator JavaScript that runs the same across all browsers.
AJAX evangelists are horribly hyping and outrageously overpromising the technology, strutting around like naked emperors, parading their ignorance of history and JavaScript programming.
-Don
There is no other viewer more widely installed than Flash -- not even close. The runner up Acrobat is more than 10% behind Flash's installed base. Why do you think Adobe is buying Macromedia for so much money?
Flash Player Statistics:
Flash: 97.6%, Acrobat: 87.1%, Java: 86.5%, Windows Media Player: 84.3%, Quicktime: 64.1%, Real: 58.9%, Shockwave: 55.4%, Viewpoint: 49.7%, SVG: 12.5%.
Flash Bundling Matrix:
Flash is bundled with Internet Explorer Win, Internet Explorer Mac, Netscape Win and Mac, AOL Win, AOL Mac, Opera, and with MacOS, Mac OS X, and Windows.
Your management is obviously stupid. My condolences. Not an unusual situation, but sad. Maybe you should look for another job.
You're totally wrong in stating that it's not that difficult to write code that runs in all browsers. Have you actually tried, or are you just saying that because you heard other people say it, and it sounds nice to repeat it?
Laszlo enables you to program Flash for free without buying any of Macromedia's tools. The cost of trying to write cross-platform JavaScript that runs in all browsers is your precious time and the quality of your application. There are some things more expensive than money, and you're wasting them if you're trying to use AJAX without being aware of its limitations.
Flash is much more portable than AJAX, and it is much better technology, by far, and it's widely accepted, much more so than any other technology. Flash graphics are much higher quality and more capable than anything that's possible with dynamic HTML, and you know it. Just try to draw a diagonal line in DHTML.
I can't diagnose what your problem is with having to install Flash manually all the time on every computer you've ever used, but I've never heard of anyone else with that problem, so you're probably doing something wrong.
JavaScript is easy to learn as long as you only need to use one version of the language, which is the case with Laszlo. But the subtle and not-so-subtle differences between different JavaScript implementations are extremely difficult to learn, and you waste a huge amount of time finding those differences by accident and then having to test against every browser use a bunch of half-assed debuggers and popup alert statements to diagnose the problems and come up with work-arounds for each browser.
Were you aware that JavaScript in Internet Explorer for the Mac does not support the push, pop, shift and unshift methods on arrays? Instead of a.push(foo), you have to go a[a.length] = foo.
If that's a surprise to you, then you're not qualified to write cross-browser JavaScript code. If you're using Array.push, pop, shift or unshift in your JavaScript code, then it absolutely will not work across all browsers, because it will crash on IE on the Mac, so you are fucked.
So does any of your JavaScript code ever use Array.push? If it does, then you're not writing code that will work in all browsers, and there are probably other incompatibility problems you're not aware of -- you'd better go back and rewrite all your code!
-Don
You admit your code doesn't run properly on all browsers, and that you have to write extra code to handle the case of browsers that don't support the features you require. You're telling me that you have to implement certain features at least twice in order to fall back to different methods for different browsers. That is my point exactly!
You say "so it's a matter of hoping it degrades gracefully in IE" -- that's only the most popular browser in the world, and you're "hoping"? You don't sound very sure of yourself that your code will work.
You're disenginuously griping about IE "doing its own thing" while admitting that you do know that Internet Explorer's XMLHTTPRequest object came first, and the other browsers imitated it.
Since you're well aware that IE had it first, you're being deceptive when you imply that there's some sort of standard that IE's failing to implement properly. The XMLHTTPRequest standard is defined by IE, and the other browsers are not imitating it properly. It's 180 degrees the other way around than what you're implying, and you know it.
Stop trying to weasle out of your original statement and twist the facts and to fit your distorted version of reality, when you know you're wrong. There are certainly enough problems with IE that you don't have to make up fictional problems just to make a rhetorical point.
You say you use "standards compliant code", but XMLHTTPRequest is not a W3C standard, it's a Microsoft standard. So you're using a Microsoft standard, and complaining about Microsoft's original implementation being incompatible with a mythical W3C standard that never existed, when it's the other browsers that incorrectly implement the standard defined by Microsoft.
You know you're full of shit, but you'd rather listen to yourself bitch about Microsoft than tell it like it really is.
-Don
Yes there are many incompatibilities, so the only reason you haven't encountered any incompatibilities, is because you haven't tested your application on every possible browser and operating system, which you have to do in order to be sure your AJAX application will run across any platforms you want to support.
AJAX requires you to test against all browsers, because all browsers are subtly and not-so-subtly different. If you're not doing all that testing, then you have no way of knowing whether or not your AJAX application will really work on other people's browsers, and it probably won't.
You couldn't be more mistaken about the XMLHTTPRequest implementation in Internet Explorer being non-standard. In case you didn't know, XMLHTTPRequest was invented by Microsoft, and Internet Explorer was the first browser to support it. Microsoft's implementation of XMLHTTPRequest defines the interface, and all other browsers are implementations of Microsoft's specification. Better do your homework next time, kiddo.
It's incorrect to say that AJAX is a new idea, and it's also incorrect to say that Microsoft invented the idea. It's been around for a long time, in systems like NeWS, the Network extensible Window System, developed in the 1980's.
It puzzles me why a consulting company like Adaptive Path would want everyone to think that they believe AJAX is a new technology. It sounds like they don't know their history, and haven't been paying attention to networking technology for the past couple of decades, so they were blindsided by a technology that's been around for a long time, and now they want people to think they invented it. Now they're totally overpromising and hyping it, because they lack the experience to know its limitations.
Coming up with a new buzzword for an old idea isn't rocket science, and using the term AJAX makes people sound like newbies to me.
-Don
NeWS used PostScript throughout, as the imaging model (like DHTML), the scripting language (like JavaScript) and the data model (like XML). It was like AJAX in that it sent asynchronous messages over the network and used a dynamic scripting language on the client side (called the NeWS server), so it could implement local graphical user input feedback, and efficient application specific network protocols (using a binary encoding for PS data).
NeWS was much more consistent and better designed than AJAX's amalgamation of accidental technologies (DHTML, JavaScript, XML). NeWS also has many other advantages over AJAX, such an excellent imaging model, wysiwyg printer compatibility, shared modules, multithreading, synchronization, a programmable event distribution system, a fully developed Open Look gui toolkit, and graphical interface builder (HyperLook).
Writing NeWS PostScript is a lot like directly programming byte code for the Java or Flash virtual machines, which are both object oriented stack machines a lot like PostScript and Forth. At the time, we were well aware that many people had a hard time programming in PostScript directly (although I love it), so several interesting compilers were developed. Rehmi Post wrote a back-end to the Amsterdam Compiler Kit (CScript: C for yourself, PostScript for NeWS), Arthur van Hoff (who later wrote the Java compiler in Java) wrote PdB (Pretty darn Brilliant), a compiler that translated object oriented C into PostScript , which supported subclassing PostScript NeWS toolkit classes. Dave Singer at Schlumberger wrote LispScript, a Lisp to PostScript compiler, which allowed you to take full advantage of Common Lisp macros to develop PostScript programs!
OpenLaszlo is a high level XML/JavaScript based programming language, which compiles into Flash byte code that runs in the Flash player, and works exactly the same across all platform. The inner loops and hot-spots of Laszlo are hand written in "flasm" (Flash Assembler), as hand optimized alternatives to the compiled JavaScript code. (Laszlo is a JavaScript compiler that currently outputs SWF code, but will support other virtual machines in the future.) Flasm looks a lot like NeWS PostScript code, with all the stack comments. Laszlo is open source, so you can grab a copy of the LPS sources and look at "LaszloView.as" to see what I mean.
-Don
The harsh reality of AJAX (besides the obvious fact that it has sucky graphics) is that it's extremely difficult to write code that runs the same in all browsers, and you have to relentlessly test against each different browser on every different platform that you plan to support. Flash has no such problem, because it's identical across all platforms.
The lowest-common-denominator graphics AJAX can support across all browsers are crude and clumsy. Google maps has to bend over backwards and depend on the server to draw a diagonal line with transparent PNGs on Firefox, but it can't use transparent PNGs on Internet Explorer, so it has to use non-standard VML instead. It can't simply do everything in terms of SVG or PNG or VML: it actually has to support BOTH PNG and VML, but can't take advantage of vastly superior SVG since it's not commonly deployed nor well supported! All that rube-goldberg technology, just to draw a stupid line.
AJAX applications require a huge amount of extra work to develop, and even more to maintain, because of the necessity of dealing with evolving browser incompatibilities. And the end result simply isn't worth all the effort, since the lowest-common-denominator graphics and the resulting user interfaces are so crude and limited.
For example, Pie menus should pop up in round and arbitrarily shaped windows, but it's impossible to even draw a circle with DHTML, let alone a spokes and speech bubbles!
AJAX practices must balance on a randomly swerving rasor's edge: the intersection of what works on all browsers at the time of implementation. But all the browsers are constantly evolving in different directions, so today's hacks and kludges you're forced to use to work around bugs in today's various browsers will make your application fragile, complex and hard to maintain, and it will probably break in future browsers. AJAX forces you to artificially limit yourself and refrain from using technologies like SVG, VML and PNG, or else you have to actually implement simple things like diagonal lines with several different technologies at once, sniff the browser, adapt at run-time, and fall back to server side rendering!
Maybe Google has the resources to develop and matintain several different ways of drawing a diagonal line over a map, but most companies and independent developers don't have as much human and computer resources to flush down the toilet on such a simple problem of drawing lines. Flash already solves that problem quite nicely thank you, and it's the most ubiquitous RIA platform that exists today, with open source development tools like OpenLaszlo.
-Don
Don't take this as anti-AJAX. That kind of architecture is great, but it's the notion that the new AJAX buzzword describes new ideas that annoys me.
Of course Microsoft has been supporting it since the 90's, but it goes back a lot further than that.
For a long time, I've been evangelizing and more importantly implementing interactive applications that run efficiently over thin wire (dial-up modems, ISDN, early internet before it was fast, etc), which are locally interactive and efficient because there's a programming language on each side of the connection that implements custom application specific protocols and provides immediate feedback without requiring network round trips.
Before he made Java, James Gosling wrote the NeWS Window System.
I did a lot of work with NeWS, as a user interface researcher, commercial product developer, and a gui toolkit engineer for Sun, implementing distributed applications as well as user interface widgets and gui construction tools.
I've programmed NeWS to implement many user interface widgets (pie menus, tabbed windows, terminal emulators, graphics editors), gui toolkits (Suns TNT Open Look Toolkit, Arthur van Hoff's HyperLook user interface construction tool), and applications (UniPress and Gnu Emacs text editor interfaces, Ben Shneiderman's HyperTIES hypermedia browser, PSIBER visual PostScript programming and debugging environment, PizzaTool for customizing and ordering pizza via FAX, a cellular automata lab, a port of Maxis's SimCity), and lots of other stuff.
Now I develop distributed applications with OpenLaszlo, which embodies all the great qualities of AJAX without the horrible compatibility problems and shitty graphics. Macromedia though OpenLaszlo was such a great idea that they made a proprietary knock-off called Flex, for which they charge $12,000 per CPU. The future of Laszlo is secure since it's free software with an open source license, but Flex is in Flux since Adobe is buying Macromedia.
I'm quite happy to have found OpenLaszlo, since it's got all the advantages of NeWS, it runs beautifully and consistently on all platforms, the people developing it really understand what they're doing, and most importantly it's open source. NeWS was a technological success, but a commercial failure, because Sun refused to release it like X11. But OpenLaszlo applications really do run everywhere consistently, support XML standards and rich dynamic graphics vastly superior to anything you can do in DTHML, and they're great fun to develop.
Here's a message I wrote on the news-makers mailing list (a mailing list about NeWS that I started and maintained during the Window System Wars of the 80's), discussing the difference between Adobe's approach to Display PostScript, X11's inherent deficiencies, and Sun's approach to NeWS.
To avoid confusion:
If that's your problem, then you should instead improve your skill set by learning better languages, instead of digging yourself deeper into the grave with Perl.
There are good reasons why people shouldn't fill airships with hydrogen, paint walls with lead paint, kill bugs with DDT, insulate homes with asbestos, glow watch faces with radium, treat medical problems with leaches, and develop software with Perl.
All of those technologies seemed to be a good idea at the time, but they turned out to have long term unforseen consequences. Now that the consequences are understood, it's criminal to continue using those technologies.
If you don't understand Perl's problems, then you certainly shouldn't be using it. If you don't think it has problems, then you're dead wrong, and should educate yourself.
-Don
-Don
It's simply irresponsible and foolish to use Perl.
-Don
So do you agree that you should reject XML for the same reason you reject Lisp: too many parentheses? Or do you claim that it's easier to read twice as many XML angled brackets with repeated tag names, than Lisp parenthesis? If so, then why's that?
-Don
XML is much harder to read and more verbose than Lisp. That's discussed here: XML Is a Poor Copy Of Lisp S-Expressions.
A schema is like a stigma: when you have more than one of them, they're called stigmata (schemata).
Could you possibly think of a worse example of a hard-to-read XML application than RDF??!
XML is like electricity: it's a great way to transmit information (power), but a horrible way to store it. Often it's much more efficient to store it in a traditional database where it can be efficiently indexed and manipulated (chemical potential energy like hydrogen or batteries), and only convert it to XML when it hits the wire.
Print statements with embedded output strings are absolutely horrible. You have to deal with all the quoting and formatting issues, and that introduces all kinds of special case bugs and security holes in your code. What's even worse is half-assed regular-expression based parsers that don't fully or correctly implement proper XML, like Perl programmers love to write.
There's no reason to discourage discussion of language A versus language B versus language C. That's what the Portland Pattern Repository Wiki is all about.
Programming language design is not just a matter of style or personal opinion: some well designed languages actually are qualitatively superior to others, and some badly designed languages (like Visual Basic, Perl, PHP and TCL) are fatally flawed in ways they needn't have been, if only their designers had been wise enough to learn about other languages (like Lisp, Python, Ruby and ML).
If you made a bad decision and invested a lot of time and effort in learning an inferior language like Perl, then there's no reason to cover your ears when people discuss its problems and the advantages of better languages. Not knowing what's wrong with Perl will only cause you more problems, if you still choose to continue using it after learning how bad it is.
-Don
-Don
If you'll remember, the whole point of the Dead Parrot sketch is that the Parrot is DEAD, but the pet store owner just won't admit it come hell or high water. The irony is delicious.
-Don
-Don
-Don
Lisp is a programming language and also a data description language. Lisp programs are exactly the same stuff as lisp data, so Lisp macros operate directly on lisp programs as well as any kind of Lisp data (S-Expressions), which makes them extremely powerful, in ways that C-preprocessor-like text substitution based macros and type system based C++ templates simply can't approach. Lisp is the original floor wax that's also a desert topping, that both shines well and tastes great.
XML is a data description language, which has programming language applications, and many other applications having nothing to do with programmign languages. That is to say: There are many XML based programming languages, which are all applications of XML, not XML itself.
If you take the parenthetical arguments against Lisp seriously, then you have to dismiss XML and all of its many applications on the same grounds.
-Don
They "represent" the same amount of information. Requiring you to repeat the same information twice is not the same as representing more information.
Each level of nesting in XML requires you to use a tag name, even if it's not necessary to represent the information required (a 5-deep array of a single string, in this example). So XML requires you to insert extra useless information, and then repeat it. It results in more text, which takes longer to read, and less information fits on the same sized page. That's why XML is less readable and more wasteful than Lisp s-expressions.
-Don
I like both Lisp and XML, and the way I use XML is deeply influences by Lisp. I'd rather be using Lisp, but XML (and JavaScript and Flash) are ubiquitous and well supported, so I'd be a fool to try to reinvent those wheels instead of learning to live with what we have and improving on it.
There's an interesting discussion of Lisp -vs- XML. Some people think Xml is a good copy Of Lisp S-Expressions, and other people think Xml is a poor copy Of Lisp S-Expressions.
"Think of XML as Lisp for COBOL programmers." (Tony-A on slashdot)
"S-expressions are a representation, XML is a career path." -- WardCunningham (oopsla '03)
The ExtensibleMarkupLanguage is a poor copy of EssExpressions.
XML made the worst part of sexprs worse, by introducing lousy syntax. Then it failed to really capture the strengths of sexprs. Less for more cost, what a deal.
See http://xmlsucks.org/ or http://xmlsucks.org/but_you_have_to_use_it_anyway/
-Don
-Don