http://blog.csdn.net/ricohzhanglong/article/details/6770762
本文来源于我在InfoQ中文站翻译的文章，原文地址是：http://www.infoq.com/cn/news/2011/09/Future-of-Flash-and-Flex
Adobe想要强化Flash与Flex在企业，特别是在移动领域中的地位。但最近的一项调研表明jQuery已经超越了Flash，成为前17,000个网站首选的Web部署解决方案。
近日，来自Adobe Systems开发工具事业部的产品经理Andrew Shorten在Adobe的官方博客上发表了一篇博文，谈到了Flash与Flex的当前状态，并就Adobe的旗舰平台给出了自己的一些看法。 Shorten承认虽然Flash曾是跨平台Web开发的唯一解决方案，但现在HTML5的发展势头越来越好，也表现出了极强的吸引力：
过去有无数的例子表明Flex是富用户体验的唯一解决方案。但现在，很多应用已经开始使用HTML5相关的技术并通过浏览器交付。在Adobe，我们也向设计者与开发者提供工具来实现这些体验——Edge与Muse就是佐证。
就HTML5以及相关的工具（Edge与Muse）来说，Shorten认为HTML5并不是“万灵丹”，企业出于”性能、框架成熟度以及健壮的工 具“等原因仍会选择使用Flex。Shorten继续谈到了Flex与Flash的主要发展方向，即面向企业与移动，特别是后者。他承诺Flash与 Flex会成为企业业务应用的运行时与开发环境：
我们将会继续加大对Flex在企业级应用中的投资力度，确保开发者可以交付富于表现力、健壮的应用。由于我们会提供未来发布版本 的更详尽的信息，因此大家将会看到我们的承诺来解决很多领域的问题，如Spark组件的实现、可访问性、构建系统集成、性能分析工具以及下一代编译器的集 成，这些举措会保证Flex成为企业级RIA应用的首选。
关于移动开发的未来，Shorten提到：
我们将会继续关注运行时性能、原生扩展、新的组件、声明式皮肤等，并添加更多的平台以及改进工具工作流，这样在下一个主版本发布之际，我们期望大多数应用都可以使用Flex进行开发，而完全的原生应用的需求则会降到最低点。
Shorten对此并未透露太多，只是说在10月1日至4日于洛杉矶举办的Adobe MAX大会上对此将会有详尽的介绍。
我不清楚Shorten为何会发表这样一篇关于Flash与Flex路线图的博文，不过这可能与前一天appendTo, LLC发布的关于全球前17,000个站点的分析报告有 关，这个报告的结果可以概括为：在全球的流行站点中，jQuery已经超越了Flash。appendTo是个提供基于HTML5与jQuery咨询、培 训与开发的公司。根据报告所述，全世界流行站点中的48%已经在使用jQuery进行部署，47%则使用Flash。该分析基于HTTP Archive所提供的数据，后者则是一个搜集Internet数据的组织。appendTo的CEO及联合创建者Mike Hostetler说到：
这些数据表明了这两年的一个发展趋势。越来越多的网站开发者选择了jQuery与JavaScript而非Flash，而这种转换速度则有愈演愈烈之势。
作为曾经的网站之王，Flash已经开始不断失守，其地盘不断被HTML5与JavaScript等Web技术所蚕食。这个势头还会继续下去么？众 多公司是会因为成熟度的原因继续选择Flex还是会等待HTML5工具成熟起来呢？HTML5是否会统治Web开发呢？只有时间能告诉我们答案，但现在我 们可以根据已有的经验猜测一二。
此文一经发布，即在InfoQ英文站引来了众多读者的回应，现摘录几篇评论以飨各位：
读者Dean Schulze说到：
Adobe对Flex的处理方式非常差劲。他们到现在为止也没有提供具备商业质量的Eclipse插件来帮助开发者构建Flex应用。哦，他们对插件收费，但这个插件却是Eclipse世界中最差劲的商业插件了。
Adobe花了好多年才发布新版本的Flex。
由于Adobe的质量一直以来都不咋样，因此除非Adobe的文化发生了变化，否则就别指望Flex能有啥出息了。
现在HTML5标准尚未最终确定，但HTML5却已经超越了Flex，从这个事实就能看出Adobe对Flex的管理方式有多差劲了。
读者Clinton Begin说到：
Flex已经玩完了。主要原因是它几乎没能提供什么东西，用户体验也变得越来越糟。如果说Flex对于开发者来说还不错的话，那 么对于用户来说就太差劲了。此外，Adobe把Flex 4搞砸了，Flex 3.5要更简单，更整洁一些。主要原因在于他们之间的互操作实在是太可怕了，Spark并没有完全取代Halo。恶心啊，恶心。我真后悔在两个重要项目中 使用了Flex。Flex完蛋了。
Flash的未来要更加光明，Adobe可以通过多种手段保持Flash的统治地位。即便人们讨厌player插件，但Adobe可以通过 JavaScript对VM进行移植（有一些开发者可以证实这一概念），他们也可以在编译器级别上解决这一问题，将AS3和FLA文件编译为原生的 JavaScript（其他一些平台已经做到了这一点）。即便他们依旧采用插件方式，他们也依旧可以统治Web，因为微软、Google和Mozilla 与Adobe之间保持了良好的关系。
然而，Flash的使用场景将会发生变化。也许优秀的Flash开发者会承认很多站点都在滥用Flash（请看看那些汽车制造商的网站吧）。在现 在这个年头，网站和广告条不应该再使用Flash了。或许过去这么干是必要的，但现在早已物是人非了。对了，还有视频。只要浏览器能好好地播放，我才不在 乎是Flash，还是H.264，或是Ogg呢。作为最终用户，我不管那么多。
到现在为止，Flash最擅长的领域还是游戏和其他交互式媒体等领域。Flash Player、框架、库、AS3语言和工具大大超出了HTML5所能提供的，他们之间有至少10年的差距。你试着在各种浏览器和设备上使用HTML5来播放音频，看看结果如何。
你可以通过比JavaScript更好的语言和一些基于矢量的创建工具实现这种效果，然后将其编译为JavaScript与HTML5 Canvas，但Adobe在这方面领先很多，至少有10年的优势——更不必说了解这些工具的开发者与设计师的网络效应了。Adobe所需的就是全新的编 译器或是VM（抑或两者兼而有之）。其他人则要从头开始。
因此我的设想是：Flash将会越来越好，或许使用不同的运行时。Flex将会死掉。HTML5将会统治除了游戏之外的其他领域。移动将会依赖于原生代码以谋求最佳的体验（Java之于Android，Objective-C之于iOS）。
此外，像Unity之类的工具/框架是非常有趣的，但最终他们将会变成像Flash一样的插件或是像Java一样的跨平台语言（下面是Mono）。因此他们还需要不断努力才行。
读者Andreas Tasoulas说到：
能够指出Flex与Flash之间的差别，这很好。我完全同意你关于Flex与Flash未来的观点。然而，文章中将Flex与 Flash的处境混为一谈的做法是有误导嫌疑的，做调研的公司说jQuery超越了Flash是有些偏颇的（用他们自己的话来说就是他们是关于 jQuery的培训、咨询公司），这影响到了最后的结果。
读者Alex TicToC说到：
Web上使用的jQuery比Flash/Flex多根本不是什么事儿，要是事实不是这样我反而觉得不正常呢。Flash /Flex不应该用于显示基本信息或是作为大多数简单网站的技术选型，甚至是电商网站。那些饭店的网站使用了Flash，最后只不过是显示菜单，然后通过 PDF下载，这正是对Flash的滥用。
HTML5/JS是个可怕的技术，它可以用于交付企业应用。目前，大多数网站都不是”企业应用“，这个结果不错。语言、工具、浏览器差异性与怪 癖、编写程序/OOP的开发者之间的层次（Google可能没有这个问题）都是前进路上的障碍。现在总有人通过一些手段来提供一些工具：我看到在线版的纯 JS PhotoShop，还不赖。但这并不能说明什么。一群聪明的家伙可以创造出很不错的技术（我想到了PHP）。我还看到有人使用汇编编写出了非常棒的游 戏，很有表现力，但这并不是说汇编就是游戏开发的技术选型。
现在说Flex已死还为时尚早，但我自己也想过Flex的未来，几乎每天都想。
如果你想要开发一个富客户端、跨浏览器/OS的应用，那么Flex依旧是正确的选择，虽说要付出更多的努力（需要Flex专家）。
Flex有很多问题，有很多遗留下来的代码，堆砌的特性、糟糕的设计决策、甚至有时代码质量也很差（我就见过太多了）。但一言以蔽之，Flex是 个框架，它以性能为代价提供了很多特性（你不能去掉大多数特性），除非你是个性能专家，并且洞察Flex的原理，在这种情况下才会保证性能。如果你在配置 不错的桌面机上运行Flex还好。毋庸置疑，Flex在移动设备上的表现不尽如人意。
这几年来，Adobe做过的最糟糕的决策就是重用现有的Flex代码基，然后对其进行一些调整就运行在移动设备上了。笨重的皮肤架构、样式系统对 CPU的消耗、优化失效/验证代码（意指空转运行，因为SDK开发者有时会调用invalidate()，并不是所有新特性都会用上）在移动设备上的表现 并不好。另一方面，纯Flash应用则在移动设备上运转良好！这只不过是膨胀的Flex/AIR SDK导致的性能问题。Flash Player变得越来越好，这都要归功于如Thibault Imbert之类的富有激情的人们。AS3语言则有一些提升。另外，Flex SDK变得越来越臃肿，其架构也没有什么变化（我上一次听说Flex 5将会对框架进行彻底的整理。在2011/2012之际，你可以期望Flex SDK将会演变为基于插件的平台，而不是像意大利面条一样，充满了大量的单例、静态、过程式代码，这些东西都是6年的老古董了）。
在查看Flex SDK的代码时，我常常觉得这是一个基于社区的项目而不是一个真正成熟的面向企业的产品；有几个Flex的领导/架构师是非常不错的，但大多数都不咋地。 对基本的OO原则的违背比比皆是，有时都达到了无法接受的程度（复杂的类继承中，父类竟然完成了子类该做的具体事情）。即便是一些基本的概念，如私有方法 的代码行数不要超过500行这种事情也会经常遇到。
千万别让我用Flash Builder。
虽然有这么多问题，但实际上Adobe并没有真正的对手，我想这种情况会使得Flex成为赢家。
读者Russell Leggett说到：
我觉得”现在“这个词儿是很适合的，这取决于开发者的受众，但确实没有太多的时间了。我曾使用Flex开发过一个大型的贷款发放 系统，但4年前我们却转向了html/js，因为我们觉得采用html/js能够更简洁地实现我们的目标（当然了，还有其他一些原因）。我们之所以这么做 是因为我曾经写过框架的重要代码。我们所实现的感觉并不好，但实际效果还不错，这个经验告诉我们可以通过html/css/js实现与Flex一样的应 用。
我们现在使用了声明式UI和数据绑定，就像MXML一样（甚至比它更好），可以通过JSON、REST和代码生成实现与Java后端的无缝集成。 它拥有一个相当强大的构建系统，可以完成依赖分析，并能自动创建延迟加载代码模块，这样就可以将成千上万行JavaScript代码划分到多个文件中，并 且根据需要进行加载。在开发过程中，我可以在页面刷新时快速重新编译客户端代码。
UI与html/css/js一样灵活，并且现有的第三方组件可以轻松集成进来，同时能够很轻松地编写自定义组件来得到框架数据绑定的优势。
虽然我所开发的框架没法展示出来，但我看到社区中很多人已经开始采取类似的方式开发框架了。有些框架非常轻量级，如backbone.js，有些 则稍微重量级一些，如Sproutcore。虽说工具、文档及解决方案并不一定适合于企业业务，但浏览器与语言却没问题。我们只需从背后的公司获得一些反 馈即可，如微软，它正在大力推进HTML5。甚至连Adobe都开发出了HTML5工具。