Copy and paste three out of four, strange inexplicable layout (ok, a lot of comic characters are too close when they have a conversation, but people don't talk to each other from 20 feet away! In a background-less void, no less!), bad art.
That said I expect Vista to be just like XP. XP took way too many resources to work. I remember how 2000 beat its pants off, sp2 or sp3 will be released, people will use it, and then they'll move on to 7.
Only after a year and a half of posting, "Windows 7 sucks so hard! I have Vista, and it works just fine! Why would anybody need any of the new stuff in Windows 7?" on Slashdot.
Even if they follow the DOM 100%, the DOM still sucks. It doesn't have enough widgets, you don't have enough control over the widgets it does have, it's missing very necessary global functions, etc.
It's great that DOM has setTimeout and setInterval, but how come there's no cookie handling functions? Why is there "getElementBy"-everything *except* className?
DOM is woefully inadequate for any real application development.
Javascript is not Java. At all. Not one bit. It has an extremely misleading name. (Actually, it's real name is ECMAScript, but Netscape called it Javascript and it stuck. Sadly. Microsoft calls it JScript.)
Anyway, Javascript is inherently super-fast, but DOM changes can be inherently slow. If you benchmarked a pure computing task, Javascript would compare very favorably to other scripting languages. But since Javascript on the web usually does more DOM element shuffling than actual computation, it can be slowed down by that.
There's also the possibility it's implemented poorly. I've seen frameworks-upon-frameworks, so many that the simpliest task (like populating a slideshow) are agonizingly slow. For example, grab a stopwatch and see how long it takes this site to populate the list of clips in the slideshow: http://abc.go.com/primetime/dancingwiththestars/index?pn=index That's not JS, that's ABC's crummy web developers.
It's not the language, it's the platform. Microsoft and Mozilla do nearly everything different from each other-- IE calls it "innerText" so FF calls it "textContent." IE deletes blank text nodes from the DOM, so Firefox keeps them. They handle event objects differently. IE doesn't bubble clicks on Flash and Silverlight content, so Firefox does. Etc.
In some cases, Microsoft is more right ("innerText" makes more sense than "textContent"), and in some cases Mozilla is more right (like bubbling Flash/Silverlight clicks.) But the real problem is that they're different.
Then the DOM API sucks, so you end up with a situation where 90% of Javascript applications need code duplicated one way or another. You can have a single webpage with 3-4 different functions that set or get cookies, for example. And of course you need your new ".realInnerText()" and your "if( !evt ) {evt = event;}" to compensate for the differences above.
Pain in the butt.
Oh, and to make things worse, all the frameworks conflict with each other. They all create/overwrite a function named "$" that does something different for each one. They all hijack event handlers with no respect for existing handlers.
BTW you can also do that as easily by hooking on to the existing onload function. This way, you're not depending on the reliability and availability of "addEventListener":
// Stupid Slashdot code; don't implement without lots of testing var t_onload = window.onload.toString().replace(/^[^{]*{/,'').replace(/}$/,'');
t_onload = 'MyNewOnloadFunction();' + t_onload;
window.onload = new Function( t_onload );
Of course, for onload specifically, we generally avoid using the window.onload handler altogether, since it doesn't fire under certain circumstances (like when the user hits Stop, for example.) Instead, we just set up a looping function using setInterval that checks the doc.readyState in IE and whether the "pageshow" event has fired in FF.
But this technique works on all types of handlers.
I'm not even talking about graphics (although that's another good example for the crappyness of DOM).
I'm just talking about widgets. For the widgets HTML/DOM does include, there's only a small percentage of the control a OS-native app has. And there are a million widgets HTML/DOM doesn't include at all-- progress bars, grid view, disclosure triangles, scrollbars with a 'lock' or 'split' function, etc.
Sure you can hack these together with tons of JS and by mis-using DIVs, but why should you have to? They come by default in any other development environment.
I agree that Javascript/ECMAScript is an excellent language.
Real web-application development isn't being hampered by JS, it's being hampered by the crappy and woefully insufficient DOM API.
For example, make a Visual Basic (or RealBasic if you're rabidly anti-Microsoft) form and add a scrolling textarea to it. Take a look at the properties inspector, and notice how many properties it has.
Now do the same thing in DOM. Can Javascript tell which text is selected? No. Can it set the text color, size, or font? No. (There is such a thing as a rich-text textarea, with those options, but DOM API has virtually no access to any of it.) It's simply ridiculous how incomplete DOM is, and that's where your true problems lie.
Of course, most people (even a lot of web developers) confuse Javascript with DOM and assume they're the same thing. They aren't; if you used python or ruby or any other language, you'd still be limited by a crappy DOM.
First of all, calm down. No lives are at stake here, you can ease up on the exclamation marks.
Secondly, what about a situation where I sign up for a "joke-a-day" phone call service? You're saying that the FTC should make that service illegal, even if it may have thousands of users and have never gotten any FTC complaints. If you slow down and think about it for a minute, you'll see that makes perfect sense.
I felt the same way when I returned to some C coding after doing tons of web work in Javascript/ECMAScript. C is just painful, even setting up the simpliest functions takes three times as much work as in Javascript and the list of things Javascript can do that C can't is nearly endless.
And Javacsript libraries (in this case, DOM) suck ass.
PHP and Perl are hasbeens, and simply not suitable for the large scale web applications of today.
Yeah. Like that teeny-tiny Facebook.
Seriously, you love Java, we get that. But it doesn't even close to "dominate the web backend." I'm not even sure it gives the Microsoft languages a run for its money; most of the huge sites I deal with on a daily basis are Microsoft technologies. (eBay, to give one example.)
People on this board blame VB all the time for bad programs. Perl doesn't get a pass.
(That said, I agree with you, I don't think you can blame the language for bad code; I *do* believe a language can contain features that encourage bad code.)
Yeah, but I bet they hit up big ISPs to pay for this for all their customers, and those ISPs will then include this as a "value-added service" (raising your bill to pay for it, of course) even if you don't want it.
There's no way they're talking about "voluntary" on an individual basis.
It would have helped for the word "PC" to be present somewhere in the summary, or the article. Unless that blog has a readership of only telepaths. That would be badass, though.
Personally, I wouldn't trust Microsoft as far as I can throw a PC, which is at least several feet, especially if we're talking about laptop.
Wow! You mean you're a foaming-at-the-mouth Microsoft hater? Who'da thunk it!
QT is not a "monster plugin" in terms of raping open standards and pillaging the web. You might consider it a heavy plugin technology by size, but again, the argument that software can't be more than a few megabytes belongs in 1998 with AOL CDs. Consumers don't have any trouble downloading QT with iTunes for their iPods. I clearly defined what I meant by Flash being a terrible plugin, and was not addressing that it takes too long to download. Flash is bad because it's bad, not because its big. Silverlight is just as bad, but it's false suggestion of being "open" makes it deceptively bad, which is even worse.
Whatever. Obviously you're not saying the "no plugin" spiel now, since you got slammed down on that one, but that is what you said originally.
Yes Microsoft began allowing users to chose their preferred software handlers years ago related to the monopoly consent decree (the portions it obeyed). You really are from 1998 aren't you?
Microsoft certainly put in the capability, but the Quicktime plugin crapped all over it and broke it, aggressively taking control of file formats while ignoring user preferences. Besides, I didn't say that Microsoft fixed it, I said either Microsoft or Apple fixed it, I'm not sure who. Since you have problems with this, I'd like to be more clear: STOP MISQUOTING ME! Thank you.
Your claim that IE didn't work with QT and therefore it must be Apple's fault can be challenged by historical precedent recorded in the Monopoly trial proceedings that proved Microsoft purposefully bjorked QuickTime's ability to play back media types, including media types QT could play and Windows couldn't. So it's your guessing against court document proof as to who might be to blame for QT not working under Windows.
I'm not talking about history, Christ. I'm talking about a bug in Quicktime that was reliably reproducible less than six months ago. I don't give a foaming shit about what happened in 1998, you're the one who keeps bringing that up (and then accusing me of living in it!) Get a goddamned grip on reality and hold up for dear life!
I don't give a crap what happened years ago in some trial. I DO. NOT. CARE. The simple fact is that Quicktime Plugin is a piece of crap that broke IE for years and years. That's what I was talking about, nothing else.
I'd be much more likely to dump Microsoft products if the competition, in this case Apple, could write decent software. Now I'm tempted to buy another copy of Vista just to spite you.
but there are plenty of ways to present video via JavaScript without using a plugin monster like Flash or Silverlight. That's what Apple does
Silverlight isn't "open" in any useful sense. It's a compiled platform that derails the web and W3C standards to erect a new way to deliver the web in a copycat to Flash: a closed binary presentation.
Maybe, but my Javascript can dive right into the Silverlight XAML DOM, install handlers on Silverlight events, do a very good many things that are impossible to do in Flash.
QT "breaks" IE's ability to display PNG?
Wow, I was just about to sent repro instructions, but it looks like either Apple finally fixed this annoying-ass bug, or Microsoft finally stopped allowing Quicktime to take control of formats.
Wow, who knew IE could even render PNG?!
Anybody who's used IE7. IE6 could, too, it had issues with transparency though.
Hint: you can chose which file formats each plugin renders.
Normally you can, but until recently your beloved Apple's Quicktime plugin would violently take control of the PNG format and never release it. Even if you manually set PNG to another helper, Quicktime would take control of it again and reverse your setting next time you attempted to view a PNG file. For some reason, Quicktime didn't screw with IE when the PNG was embedded.
To make things even more fun, if Quicktime's auto-updater happened to trigger while you were viewing this PNG image, it would lock-up the browser and require a ctrl-alt-delete to fix. Face it, Apple writes shit software.
It's also not Apple's fault you are using a legacy operating system.
This bug was on IE7 and Windows Vista only a little while ago. Those are both current supported versions. And yes, the bug was Apple's fault-- computers without the Quicktime plugin could view PNG files in IE just fine.
Actually, if a javascript app is programmed well/correctly, you can drag and drop on them just like any other application. I've used many a javascript front end that can do so.
Link me to one, please?
Again, if programmed correctly, a javascript app can do what you're describing. I've used many a javascript front end that can do so.
Again, link?
One more time, just for kicks: if programmed correctly, and the java engine is installed correctly, a javascript app can do what you're describing. I've used many a javascript front end that can do so.
Ah, well, there's no way in hell I'm installing that bloated piece of shit Java. If Javascript can't do it on its own, it can't do it period, as far as I'm concerned.
Thanks for confirming your original post was wrong.
Flash is bad because it's a proprietary de-opening of the web, not just because it happens to be a plugin. Everything is getting shoved back into a box owned by Adobe, and Adobe has proven that it has no interest in developing a non-crap version of Flash for any platform other than the Windows PC, where it is only decent.
Then you should be jumping for joy for Silverlight, which is a hell of a lot more open than Flash is, and if nothing else will prod Adobe into improving their product which is badly overdue.
Flash = Office. You can talk about how you can do this and that with Flash that you can't yet do with open standards, but that's like ridiculing OpenOffice for not being able to do some esoteric thing than Excel can, and demanding that everyone just hop into the Microsoft cuddle puddle.
It is exactly like that. There are thousands of things Office can do that OpenOffice can't. The open source fans who claim the product are equivalent always forget to add: "for myself, at least." If the Microsoft "cuddle puddle" helps me do my job easier, then I'll use it. (Hell, OpenOffice doesn't even have Normal View or equivalent yet!)
Web apps also don't need a special JavaScript runtime. The browser already provides that, and you can already save them as freestanding apps using a third party tool.
What tool? I know Mozilla is working on one, but I believe it's still pre-alpha.
My point about using JS to present web video is that Flash is not needed to present player controls prior to the completion of HTML5.
Huh? If you're talking about Apple's website, their controller is managed by Quicktime, not Javascript. If you're saying you can't make a Javascript controller for Flash, you're wrong; it's quite easy for Flash and Javascript to talk to each other. But I really have no idea what point you're trying to make here.
I'm sure you're aware that HTML5 doesn't natively play back video itself either.
Actually, I don't know much about HTML5. I just know it has a video tag because I've read other posts on this topic from more knowledgeable people about it.
In most cases, users would be using QuickTime to do that. Packing up your video in a Flash shell is just a step back into the past.
Quicktime is a bloated piece of crap. Anything that lets me watch video without using it (Flash *and* Silverlight inclusive) wins, as far as I'm concerned. Even having Quicktime installed breaks native features of IE (for example, displaying PNG formats), and I wouldn't trust Apple to code themselves out of a wet paper bag. At least, not on Windows.
Over here we have "10 Items or Less" (or the even better "About 10 Items") checkout lanes next to the cigs, and they all have scales. Unfortunately, they also take checks, which kind of defeats the purpose of an "express" lane, but oh well.
I guess that makes sense, but it still seems easier to me to just install a scale for the checker.
Slashdot Mirror
Wow, that's a bad comic.
Copy and paste three out of four, strange inexplicable layout (ok, a lot of comic characters are too close when they have a conversation, but people don't talk to each other from 20 feet away! In a background-less void, no less!), bad art.
Thanks for sharing.
Yeah, it's not like he was in a major blockbuster last summer or anything.
That said I expect Vista to be just like XP. XP took way too many resources to work. I remember how 2000 beat its pants off, sp2 or sp3 will be released, people will use it, and then they'll move on to 7.
Only after a year and a half of posting, "Windows 7 sucks so hard! I have Vista, and it works just fine! Why would anybody need any of the new stuff in Windows 7?" on Slashdot.
I have absolutely no idea what you're talking about.
Even if they follow the DOM 100%, the DOM still sucks. It doesn't have enough widgets, you don't have enough control over the widgets it does have, it's missing very necessary global functions, etc.
It's great that DOM has setTimeout and setInterval, but how come there's no cookie handling functions? Why is there "getElementBy"-everything *except* className?
DOM is woefully inadequate for any real application development.
Javascript is not Java. At all. Not one bit. It has an extremely misleading name. (Actually, it's real name is ECMAScript, but Netscape called it Javascript and it stuck. Sadly. Microsoft calls it JScript.)
Anyway, Javascript is inherently super-fast, but DOM changes can be inherently slow. If you benchmarked a pure computing task, Javascript would compare very favorably to other scripting languages. But since Javascript on the web usually does more DOM element shuffling than actual computation, it can be slowed down by that.
There's also the possibility it's implemented poorly. I've seen frameworks-upon-frameworks, so many that the simpliest task (like populating a slideshow) are agonizingly slow. For example, grab a stopwatch and see how long it takes this site to populate the list of clips in the slideshow: http://abc.go.com/primetime/dancingwiththestars/index?pn=index That's not JS, that's ABC's crummy web developers.
It's not the language, it's the platform. Microsoft and Mozilla do nearly everything different from each other-- IE calls it "innerText" so FF calls it "textContent." IE deletes blank text nodes from the DOM, so Firefox keeps them. They handle event objects differently. IE doesn't bubble clicks on Flash and Silverlight content, so Firefox does. Etc.
In some cases, Microsoft is more right ("innerText" makes more sense than "textContent"), and in some cases Mozilla is more right (like bubbling Flash/Silverlight clicks.) But the real problem is that they're different.
Then the DOM API sucks, so you end up with a situation where 90% of Javascript applications need code duplicated one way or another. You can have a single webpage with 3-4 different functions that set or get cookies, for example. And of course you need your new ".realInnerText()" and your "if( !evt ) {evt = event;}" to compensate for the differences above.
Pain in the butt.
Oh, and to make things worse, all the frameworks conflict with each other. They all create/overwrite a function named "$" that does something different for each one. They all hijack event handlers with no respect for existing handlers.
The language is great though.
Defer only works in IE. Firefox doesn't support it, and I'm pretty sure Safari doesn't support it either.
BTW you can also do that as easily by hooking on to the existing onload function. This way, you're not depending on the reliability and availability of "addEventListener":
Of course, for onload specifically, we generally avoid using the window.onload handler altogether, since it doesn't fire under certain circumstances (like when the user hits Stop, for example.) Instead, we just set up a looping function using setInterval that checks the doc.readyState in IE and whether the "pageshow" event has fired in FF.
But this technique works on all types of handlers.
I'm not even talking about graphics (although that's another good example for the crappyness of DOM).
I'm just talking about widgets. For the widgets HTML/DOM does include, there's only a small percentage of the control a OS-native app has. And there are a million widgets HTML/DOM doesn't include at all-- progress bars, grid view, disclosure triangles, scrollbars with a 'lock' or 'split' function, etc.
Sure you can hack these together with tons of JS and by mis-using DIVs, but why should you have to? They come by default in any other development environment.
I agree that Javascript/ECMAScript is an excellent language.
Real web-application development isn't being hampered by JS, it's being hampered by the crappy and woefully insufficient DOM API.
For example, make a Visual Basic (or RealBasic if you're rabidly anti-Microsoft) form and add a scrolling textarea to it. Take a look at the properties inspector, and notice how many properties it has.
Now do the same thing in DOM. Can Javascript tell which text is selected? No. Can it set the text color, size, or font? No. (There is such a thing as a rich-text textarea, with those options, but DOM API has virtually no access to any of it.) It's simply ridiculous how incomplete DOM is, and that's where your true problems lie.
Of course, most people (even a lot of web developers) confuse Javascript with DOM and assume they're the same thing. They aren't; if you used python or ruby or any other language, you'd still be limited by a crappy DOM.
https://sourceforge.net/tracker/?func=detail&aid=1973248&group_id=4421&atid=104421
First of all, calm down. No lives are at stake here, you can ease up on the exclamation marks.
Secondly, what about a situation where I sign up for a "joke-a-day" phone call service? You're saying that the FTC should make that service illegal, even if it may have thousands of users and have never gotten any FTC complaints. If you slow down and think about it for a minute, you'll see that makes perfect sense.
I felt the same way when I returned to some C coding after doing tons of web work in Javascript/ECMAScript. C is just painful, even setting up the simpliest functions takes three times as much work as in Javascript and the list of things Javascript can do that C can't is nearly endless.
And Javacsript libraries (in this case, DOM) suck ass.
PHP and Perl are hasbeens, and simply not suitable for the large scale web applications of today.
Yeah. Like that teeny-tiny Facebook.
Seriously, you love Java, we get that. But it doesn't even close to "dominate the web backend." I'm not even sure it gives the Microsoft languages a run for its money; most of the huge sites I deal with on a daily basis are Microsoft technologies. (eBay, to give one example.)
People on this board blame VB all the time for bad programs. Perl doesn't get a pass.
(That said, I agree with you, I don't think you can blame the language for bad code; I *do* believe a language can contain features that encourage bad code.)
Yeah, but I bet they hit up big ISPs to pay for this for all their customers, and those ISPs will then include this as a "value-added service" (raising your bill to pay for it, of course) even if you don't want it.
There's no way they're talking about "voluntary" on an individual basis.
It would have helped for the word "PC" to be present somewhere in the summary, or the article. Unless that blog has a readership of only telepaths. That would be badass, though.
Ditto. You can skip the demo, I'll guarantee you'll want to buy it. Brilliant game.
Personally, I wouldn't trust Microsoft as far as I can throw a PC, which is at least several feet, especially if we're talking about laptop.
Wow! You mean you're a foaming-at-the-mouth Microsoft hater? Who'da thunk it!
QT is not a "monster plugin" in terms of raping open standards and pillaging the web. You might consider it a heavy plugin technology by size, but again, the argument that software can't be more than a few megabytes belongs in 1998 with AOL CDs. Consumers don't have any trouble downloading QT with iTunes for their iPods. I clearly defined what I meant by Flash being a terrible plugin, and was not addressing that it takes too long to download. Flash is bad because it's bad, not because its big. Silverlight is just as bad, but it's false suggestion of being "open" makes it deceptively bad, which is even worse.
Whatever. Obviously you're not saying the "no plugin" spiel now, since you got slammed down on that one, but that is what you said originally.
Yes Microsoft began allowing users to chose their preferred software handlers years ago related to the monopoly consent decree (the portions it obeyed). You really are from 1998 aren't you?
Microsoft certainly put in the capability, but the Quicktime plugin crapped all over it and broke it, aggressively taking control of file formats while ignoring user preferences. Besides, I didn't say that Microsoft fixed it, I said either Microsoft or Apple fixed it, I'm not sure who. Since you have problems with this, I'd like to be more clear: STOP MISQUOTING ME! Thank you.
Your claim that IE didn't work with QT and therefore it must be Apple's fault can be challenged by historical precedent recorded in the Monopoly trial proceedings that proved Microsoft purposefully bjorked QuickTime's ability to play back media types, including media types QT could play and Windows couldn't. So it's your guessing against court document proof as to who might be to blame for QT not working under Windows.
I'm not talking about history, Christ. I'm talking about a bug in Quicktime that was reliably reproducible less than six months ago. I don't give a foaming shit about what happened in 1998, you're the one who keeps bringing that up (and then accusing me of living in it!) Get a goddamned grip on reality and hold up for dear life!
I don't give a crap what happened years ago in some trial. I DO. NOT. CARE. The simple fact is that Quicktime Plugin is a piece of crap that broke IE for years and years. That's what I was talking about, nothing else.
I'd be much more likely to dump Microsoft products if the competition, in this case Apple, could write decent software. Now I'm tempted to buy another copy of Vista just to spite you.
I never claimed QuickTime wasn't a plugin.
And I quote:
Silverlight isn't "open" in any useful sense. It's a compiled platform that derails the web and W3C standards to erect a new way to deliver the web in a copycat to Flash: a closed binary presentation.
Maybe, but my Javascript can dive right into the Silverlight XAML DOM, install handlers on Silverlight events, do a very good many things that are impossible to do in Flash.
QT "breaks" IE's ability to display PNG?
Wow, I was just about to sent repro instructions, but it looks like either Apple finally fixed this annoying-ass bug, or Microsoft finally stopped allowing Quicktime to take control of formats.
Wow, who knew IE could even render PNG?!
Anybody who's used IE7. IE6 could, too, it had issues with transparency though.
Hint: you can chose which file formats each plugin renders.
Normally you can, but until recently your beloved Apple's Quicktime plugin would violently take control of the PNG format and never release it. Even if you manually set PNG to another helper, Quicktime would take control of it again and reverse your setting next time you attempted to view a PNG file. For some reason, Quicktime didn't screw with IE when the PNG was embedded.
To make things even more fun, if Quicktime's auto-updater happened to trigger while you were viewing this PNG image, it would lock-up the browser and require a ctrl-alt-delete to fix. Face it, Apple writes shit software.
It's also not Apple's fault you are using a legacy operating system.
This bug was on IE7 and Windows Vista only a little while ago. Those are both current supported versions. And yes, the bug was Apple's fault-- computers without the Quicktime plugin could view PNG files in IE just fine.
So let me see if I've got this straight:
You suggest that Javascript is not good enough if it can't function without an interpreter, BUT...
you are perfectly at ease with Flash and Silverlight...
even though they require interpreters?
No, I'm saying that Java is a piece of crap. Obviously Javascript needs an interpreter to function, but it doesn't need a JAVA interpreter/VM.
Actually, if a javascript app is programmed well/correctly, you can drag and drop on them just like any other application. I've used many a javascript front end that can do so.
Link me to one, please?
Again, if programmed correctly, a javascript app can do what you're describing. I've used many a javascript front end that can do so.
Again, link?
One more time, just for kicks: if programmed correctly, and the java engine is installed correctly, a javascript app can do what you're describing. I've used many a javascript front end that can do so.
Ah, well, there's no way in hell I'm installing that bloated piece of shit Java. If Javascript can't do it on its own, it can't do it period, as far as I'm concerned.
Yes QuickTime is a plugin.
Thanks for confirming your original post was wrong.
Flash is bad because it's a proprietary de-opening of the web, not just because it happens to be a plugin. Everything is getting shoved back into a box owned by Adobe, and Adobe has proven that it has no interest in developing a non-crap version of Flash for any platform other than the Windows PC, where it is only decent.
Then you should be jumping for joy for Silverlight, which is a hell of a lot more open than Flash is, and if nothing else will prod Adobe into improving their product which is badly overdue.
Flash = Office. You can talk about how you can do this and that with Flash that you can't yet do with open standards, but that's like ridiculing OpenOffice for not being able to do some esoteric thing than Excel can, and demanding that everyone just hop into the Microsoft cuddle puddle.
It is exactly like that. There are thousands of things Office can do that OpenOffice can't. The open source fans who claim the product are equivalent always forget to add: "for myself, at least." If the Microsoft "cuddle puddle" helps me do my job easier, then I'll use it. (Hell, OpenOffice doesn't even have Normal View or equivalent yet!)
Web apps also don't need a special JavaScript runtime. The browser already provides that, and you can already save them as freestanding apps using a third party tool.
What tool? I know Mozilla is working on one, but I believe it's still pre-alpha.
My point about using JS to present web video is that Flash is not needed to present player controls prior to the completion of HTML5.
Huh? If you're talking about Apple's website, their controller is managed by Quicktime, not Javascript. If you're saying you can't make a Javascript controller for Flash, you're wrong; it's quite easy for Flash and Javascript to talk to each other. But I really have no idea what point you're trying to make here.
I'm sure you're aware that HTML5 doesn't natively play back video itself either.
Actually, I don't know much about HTML5. I just know it has a video tag because I've read other posts on this topic from more knowledgeable people about it.
In most cases, users would be using QuickTime to do that. Packing up your video in a Flash shell is just a step back into the past.
Quicktime is a bloated piece of crap. Anything that lets me watch video without using it (Flash *and* Silverlight inclusive) wins, as far as I'm concerned. Even having Quicktime installed breaks native features of IE (for example, displaying PNG formats), and I wouldn't trust Apple to code themselves out of a wet paper bag. At least, not on Windows.
Over here we have "10 Items or Less" (or the even better "About 10 Items") checkout lanes next to the cigs, and they all have scales. Unfortunately, they also take checks, which kind of defeats the purpose of an "express" lane, but oh well.
I guess that makes sense, but it still seems easier to me to just install a scale for the checker.