5 ms·

I want Flash to die. I've been a Flash developer for the last five years. I know it inside and out, and I've pushed ActionScript to its limits. It's a great en

I want Flash to die. I've been a Flash developer for the last five years. I know it inside and out, and I've pushed ActionScript to its limits. It's a great environment for web-based, interaction-heavy software, and there's nothing else I'd be able to use instead of it for the sort of work I do. But I want it to die. I can't run a SWF without my MacBook Pro's fans kicking on after 30 seconds, and my battery life dropping to 1/4 of whatever it was. It's a dastardly circumstance, because there are some things you can do with Flash that are prohibitively difficult to do with other tools. JS/HTML/CSS are getting close, but they're not quite ready yet.

statictype 16y ago
I'm not really a Flash developer so I have to ask: Is the only issue you see with Flash that it runs poorly on Macs/Linux? If this is, in fact, the reason that many people hate Flash then Adobe is really dropping the ball by not making this performance issue their highest priority.
- tomjen3 16y ago
  Flash runs poorly on everything, in addition it's sucks battery power like crazy and the language itself is bad. Compare it to the jvm which has been optimized for a decade and a half. But they shouldn't fix it, because it is unfixable. The underlying architecture of the flash language means that performance on an arm processor will always be poor. In summary flash needs to die in a pit of fire and molten brimstone.
  - statictype 16y ago
    What's wrong with the underlying architecture of Flash that makes it poor on Arm?
    - tomjen3 16y ago
      (First sorry for the incoherent rambling above, it made sense when I wrote it) The flash machine architecture (at least last time I read about it, about a year ago) was based on a stack architecture, which is pretty okay on an x86 but doesn't work very well on an ARM processor primarily because it is optimized for register use (and has a lot more registers than is normally used in x86). See also this question [http://stackoverflow.com/questions/2719469/why-is-the-jvm-stack-based-and-the-dalvik-vm-register-based http://stackoverflow.com/questions/2719469/why-is-the-jvm-st...] on stack overflow.
- deleted 16y ago
  [deleted]
- spiralganglion 16y ago
  There are other issues, but most of them sum up well in one word: Adobe. They're releasing Flash as a part of the Creative Suite, which means they've got an update cycle and constantly need new features. Not bug fixes, not refinements or low-level enhancements, but bullet-list-on-the-box new features. This is great if you're wasting time in the authoring environment and you want to paint with the [Art] "Deco Tool", and it'd be fine for real developers as long as these new features didn't encumber the language and were purely "optional". We devs could trust them to expand the appeal of their product while keeping a solid core we can build our code on. Well.. Adobe keeps violating developer trust. They keep allowing new features to mess up the way the Flash APIs work. Here's an example: In CS5, the biggest new feature was the TLF text-rendering engine. For visual designers, it was a staggeringly powerful tool, bringing Flash up to the level of InDesign and Quark for text layout. But this new TLF system wasn't added to the Flash Player * , though it was added to the Flash authoring environment and the ActionScript language. To view SWF files containing TLF text, the Flash Player needs to jump through a few hoops. First, unless the SWF is set to contain it, the Flash Player needs to download a ~150kb file from Adobe to support TLF. This file is stored in the system, so after a given end-user has downloaded the file once, they should never need to again (until there's an update). But the SWF could be set to contain the file, which ensures that TLF text will work for people without internet access, but there are some problems with that (too dry to talk about here). Now, once the user has the TLF file on their machine, the Flash Player needs to load it for the running SWF first, before it tries to render the TLF text. So, the SWF gets an automatically-generated preloader that loads the TLF stuff, which then wraps around all the TLF content. But this preloader starts running after the SWF code, whatever code the author of the SWF has written. So to their code, none of the TLF text objects exist and there's this weird preloader. Then, when the preloader finishes, it doesn't go away. It persists as an additional layer containing the TLF text. So, any code that the dev uses to access the TLF text isn't compatible with non-TLF text because it needs to go through this additional layer (otherwise it would be, straight across, no extra hoops). Worse still, if a SWF loads another SWF that contains TLF text, the standard loading procedure doesn't work and instead causes all sorts of terrible errors, because the preloader doesn't behave well with the normal Loader class. Developers need to download a special "SafeLoader" class from Adobe, and use that to load any SWFs with TLF text. The SafeLoader breaks some of the Loader functionality, so it's not a perfect solution either. Now, all of this would be just plain "bad", not "terrible", were it not for the following: None of this is mentioned anywhere in any of Adobe's documentation, in their API docs, or in any visible place on their support site. In fact, a lot of the API docs for ActionScript in Flash CS5 are now absolutely false and contain incorrect, misleading information. Tracking down these problems and finding effective workarounds has fallen into the hands of developers, with the support of bloggers, with Adobe offering only the SafeLoader class to assist us (and even that is only found by very careful Google searching.. I can never find it on their website.. it's hidden in some obscure support doc). The problem extends further, and messes with other well-established practices and familiar aspects of the ActionScript language and Flash Player environment, but they're too many and too technical to be worth going into here. Suffice it to say, the effects are wide and deep. And Adobe are aware of them, and were even before they released CS5. The TLF fiasco is just one of the more recent, highly-visible problems present for Flash devs, since TLF was the biggest new feature in CS5. Adobe has been a terrible bedfellow at many other turns, and I look forward to the day I am rid of them. * Their reasoning for not adding TLF support directly to the Flash Player, instead requiring a separate file and creating the above nightmare scenario, is: it keeps the (~8mb) Flash Player smaller (by ~150kb); and it allows the TLF to be updated without people needing to re-download the Flash Player (though there haven't been many, if any, TLF updates in the last 9 months it's been out). Words cannot describe..

statictype 16y ago

I'm not really a Flash developer so I have to ask: Is the only issue you see with Flash that it runs poorly on Macs/Linux? If this is, in fact, the reason that many people hate Flash then Adobe is really dropping the ball by not making this performance issue their highest priority.

tomjen3 16y ago
Flash runs poorly on everything, in addition it's sucks battery power like crazy and the language itself is bad. Compare it to the jvm which has been optimized for a decade and a half. But they shouldn't fix it, because it is unfixable. The underlying architecture of the flash language means that performance on an arm processor will always be poor. In summary flash needs to die in a pit of fire and molten brimstone.
- statictype 16y ago
  What's wrong with the underlying architecture of Flash that makes it poor on Arm?
  - tomjen3 16y ago
    (First sorry for the incoherent rambling above, it made sense when I wrote it) The flash machine architecture (at least last time I read about it, about a year ago) was based on a stack architecture, which is pretty okay on an x86 but doesn't work very well on an ARM processor primarily because it is optimized for register use (and has a lot more registers than is normally used in x86). See also this question [http://stackoverflow.com/questions/2719469/why-is-the-jvm-stack-based-and-the-dalvik-vm-register-based http://stackoverflow.com/questions/2719469/why-is-the-jvm-st...] on stack overflow.
deleted 16y ago
[deleted]
spiralganglion 16y ago
There are other issues, but most of them sum up well in one word: Adobe. They're releasing Flash as a part of the Creative Suite, which means they've got an update cycle and constantly need new features. Not bug fixes, not refinements or low-level enhancements, but bullet-list-on-the-box new features. This is great if you're wasting time in the authoring environment and you want to paint with the [Art] "Deco Tool", and it'd be fine for real developers as long as these new features didn't encumber the language and were purely "optional". We devs could trust them to expand the appeal of their product while keeping a solid core we can build our code on. Well.. Adobe keeps violating developer trust. They keep allowing new features to mess up the way the Flash APIs work. Here's an example: In CS5, the biggest new feature was the TLF text-rendering engine. For visual designers, it was a staggeringly powerful tool, bringing Flash up to the level of InDesign and Quark for text layout. But this new TLF system wasn't added to the Flash Player * , though it was added to the Flash authoring environment and the ActionScript language. To view SWF files containing TLF text, the Flash Player needs to jump through a few hoops. First, unless the SWF is set to contain it, the Flash Player needs to download a ~150kb file from Adobe to support TLF. This file is stored in the system, so after a given end-user has downloaded the file once, they should never need to again (until there's an update). But the SWF could be set to contain the file, which ensures that TLF text will work for people without internet access, but there are some problems with that (too dry to talk about here). Now, once the user has the TLF file on their machine, the Flash Player needs to load it for the running SWF first, before it tries to render the TLF text. So, the SWF gets an automatically-generated preloader that loads the TLF stuff, which then wraps around all the TLF content. But this preloader starts running after the SWF code, whatever code the author of the SWF has written. So to their code, none of the TLF text objects exist and there's this weird preloader. Then, when the preloader finishes, it doesn't go away. It persists as an additional layer containing the TLF text. So, any code that the dev uses to access the TLF text isn't compatible with non-TLF text because it needs to go through this additional layer (otherwise it would be, straight across, no extra hoops). Worse still, if a SWF loads another SWF that contains TLF text, the standard loading procedure doesn't work and instead causes all sorts of terrible errors, because the preloader doesn't behave well with the normal Loader class. Developers need to download a special "SafeLoader" class from Adobe, and use that to load any SWFs with TLF text. The SafeLoader breaks some of the Loader functionality, so it's not a perfect solution either. Now, all of this would be just plain "bad", not "terrible", were it not for the following: None of this is mentioned anywhere in any of Adobe's documentation, in their API docs, or in any visible place on their support site. In fact, a lot of the API docs for ActionScript in Flash CS5 are now absolutely false and contain incorrect, misleading information. Tracking down these problems and finding effective workarounds has fallen into the hands of developers, with the support of bloggers, with Adobe offering only the SafeLoader class to assist us (and even that is only found by very careful Google searching.. I can never find it on their website.. it's hidden in some obscure support doc). The problem extends further, and messes with other well-established practices and familiar aspects of the ActionScript language and Flash Player environment, but they're too many and too technical to be worth going into here. Suffice it to say, the effects are wide and deep. And Adobe are aware of them, and were even before they released CS5. The TLF fiasco is just one of the more recent, highly-visible problems present for Flash devs, since TLF was the biggest new feature in CS5. Adobe has been a terrible bedfellow at many other turns, and I look forward to the day I am rid of them. * Their reasoning for not adding TLF support directly to the Flash Player, instead requiring a separate file and creating the above nightmare scenario, is: it keeps the (~8mb) Flash Player smaller (by ~150kb); and it allows the TLF to be updated without people needing to re-download the Flash Player (though there haven't been many, if any, TLF updates in the last 9 months it's been out). Words cannot describe..