先帖上内部人士的：内部人士说，Flash 是这样作死的，而 HTML5 的路也不一定好走
以及偶然翻到的比较不错的一篇：大漠穷秋：Flex七宗罪
再帖一个我11年写的：千万不要使用Flex组件，也就是《死之一：Flex》，本文也可算做是第二篇《死之二：编译》。
----------------------正文开始--------------------
Flex组件搭界面的MXML是种编译型标记语言。
并且在里面插入逻辑代码，甚至支持CSS皮肤。
看起来与HTML开发方式完全一样，
并且更先进了，因为会有代码提示、编译器错误检查等。
JS显然被秒成渣（后来微软做TypeScript，谷歌做Dart都是因为意识到JS的缺陷）。
另外当时（在html5标准还未被浏览器广泛实现之前）AS3还有其它优点，
比如图形API把html秒成渣，有socket通信把http秒成渣，客户端小型数据库把HTML的COOKIE秒成渣之类……
但为什么这么些年过去了，不要说取代HTML，反而都很少见到Flex应用呢？
除了网页游戏和视频网站，连Flash网站都很少见到了？
可能问十个人有十种不同的答案，比如上面那篇内部人士的。
事实已经证明，我也已花了很多时间写了一个AnyBuilder来证明，
并且历史将更加清晰地证明：
Adobe公司的Flex组件以及为它专门设计的编译型标记语言MXML，
是一种愚蠢的设计，必将遗臭程序史。
将多种需求混合在一起，用自己可怜的工人工时与资金验证了一次
编程复杂度公理，完美的诠释了愚蠢一词。
今天又写此文，主要是以补充的形式聊一下除了那些显而易见的，很少人注意到的一些方面。
ActionScript这个语言，虽然叫做“Script——脚本”。
但却不像一般脚本语言那样不需要编译就直接运行，其实是一种与C或JAVA一样需要编译的语言。
准确的说，是模仿JAVA的语言，与JAVA一样是产生预编译字节码然后在运行时给虚拟机执行。
也可以叫做仿制品。理论上来说，运行效率应当达到JAVA同等档次，
但实际上，运行效率差到人们总是拿来跟js比，颇有一语成谶的味道。
AVM效率有多差，adobe的开发水平就有多差。
另外各种成筐被黑客利用的漏洞，JAVA就没有。
编译型语言的特点是编译器会检查明显的错误，
而代价就是是编译需要更多时间。
而且由于adobe的烂编译器，比巨头公司作品应有的速度要慢很多，
与JAVA比就是垃圾。
这里首先讲一个真实的例子，一个大型IT公司，里面基本都是做JAVA的，
接的都是大企业或政府的企业应用之类大单。
有天他们开始用Flex做前端。就这样过去了两三年，他们积累了一个Flex的库。
而骇人听闻的是，这些JAVA或C++的老练程序员甚至大神们，
竟然没有一个人知道FlashBuilder里Flex项目的模块化编译功能。
甚至连制作SWC都不知道。
也许他们会制作SWC，但是不知道把自己的库做成SWC的理由。
因为JAVA编译器速度很快，很庞大的代码编译时间也不用几秒，
所以他们下意识的认为库项目即使编译成SWC也不会提高多少编译速度，
或者还认为（其实是臆测）SWC和SWF各编译一份更麻烦，增加编译时间、增加开发成本。
到最后，他们哪怕修改一行代码，编译的时间也是十分钟。
（嗯，连增量编译都已经残痪了？）
当然这是一个极端的例子，我相信大部分使用Flex的开发者们没有蠢到如此地步。
或是编译时间达到2分钟项目就已经失败或者公司倒闭了。
我是要说明，Flex编译耗时间。
而上面那个例子即使用了最好的模块划分与运行时库加载方式，
编译一次还是会超过一分钟。
所以，编译次数的增加是导致Flex项目开发时间增加的主要原因。
时间增加也就是成本增加，这个算式函数图像大概是（成本=编译时间的平方）这样。
另外，使用炼金术（现在叫CrossBridge）产生的swc，
似乎是无法使用外部链接库形式的，也就是external link，不将导入的代码编译进来。
更离谱的是增量编译也失效了。
比如lua引擎的swc就是这样，五百多kb，使用它的项目每一次编译大概都要而三十秒。
而且的而且，我做AnyBuilder演示程序的时候发现Ant编译导入这个lua.swc的项目会报错
只能用FlexBuilder里面的工程编译……
总结的说，程序员会感觉开发变得枯燥甚至令人抓狂。
Flex组件可以制作皮肤，而且是可视化的。
这个听起来很牛逼。但有个问题就是制作皮肤居然也需要编译！
谁见过会用Flash Builder的美工呢？
所以adobe又做了个Catalyst，但是一样要编译思密达。
而且电脑多开一个软件的话变卡变慢工作效率还是降低。
后来adobe在CS6中还去掉了它，
嗯，又一个浪费千百万美元的的孩子……
用Flex制作大型项目，想要编译不慢，必须用项目拆分+运行时载入模块技术。
我做包含AnyBuilder演示程序在内的这个网站，就纯AS工程，纯AS啊，不是Flex啊，都分了五个，
编译出的程序本身几乎不携带依赖库，只有几十k，还有个忽略不计的壳，也就是加载器。
而这即使只有几十k的程序编译也需要十秒以上！
Flash如果死了，那是他该死，这是它该死的理由之一。
大家都在追求动态化了，减少编译，但adobe来个倒行逆施！把本可以动态解析的东西编译。
用一句中国的话讲，叫逆天而行，自取灭亡。
现在讲讲反复修改设计这个事情。
（嗯，我相信大部分IT工作者都看过许多副讽刺、抱怨客户或设计师修改设计的GIF或表情图片）
反复修改导致的结果就是，一个大型项目使用Flex开发的成本远远超过了HTML。
那么客户会选择谁呢？这是显而易见的。
当然曾经也有过自以为能用Flex做高端大气上档次东西的团队和公司，
给客户报跟HTML差不多的价格，然后做完亏了甚至没做完就亏死了的。
幸好我没有用Flex做过大型项目或者是被坑倒闭的老板或CTO，
否则你们今天看到这篇文章里一定写满了将adobe的人千刀万剐之类最恶毒的curse。
说Flex是死了的可能有点过分，但是说它害死了一些公司，说与市场占有率几乎没有，一点都不过份。
顺便，AVM执行效率的问题，我也发表一下自己的看法。
我不像乔布斯那么strict严厉，
换我是乔布斯我可以让Adobe上苹果。
纯AS做个web应用应该还可以，但如果是Flex的大型项目，
我觉得消耗之高，甚至可以让某些中国产安卓山寨手机的电池爆炸。
再做个实验告诉全世界这玩意的能耗是多么可怖，
并且附上《Avm2虚拟机浅析与as3性能优化（陈士凯）.pptx》这样一些分析分析Flash核心技术如何渣的铁证。
最后堂而皇之的毙掉它。不毙也没关系，市场会自然的淘汰。
乔布斯那么做一方面也是想让多些开发者去学他自家的开发语言。
背负一些as开发者的咒怨，总比允许安装flash，然后被广大消费者抱怨电池不够用好吧？
再说万一开始就允许安装运行flash，然后flash借此机会做大，
adobe真的招到几个大牛把avm和编译器做好了，那苹果自己obj-c的市场份额必定要被攻。
编译型语言，一个小错导致程序不能编译，
这是好处，帮助程序员发现错误，但也会带来不便，
就是一旦出错就需要先排错，否则不能测试或调试。
这在团队开发中会导致测试程序极其不便，
我在《如何解决契约（接口）修改的相关问题》中进行了比较详细的描述。
另外这里还有一点一般人注意不到的事情，就是程序员心理压力会增大。
心理压力增大，这个又会导致各种做不好事，尤其是心理素质本来就不好的人。
Flex组件，准确的说，是MXML的设计者当初也是有一些无辜的。
因为首先他们没有想到修改在项目开发中所占用的时间。
而编译（2次，先编译成as3再编译成SWF/SWC，另外皮肤也要编译）型的的标记语言可能是傻X领导或C？O的想法，
上面这么说了一声他们就这么做了，没有想那么多。
尤其没有想到的是编译器团队会把编译器做的像渣一样,
可能速度连JAVA编译器的三分之一都没有，
doc编译器各种语法不支持、连包文档都不支持……最可恨的是，只修改注释或格式缩进也会引发编译！
更尤其的是想不到三五年都没有改善。
甚至可能还自以为是编译型语言，运行效率能超越HTML（+JS）而沾沾自喜。
其实HTML里面组件基本都是c++之类写的，只要js写的没有效率问题，一样的东西Flex效率连HTML都不如。
Flex一词翻译为灵巧轻便，可实际却如老弱病残一般，
与ActionScript命名的一语成谶相比，Flex之冠名可以说是自我讽刺，不管是开发的桎梏还是程序运行的效能。
也许Adobe内部也有人提到过运行时解析的方法，如果真的那么毫无疑问被领导、同事否决了，甚至被自己否决。
组件的设计制作，除了id一个属性，可以也应当完全与标记语言特性无关。
脚本也是一样。
Flex组件为了成为“可使用标记语言进行可视化设计”并且与“脚本无缝融合”的组件
违反了这个原则，导致的后果就是大大增加了复杂度
（编程中两个问题混合在一起复杂度通常不是他们相加而是相乘甚至幂）。
比如设计师自以为是才气冲天传世经典而在我眼中就是个毒药的双向绑定机制。
UI组件编写可以只要很少几个人，可以由一家游戏公司在开发商业项目中顺便开发出来。
也可以像aswing那样只用一个人从其它语言的成熟组件库移植过来。
脚本语言也可以成本很低的由开源社区很快的开发出来并且向多种语言移植（比如lua）。
甚至可以由一个人完成，比如网名“dayu”一个人开发的AsScript，
比如csksoft.net上那样的脚本。又比如AS3EVAL。
做一个解析标记语言并集成脚本语言的工具也只需一个人（我这个工具就是）。
甚至IDE开发也可以只要一个人（JAVA SWING的可视开发工具似乎已经多到不好数）。
AS3,AVM是在模仿JAVA那样在虚拟机中运行预编译字节码的语言，
但是它不像JAVA那样可以编译一份jar，在开发时导入使用与运行时载入可以都可用这一份。
同一个库的代码要编译两份，swf不能开发时导入，必须要导入swc；swc又不能运行时载入，必须载入swf。
而且最他妈让人堵的是，Flash Builder一个库你要编译成swf，要先编译成swc再拿他编译swf，
不然你想直接编译成swf的话，就得要写一个导入所有类的空壳“主程序类”去编译，
主程序类没导入也没间接导入的类，是不会编译进去的。
所以很多人或公司要用ant之类写个脚本来生成导入库里所有类的“importer”。
就打两份包这一点看似不算事的事，也是做死flash的原因之一。
（其实这也反映出adobe技术之低劣,“窥一斑而知全貌”）
因为这个事就导致一个问题：
每一个被依赖的库或模块项目要不要分别做导入库工程与运行时加载库两个？
被依赖代码不编译成SWC库，而是在引用这个库的项目中以源代码形式导入它，
也就是说编译时就要编译它的代码，这等于没有拆分，对于解决大规模工程的超长编译时间问题是没有作用的。
大规模工程，准确的说，是发布的程序体积大到不能一次加载所有的时候，
应当使用运行时加载库技术，
而对于Flash来说，则更加必要。
因为Flash主要使用场合是在浏览器，运行要从网络读取，
即使是移动设备App，体积大也会导致不利推广，安装量减少。
如果运行时加载库（swf）不用Ant而是用Flex Builder工程来生成，
并且要做干净，做到不把依赖的库代码和测试的代码编译进来，
那就需要一定的技巧了。这些事情对不够聪明的程序员是会很头痛的。
除非库项目不做测试，或者多个库用一个公用的工程测试。
有人说在最终产品工程里面做到很好的管理测试他们的单元测试、用例测试等测试代码？
不嫌release慢你们就这么做吧……
且必然导致发布目录多了一大堆无用的垃圾文件。
这些麻烦都是因为残废的FlashBuilder，项目不能像JAVA IDE那样既编译swf又编译swc。
这个功能很简单，但做了这不说七八年，起码五年都没做出哦！
而Flash却一直可以喔，就是拿来做时间轴动画的那个Flash！专业的编程IDE不如做动画的软件哦,
哦哦哦哦哦。就连第三方免费的FlashDevelop都有编译swc插件的。
所以我们的“模块”工程都要建立一个swc库项目供最终产品和其它工程引用。
然后再建立一个工程，用来将它编译成运行时加载的swf，并且里面可能还带有用于测试的程序，看起来很傻不是吗？
除非开发人员会使用ant来生成swc。
诸位老板、C?O，知道什么是ant吗？不知道？而且你们公司没有用？
好的我估计你当年的Flex项目是亏损的或者你那家公司倒闭了。
而且，由于adobe官方的编译器使用手册，
中对ant脚本写法讲的不是很详细，项目复杂的情况下可能又遇到奇怪的问题。
这样，工程的数量又增加了。
然后我们会发现我们又需要ivy、meaven之类的东西了。
还有swf文件要复制到测试、产品工程等等……
好的，这样稍微复杂一点的ant脚本就需要ant-contrib中的增强功能来实现了。
Ant和Meaven好像没有完全的中文手册，Ant-contrib更没有，
没有一个英文好的程序员，这种活就得花时间上渣度各种查，
这些也是技术成本啊，技术成本增加，也是增加开发成本对不对？
把调试和测试代码装在编译条件变量装起的语句块里面。
在产品发布版本时关闭这些编译条件。
这样可以随意在代码中插入调试、测试代码，
并且不用逐个做记录在交付客户时全部删除他们。
这是很好的开发方式，显著提高效率，也是我开发中几乎唯一的“敏捷”手法。
条件编译在AS3诞生之初就有前辈发表过，但是有几个人会呢？几个人用了呢？
一旦使用了条件编译，则使用ant几乎就是必须的了。
因为ant脚本可以做到通过询问来方便的在编译时选择编译条件。
除非你们也能想到或被人告知用ant脚本修改工程属性文件的做法（没错，怎么也得用ant），
不然每次发布产品版本或模块版本演进，都要做一次很烦的操作：
在FlashBuilder每个工程属性里面把编译条件的属性值改为关闭，然后使用发布功能发布工程。
最后还需要再改回来以进行正常的开发。
实际上我不只写编译的ant脚本，还写了一个修改FlexBuilder里项目属性的ant脚本，
通过用这个脚本修改项目的配置文件来切换发布版本与开发版本。
另外补充一个：弱到爆的文本渲染。
这也是被所有咒Flash死者忽略的重要一点，AS3的文本框仅支持少量的HTML标记，
连pre、hr（就是所谓的分割线而已）都不支持，CSS也是弱到爆。
说起来是AS3强大，HTML弱，
但是强大的东西为什么连弱到爆的东西的功能都做不到呢？
AS3做网站，如果可以轻松的载入并呈现HTML内容，对于WEB市场冲击的能力会有多高？
如果很多HTML源码可以直接拿到Flash里面呈现，整个业界将会产生如何巨大的波澜？
当时肯定也有web程序员去学as/flex的，但是文档打开一看“卧槽！”
这么几个html标记掰着指头都数的过来，打发叫花子呢？！
2008年做一个在AVM里面跑JS的“壳”，还是几年后做AS3把编译成JS的开发工具，
这就是远见卓识与眼光短浅的区别，然而历史无法改写。、
还有比如，Flash Builder基于eclipse，却连Mylyn这么简单且常用的插件都不支持。
请允许我再念叨一次“窥一斑而知全貌……”
总结：
很多做Flex/Flash后来转其它技术了的人，他们可能是“死”的不明不白的。
我写这篇文章时，正逢adobe宣布flash改名animat，
而满网络已经可以说四面楚歌了。
也许adobe依旧会继续做avm和swf编译器，
而我是不关心了，因为做下去也是那么烂。
我已经下决心把自己写的东西往JAVAFX/HAXE等其它语言移植了。
这篇文章的主要意义，是帮助那些做flash做死了的人死的明白一点。
Flex组件不仅是垃圾，更是一个浪费上数千万美元的罪孽。
顺便还把整个Flash技术拖累致死，
最后还抛给Apache，浪费别人的时间，消耗人类时间。
即使有些页游公司赚到大钱，但Flash给人们带来的损失总计是一个天文数字。
当小页游公司开始倒闭，泡沫破裂，页游大潮落下后，
而普通应用开发（尤其是移动端）因为Flex组件太垃圾又做不起来，
这就意味着flash无法侵入这个占IT业大部分产值的市场。
这样AS3市场需求骤减，导致岗位与待遇骤减，
逼迫大量程序员刚掌握AS后就转向其它语言。
他们多少都是有怨恨的，你们看到那些从Flash转其它语言，
时不时随口吐个槽的就是有这种原因在里面。
最后，话不应该讲死，Flash到底死了没？肯定也有人要说Flash没死的，
adobe现在在开发工具上还有点优势，
尤其是一些中国区前员工搞的白鹭，另外还有腊鸭，真可谓是救命稻草。
AS再衰，有这两个平台在，那么起码不能说死了。这也是中国崛起在IT业的征象。
即使真死，我这文就是给他烧香了。而且死灰也可复燃。
（本篇完，感谢您的耐心阅读，但是以后应该还有续篇）