5 ms·

I would give anything for someone to explain to me why the right move for Adobe wasn't to simply accept HTML5, pivot from Flash to making killer HTML5 authoring

I would give anything for someone to explain to me why the right move for Adobe wasn't to simply accept HTML5, pivot from Flash to making killer HTML5 authoring tools, and maybe even provide a way for people to take their existing Flash projects and repurpose them to HTML5? How would that have been worse then trying to wedge Flash where it doesn't belong?

Anon84 16y ago
They might be doing that in the background. I imagine that creating new tools from scratch (or heavily modifying existing ones) is a n time consuming process. In the meantime, Flash is all they got to go on with.
sp332 16y ago
Adobe CS5 has some rudimentary HTML5 Canvas export capabilities, and from what I've heard, they plan to develop HTML5 as a fully-supported platform in future releases. http://www.youtube.com/watch?v=v69S22ZBBqA http://www.youtube.com/watch?v=v69S22ZBBqA
- robotron 16y ago
  You beat me to a response. Here's some more info: http://ajaxian.com/archives/html5-tools-from-adobe-html5-pack-available-and-a-future-sneak-peak http://ajaxian.com/archives/html5-tools-from-adobe-html5-pac...
OpieCunningham 16y ago
Clearly they should be doing just that, if they're not already working towards that goal. But I have rather low expectations. If Adobe's theoretical HTML5 tools are anything like Dreamweaver's WYSIWYG HTML editor or, worse, GoLive, they'll produce bloated, terrible code.
marcusbooster 16y ago
Even in current JavaScript engines, drawing with canvas is still pretty slow for the types Flash applications they'd like to promote. Maybe they'll port things in the future but it doesn't seem ready for prime-time now.
leviathant 16y ago
If you can show me how to make audiotool.com or even something like captainforever.com in HTML5 I think I'll begin to see where you're coming from, but there are plenty of things Flash does that HTML5 does not. To flip the switch from Flash 10 to HTML5 would be cutting off a lot of functionality. Saying HTML5 should replace Flash is like saying HTML5 should replace JPGs.
- cryptoz 16y ago
  > but there are plenty of things Flash does that HTML5 does not. Really? Can you mention any specifics? I do not think there are any things that Flash can do that HTML5 cannot. Have you seen Or So They Say? http://xplsv.com/prods/demos/xplsv_orsotheysay/ http://xplsv.com/prods/demos/xplsv_orsotheysay/
  - qeorge 16y ago
    There's a ton of things Flash can do that HTML5 cannot, besides run in nearly any browser (now). P2P video is one example, sound recording is another. That doesn't mean Flash isn't overused. But its not useless either.
  - wmf 16y ago
    Webcams, P2P, advanced audio stuff, DRM (you probably consider this a bug), etc.
    - cryptoz 16y ago
      Webcams? No, HTML5 will probably have support for that. "Advanced audio stuff"?! What do you mean? JavaScript (with HTML5) is a full programming language totally capable of "advanced audio stuff", whatever that means. What do you mean Flash has DRM but HTML5 doesn't? And yes, I do consider DRM a bad thing. Edit: Source for webcam comment: http://devworks.thinkdigit.com/Internet/Native-webcam-support-to-come-with-HTML5_3834.html http://devworks.thinkdigit.com/Internet/Native-webcam-suppor...
      - 16y ago
cookiecaper 16y ago
HTML5 is cool but it's not the end-all. You have a whole set of new issues to deal with when you use HTML5. You have to worry about cross-browser compatibility and specific rendering bugs, whereas Flash authors don't. You have to rely on the slow JavaScript VMs included in even the fastest browsers (even the "fast" JS VMs are still rather slow), and then you have IE, which is still used by > 50% of internet users, of which much is IE 6 or 7, which are outdated and _extremely_ slow. You have audio synchronization issues. There is no ready-made IDE like Adobe's Flash IDE, meaning HTML5 development is much harder for many people. There are other issues too. The fact is that HTML5 is not a reasonable general replacement for Flash. If you want your thing to work for most people, you are going to have to write in Flash anyway. Realistically, only a relative handful of people could run a HTML5/JavaScript program at Flash-equivalent speeds. And that assumes that you just want something in Flash that HTML5 could do; there's still RTMP and significant swaths of other stuff that Flash does and HTML5 doesn't.
- thwarted 16y ago
  This doesn't answer the question of why Adobe doesn't do that, it lists the things that Adobe could step up to do. Yes, we know there is no ready-made IDE like Adobe's Flash IDE: fixing this problem is something Adobe can do, by providing a ready made HTML5 IDE. Why isn't Adobe doing that and leading the charge? There are distinct problems with HTML5 replacing Flash, and Adobe is in a unique position to partner, consult, contract, and contribute to that. For example, if everyone else's javascript VMs are crap and Adobe's Flash interpreter (which is close to javascript, isn't it?) is awesome, then Adobe can help contribute rather than taking a beating from industry leaders (Jobs) and be part of the solution rather than be viewed as part of the problem.
  - nanairo 16y ago
    I think the answer is a common one in free markets: cost. Adobe would need to invest a _lot_ to make a good HTML5 IDE, and what would they get then? At best they'd be in the same situation as they were before just with HTML5 instead of Flash, and on top of that they would have lost control of the platform. So the bean counters find this kind of proposition difficult to swallow. And if you say: but what if someone else did? Then they'll reply: well, then make sure Flash kills anything HTML5 related, and that's how they end up putting a lot of money to preserve the status quo, instead of using their baskets full of gold to make them run faster.
WilliamLP 16y ago
The much glossed-over answer is that JavaScript and HTML just isn't a good environment for rich app development, for many reasons. One "elephant in the room" kind of issue is that JavaScript's object system is not acceptable to most programmers, and most programmers require classical OOP. Even prototype system fanatics probably would have to admit that the current state of JavaScript doesn't work very well, with its warts like the "this" keyword behavior, and the tendency for all framework authors to role their own mutually incompatible systems. Even Google seems to have backed off from this space recently - have you heard much mention of Chrome OS lately?
- warfangle 16y ago
  What are the typical gripes about this keyword behavior? Once you understand how scope works and how to force scope, and what exactly constitutes an object.. it makes quite a bit of sense.
  - WilliamLP 16y ago
    From the Google style guide: "The semantics of this can be tricky. At times it refers to the global object (in most places), the scope of the caller (in eval), a node in the DOM tree (when attached using an event handler HTML attribute), a newly created object (in a constructor), or some other object (if function was call()ed or apply()ed)." The pragmatic answer is to limit its use except when absolutely required (as Google's guide suggests). The more problematic meta-problem, is that many people do think it's valuable and don't understand it and dig themselves into some subtle and insidious messes.
    - mryall 16y ago
      Avoiding something you don't understand might seem like a good idea when programming, but if it's a core part of the language you're using -- like 'this' in JavaScript -- trying to understand it and use it appropriately is actually a much better approach. I've seen JS code that tries to avoid using 'this', and it often ends up a lot more complicated and tightly coupled than code which uses it appropriately. The behaviour of 'this' in JavaScript is different to Java and other OO languages, but it isn't that complicated to understand.
wtallis 16y ago
Migrating to open standards is the right thing for Adobe to do, but that's not how Adobe likes to do business. Adobe is lazy. If there's a problem with their software, they'll blame it on somebody else, because talk is cheap. If that doesn't work, they'll wait until the last possible moment to actually put in the time and effort to improve their code. It's a pattern that is most evident with their Mac software: CS5 (released April 2010) was the first version of the suite that was fully Mac OS X native. (Mac OS X was released March 2001). Prior to CS5, they were still using the Mac OS 9 GUI APIs, which, though they weren't officially totally deprecated until June 2007, were obviously always just a transitional compatibility environment. Even prior to the official deprecation of the Carbon UI APIs, Adobe had plenty of reasons to port to Cocoa. Number one was to provide a truly OS X native look-and-feel, which is pretty much impossible to emulate via Carbon. Adobe's approach to dealing with Flash performance on OS X has been similar. When people complained that video playback was unreasonably slow (ie eating up 5x the CPU time that a standalone player would use), they blamed Apple for not providing them with direct low-level access to the video decoding hardware. When Apple called their bluff and gave them exactly what they asked for, Adobe released a flash player that used those APIs but wasn't noticeably faster for anybody, and introduced several new glitches that made it a step backwards for everybody who's Mac predates the NVidia 9400M chipset. On the Windows side of things, Adobe's PDF reader has been such a long-standing resource hog that third-party PDF readers have garnered significant market share in spite of their lack of support for most of the recent advanced features of PDF. If Adobe would take better care of their PDF implementation, it would be good for the progress of the format overall. Further back, Adobe kept their font format (PostScript Type 1) proprietary and expensive so long that Apple had to create TrueType, and Apple ended up licensing it to Microsoft. Several years later, Adobe abandoned Type 1 in favor of co-developing a TrueType-based successor (OpenType) that is finally re-unifying the font market. Adobe seems to think they're playing it safe by being the last rat off each sinking ship, but one of these days, they'll be too slow.
- gamble 16y ago
  > Adobe's PDF reader has been such a long-standing resource hog It makes me feel old to remember a time when Adobe reader didn't suck. The great PDF support in OSX is one of the things that's most jarring to lose when I use a Windows machine. It's incredible that you have to download a third-party utility just to view PDF files on Windows properly, and none of the options even comes close to Preview on the Mac. In fact, the only aspect of working with PDF files that does suck on the Mac is Adobe Acrobat itself.

Anon84 16y ago

They might be doing that in the background. I imagine that creating new tools from scratch (or heavily modifying existing ones) is a n time consuming process. In the meantime, Flash is all they got to go on with.

sp332 16y ago

Adobe CS5 has some rudimentary HTML5 Canvas export capabilities, and from what I've heard, they plan to develop HTML5 as a fully-supported platform in future releases. http://www.youtube.com/watch?v=v69S22ZBBqA http://www.youtube.com/watch?v=v69S22ZBBqA

robotron 16y ago
You beat me to a response. Here's some more info: http://ajaxian.com/archives/html5-tools-from-adobe-html5-pack-available-and-a-future-sneak-peak http://ajaxian.com/archives/html5-tools-from-adobe-html5-pac...

OpieCunningham 16y ago

Clearly they should be doing just that, if they're not already working towards that goal. But I have rather low expectations. If Adobe's theoretical HTML5 tools are anything like Dreamweaver's WYSIWYG HTML editor or, worse, GoLive, they'll produce bloated, terrible code.

marcusbooster 16y ago

Even in current JavaScript engines, drawing with canvas is still pretty slow for the types Flash applications they'd like to promote. Maybe they'll port things in the future but it doesn't seem ready for prime-time now.

leviathant 16y ago

If you can show me how to make audiotool.com or even something like captainforever.com in HTML5 I think I'll begin to see where you're coming from, but there are plenty of things Flash does that HTML5 does not. To flip the switch from Flash 10 to HTML5 would be cutting off a lot of functionality. Saying HTML5 should replace Flash is like saying HTML5 should replace JPGs.

cryptoz 16y ago
> but there are plenty of things Flash does that HTML5 does not. Really? Can you mention any specifics? I do not think there are any things that Flash can do that HTML5 cannot. Have you seen Or So They Say? http://xplsv.com/prods/demos/xplsv_orsotheysay/ http://xplsv.com/prods/demos/xplsv_orsotheysay/
- qeorge 16y ago
  There's a ton of things Flash can do that HTML5 cannot, besides run in nearly any browser (now). P2P video is one example, sound recording is another. That doesn't mean Flash isn't overused. But its not useless either.
- wmf 16y ago
  Webcams, P2P, advanced audio stuff, DRM (you probably consider this a bug), etc.
  - cryptoz 16y ago
    Webcams? No, HTML5 will probably have support for that. "Advanced audio stuff"?! What do you mean? JavaScript (with HTML5) is a full programming language totally capable of "advanced audio stuff", whatever that means. What do you mean Flash has DRM but HTML5 doesn't? And yes, I do consider DRM a bad thing. Edit: Source for webcam comment: http://devworks.thinkdigit.com/Internet/Native-webcam-support-to-come-with-HTML5_3834.html http://devworks.thinkdigit.com/Internet/Native-webcam-suppor...
    - 16y ago

cookiecaper 16y ago

HTML5 is cool but it's not the end-all. You have a whole set of new issues to deal with when you use HTML5. You have to worry about cross-browser compatibility and specific rendering bugs, whereas Flash authors don't. You have to rely on the slow JavaScript VMs included in even the fastest browsers (even the "fast" JS VMs are still rather slow), and then you have IE, which is still used by > 50% of internet users, of which much is IE 6 or 7, which are outdated and _extremely_ slow. You have audio synchronization issues. There is no ready-made IDE like Adobe's Flash IDE, meaning HTML5 development is much harder for many people. There are other issues too. The fact is that HTML5 is not a reasonable general replacement for Flash. If you want your thing to work for most people, you are going to have to write in Flash anyway. Realistically, only a relative handful of people could run a HTML5/JavaScript program at Flash-equivalent speeds. And that assumes that you just want something in Flash that HTML5 could do; there's still RTMP and significant swaths of other stuff that Flash does and HTML5 doesn't.

thwarted 16y ago
This doesn't answer the question of why Adobe doesn't do that, it lists the things that Adobe could step up to do. Yes, we know there is no ready-made IDE like Adobe's Flash IDE: fixing this problem is something Adobe can do, by providing a ready made HTML5 IDE. Why isn't Adobe doing that and leading the charge? There are distinct problems with HTML5 replacing Flash, and Adobe is in a unique position to partner, consult, contract, and contribute to that. For example, if everyone else's javascript VMs are crap and Adobe's Flash interpreter (which is close to javascript, isn't it?) is awesome, then Adobe can help contribute rather than taking a beating from industry leaders (Jobs) and be part of the solution rather than be viewed as part of the problem.
- nanairo 16y ago
  I think the answer is a common one in free markets: cost. Adobe would need to invest a _lot_ to make a good HTML5 IDE, and what would they get then? At best they'd be in the same situation as they were before just with HTML5 instead of Flash, and on top of that they would have lost control of the platform. So the bean counters find this kind of proposition difficult to swallow. And if you say: but what if someone else did? Then they'll reply: well, then make sure Flash kills anything HTML5 related, and that's how they end up putting a lot of money to preserve the status quo, instead of using their baskets full of gold to make them run faster.

WilliamLP 16y ago

The much glossed-over answer is that JavaScript and HTML just isn't a good environment for rich app development, for many reasons. One "elephant in the room" kind of issue is that JavaScript's object system is not acceptable to most programmers, and most programmers require classical OOP. Even prototype system fanatics probably would have to admit that the current state of JavaScript doesn't work very well, with its warts like the "this" keyword behavior, and the tendency for all framework authors to role their own mutually incompatible systems. Even Google seems to have backed off from this space recently - have you heard much mention of Chrome OS lately?

warfangle 16y ago
What are the typical gripes about this keyword behavior? Once you understand how scope works and how to force scope, and what exactly constitutes an object.. it makes quite a bit of sense.
- WilliamLP 16y ago
  From the Google style guide: "The semantics of this can be tricky. At times it refers to the global object (in most places), the scope of the caller (in eval), a node in the DOM tree (when attached using an event handler HTML attribute), a newly created object (in a constructor), or some other object (if function was call()ed or apply()ed)." The pragmatic answer is to limit its use except when absolutely required (as Google's guide suggests). The more problematic meta-problem, is that many people do think it's valuable and don't understand it and dig themselves into some subtle and insidious messes.
  - mryall 16y ago
    Avoiding something you don't understand might seem like a good idea when programming, but if it's a core part of the language you're using -- like 'this' in JavaScript -- trying to understand it and use it appropriately is actually a much better approach. I've seen JS code that tries to avoid using 'this', and it often ends up a lot more complicated and tightly coupled than code which uses it appropriately. The behaviour of 'this' in JavaScript is different to Java and other OO languages, but it isn't that complicated to understand.

wtallis 16y ago

Migrating to open standards is the right thing for Adobe to do, but that's not how Adobe likes to do business. Adobe is lazy. If there's a problem with their software, they'll blame it on somebody else, because talk is cheap. If that doesn't work, they'll wait until the last possible moment to actually put in the time and effort to improve their code. It's a pattern that is most evident with their Mac software: CS5 (released April 2010) was the first version of the suite that was fully Mac OS X native. (Mac OS X was released March 2001). Prior to CS5, they were still using the Mac OS 9 GUI APIs, which, though they weren't officially totally deprecated until June 2007, were obviously always just a transitional compatibility environment. Even prior to the official deprecation of the Carbon UI APIs, Adobe had plenty of reasons to port to Cocoa. Number one was to provide a truly OS X native look-and-feel, which is pretty much impossible to emulate via Carbon. Adobe's approach to dealing with Flash performance on OS X has been similar. When people complained that video playback was unreasonably slow (ie eating up 5x the CPU time that a standalone player would use), they blamed Apple for not providing them with direct low-level access to the video decoding hardware. When Apple called their bluff and gave them exactly what they asked for, Adobe released a flash player that used those APIs but wasn't noticeably faster for anybody, and introduced several new glitches that made it a step backwards for everybody who's Mac predates the NVidia 9400M chipset. On the Windows side of things, Adobe's PDF reader has been such a long-standing resource hog that third-party PDF readers have garnered significant market share in spite of their lack of support for most of the recent advanced features of PDF. If Adobe would take better care of their PDF implementation, it would be good for the progress of the format overall. Further back, Adobe kept their font format (PostScript Type 1) proprietary and expensive so long that Apple had to create TrueType, and Apple ended up licensing it to Microsoft. Several years later, Adobe abandoned Type 1 in favor of co-developing a TrueType-based successor (OpenType) that is finally re-unifying the font market. Adobe seems to think they're playing it safe by being the last rat off each sinking ship, but one of these days, they'll be too slow.

gamble 16y ago
> Adobe's PDF reader has been such a long-standing resource hog It makes me feel old to remember a time when Adobe reader didn't suck. The great PDF support in OSX is one of the things that's most jarring to lose when I use a Windows machine. It's incredible that you have to download a third-party utility just to view PDF files on Windows properly, and none of the options even comes close to Preview on the Mac. In fact, the only aspect of working with PDF files that does suck on the Mac is Adobe Acrobat itself.