Egret 的 童话 与 现实

[finscn]

Egret 的童话与现实

我要变成，童话里，你爱的那个天使 ……

你哭着对我说，童话里都是骗人的 ……

---

写在前面的一些话，不必要，但重要

我一直很少谈论Egret引擎，因为我对这样一款『打着HTML5游戏引擎旗号，实际以拉拢Flash开发者为主旨』的奇怪引擎不感冒。

但是最近Egret越来越多的出现在我的生活和工作当中，让我无法再继续无视它的存在。最近正好Egret联合创始人之一的7yue老师在知乎里阐述了一些Egret的想法和理念 ( http://www.zhihu.com/question/27078280 ) ，那我也就顺着那篇文章，把我的一些观点也拿出来说一说吧。

在开始之前，我先交代一些事情：

• 写这篇文章的初衷，只是发表个人的观点，并不是『为了Egret好』。我没那么伟大，也没那种影响力去改变已经发布到1.5版本的Egret。
• 我们在谈论一件事时，其实很难把『人』的因素完全剥离开，所以『对事不对人』这种说法根本是异想天开。我说的每一句话都可能因事而伤人，先说声对不起了。
• 我不太会“有话好好说”，有时候会显得气急败坏、尖酸刻薄，不求大家的谅解，只求被冒犯者能够看开点，别把我当回事。
• 如果你觉得 我也是做技术的，我是因为『同行相轻』才看别人的引擎不顺眼的 ———— 那么，请你坚持自我，继续保持这种观点吧。像你这么狭隘的人 未来会很珍贵的。
• 我和Egret不存在任何竞争关系。相反，它的本意是来帮助我这种HTML5游戏开发者的。
• • Egret的联合创始人7yue老师是我很欣赏的Flash传教士（技术传教士想让我这种自以为有独立思考能力的人欣赏其实是挺难的，但7yue老师做到了）。他还曾经很热心的帮我介绍过投资人，对我有恩。
  • HTML5梦工厂的创始人田爱娜 刚刚加入了Egret团队。娜姐是我这一生的贵人，没有她就没有现在的我。
  • 所以，请你们相信，当我对Egret说出冒犯的话语时，最受伤的人是我自己。这倒不是因为我心理会很愧疚很难受什么的（那太装逼了），而是因为『当我用恶劣的方式对待爱我的人时，其实我也扼杀了别人继续爱我的可能』。所以我的损失才是最大的。当然，这是我咎由自取。

好了，扯了一堆没用的 进入正题吧。直接点，先抛观点：

• Egret如果能不用TypeScript 而是直接使用JS ，同时抛弃掉对Flash的傻傻痴恋 ，那么Egret会离成功更近一点。
• 在WebGL面前，Egret runtime的价值有限。
• Egret的那套开发工具才是一切的关键，也是最大的困难之所在。

我的整篇文章 都将围绕且只围绕上述几点展开。不喜欢 不感兴趣的，可以撤了。

---

Egret 与 TypeScript , 是童话还是谎言?

7yue老师的文章里第一个阐述的问题就是 Egret 为什么选择 TypeScript ,总结一下有以下几点:

1. TypeScript 是 ES6 的超集，将来ES6普及时，可以平滑的过渡到ES6
2. TypeScript 弥补了JavaScript 的不足, 可以帮助开发者开发更有规模，更成熟，更有质量的游戏项目
3. 更类似于ActionScript3.0的语法，可以用TS基于Canvas来封装跟Flash ActionScript3.0类似的API结构设计。

我觉得这几个观点都有些问题。

首先，TypeScript并不是ES6的超集，更不是子集，只是有很多交集而已。TypeScript的代码现在以及未来都不大可能『不借助TS的编译器编译，直接跑在浏览器里』。

虽然它和ES6语法上的确实相像，但是这种相像意义不大，他们就是两种不同的语言。类似的，UnityScript和JS也很像，C#和Java语法也很像一样，但本质上就是不同的东西。

认为『TypeScript 就是 ES6的提前实现，学习TypeScript 就相当于学习ES6，就是提前与未来接轨』的想法是不对的。

TypeScript就是一个借鉴了ES6的语法，但是加入了types，不支持异步yield await的 js transformer 。真想提前与未来接轨，请直接学习真正的ES6，ES6 to ES5 的transformer已经很成熟了。

其次，目前的JS确实有很多不足，一个用10天时间写出来用来应付差事的语言能有什么好的(BTW：从语法层面，我最喜欢的语言是 AS3 和 Python2 ，作为有多年Basic + Java + PHP经验的人，喜欢这两种语言一点也不奇怪 ）？

但是为了弥补这种不足，我更建议选择真正的ES6，而非TypeScript。而且什么module啊、classes啊 ,在ES5时代也早就有成熟的解决方案了，虽然这些方案不够统一，不够完美，但是早已被广大程序员所熟悉和理解，也经过了足够的验证，是可用和好用的。

TypeScript真正带来的价值（标准ES6无法提供的）基本上只有types，编译期的类型检查。给弱类型动态脚本语言加入类型检查，这么多年一直是很有争议的一件事。早在ES4里就尝试加入，结果最后连自己都悲剧了，后来ES6里又想加入，后来又去掉了，计划在ES7里加入……

不可否认，类型检查是有好处的。但是它的好处大多数也仅仅体现在『有助于减少在编码期因失误造成的拼写错误等低级错误的发生』。也许有人会说，这个好处已经足够了，配合强大的IDE可以更好的开发复杂的企业级项目，尤其那种大型团队，成员众多，水平良莠不齐balabalabalabala…… 他们说的就跟如今PHP Python Ruby 和JS没开发过大型项目似的……

另外，『TypeScript并不强制要求变量指定类型，并且可以和兼容ES5的传统js代码混用』这点，很多人把它看成是优点。那些有这种想法的朋友，你们确定这是优点吗？是优点吗？是吗？一边说『有了类型检查 再也不怕开发大型 起夜急 项目了』，一边对『可以和兼容ES5的传统js代码混用』持认可态度的人，精分的真是可以了。

说了这么多， 其实我想表达的不是TypeScript一无是处，而是我们没必要把它神话。他就是诸多js transformer里的一个，还不是最好的那个（没有最好 ———— 后半句自己心里默念一下吧，我懒得打字了）。

我觉得7yue老师说的那几点里，让他选择TypeScript最直接的原因只有第3点：『更类似于ActionScript3.0的语法，可以用TS基于Canvas来封装跟Flash ActionScript3.0类似的API结构设计』。

我必须强调一下，我不是说Flash那一套不好，更不是觉得AS3不好（但是总有人不信）。而且我对Flash的感情不比任何Flash开发者少，毕竟我们这一代70后80初的人 也是看着Flash动画长大的。当年的闪客帝国给我带来过无数美好时光。而且我很多游戏开发的技术都是从Flash游戏开发的书籍里借鉴学习的。

但是，我特别反感『把HTML5弄成Flash那个样子』的做法。 简单的说：我觉得我们可以借鉴Flash里好的设计思想，更要保留和发扬Flash领域里那些优秀的经验，但没必要在API层面去模仿Flash和AS，而属于HTML5自己的特点和优势。
而且这种模仿甚至会把Flash里的那些坏味道也带进来。典型的就是那个MovieClip，我都无力吐槽了，从名字到内部设计，根本不是为游戏准备的。

引领『模范Flash的API，以便让Flash开发人员更容易上手』这种思潮的框架/引擎 自然是大名鼎鼎的 easelJS 。后来我在盛大也和同事李正林（其实主要是他）搞的QuarkJS也是类似的东西，虽然自己参与其中，但是一点不喜欢。

说句题外话：也许有人会说，哪个社区不都是如此？NodeJS的兴起不也是因为搞JS的人『喜欢JS那一套东西』，所以balabalabala…… 但是这里面有一个本质的区别：NodeJS是充分挖掘了JS本身的特质和功能，让JS可以做更多的事情，而不是用JS去模拟其他某种语言，更不是从JS代码翻译成其他语言代码后再去执行。

好，把话题拉回来。虽然我不喜欢『模仿Flash的HTML5游戏框架』，但是我对『模仿FlashPunk和flixel这类Flash游戏框架』的做法是持肯定态度的。我的这两种态度并不矛盾：

Flash是提供渲染、音频、输入输出、网络等功能的底层架构，HTML5也是提供渲染、音频、输入输入、网络等功能的底层架构。而FlashPunk是构建在Flash上的上层游戏框架。在上层框架范畴内，我觉得可以借鉴Flash领域的任何优秀的产品（思想 算法等）。但是没必要先去用HTML5模拟一套Flash。

这就好像北京和广州都可以到上海，当你在广州时，没必要先飞到北京，再从北京飞上海。

而这种喜欢用HTML5模拟Flash的人，通常有一个常挂在嘴边的理由：这样就可以用那些Flash领域里的成熟的工具来辅助开发了。一个典型的（也是唯一一个有点现实意义的场景）是：在Flash的IDE里导出的动画描述文件（json格式）可以被这类仿Flash的引擎直接使用。但是懂技术的都懂，这根本不需要模仿Flash，这只和json的解析方式有关。
而从集Flash和HTML5技术之大成的Adobe公司所做的Edge系列的品质，我们就能明白其中的真实价值到底几何了。

我们可以梳理一下Egret所做的事情:

1. 用TypeScript来模拟Flash的体系结构
2. 然后生成JS
3. 去做HTML5能做的事情。

这么折腾一圈之后，除了对初级Flash开发人员更友好（中高级的可以轻松驾驭HTML5，不需要折腾，例如Egret团队里的那些Flash程序员）之外，其他的意义并不大。

而7yue老师文章里几句看似一带而过的话，也从一个侧面印在了我的观点。也许这些话才是Egret团队潜意识里选择TypeScript的真正源动力：

1. Egret使用TS，一方面是为了让JS游戏开发人员更舒服些，另一方面是考虑到Flash AS3这个开发群体，不争取的话，慢慢都流失掉了，很可惜。
2. Egret里我带的这帮人以前是做Flash Pro，Flash Builder，Flex GUI和众多工具及框架的技术，很有经验

第一句只看后半句就好，因为『让JS游戏开发人员更舒服些』是个伪命题，大多数我接触到的JS开发者都只是觉得别扭。

而第二句，我是不是可以这么理解：因为Egret团队的人对Flash特别特别了解，所以把HTML5模拟成类似Flash的东西后，才能更快速的展开后面的计划？

而Egret产品线里有一款叫TS Conversion的工具, 它的存在也让我进一步巩固了我的这一观点：

TS Conversion是一款语法转换工具，能够快速将Flash游戏代码转换成Egret游戏代码。

以我对Egret团队的了解，他们完全有能力针对HTML5技术本身的特点去开发引擎、工具等等，但是他们就是放不下Flash的情结，这就是我前面所提到的『对Flash的傻傻痴恋』。
而这种痴恋其实里外不讨好。知乎上那位一直说『Egret很好，要是把TS换成AS就更好了』的Egret拥护者，似乎也验证了这点。

我们可以很容易的分析出 Egret + TypeScript的组合，对开发人员友好度的排名情况（从最友好，到最不友好）：

1. 熟悉Flash，也熟悉HTML5，但Flash情结严重。
2. 熟悉Flash，但不熟悉HTML5
3. 一张白纸，什么都不熟悉，不管用什么引擎，都要重新学习
4. HTML5游戏开发者

Flash，Flash，Flash …… Egret的一系列选择，一直在向我传递着一个信号：Flash为大。

也许Egret的开发者的初衷并非如此，但是证明你的，不是你的心，而是你的所作所为。

在这里插播一件几个月前我在某群里和一位资深Flash粉之间发生的趣事：
他在群里说Egret好，靠谱，牛逼。我问他，你用过吗？他说没用过。我说那你为什么说他好？他说，因为这是从Flash社区出来的人做的，我相信他们。

这…… 还真是让我感动呢，计算机信息技术专业要变文科了？

唉 不说了，说多了全是口水，弄得好像我和Flash社区势不两立似的。其实我不喜欢的是JS社区，而flash社区一直是我学习各种游戏开发知识的宝库（有我发过的无数条黑js，夸flash的微博为证）。所以，大家千万别误会。

既然已经聊到了开发工具，那我就顺势离开TypeScript这个的话题，聊聊Egret的开发工具吧。

---

Egret 开发工具， 任重而道远

这个其实没什么好说的，我个人很认可7yue老师说的那段Egret对开发工具的观点：

要想在市场立足，在最短时间内做出来的产品的“核”也就是中心思想很重要，它不必拘泥于是否先要有个IDE来承载这种形态，市场需要的是最有效率的工作流，其次才是一招打遍天下的IDE集成开发环境，工作流的形态可以先出现在最初的若干款产品里，他们之间独立，小巧且专注，之间的数据通用且可以协作，对于研发而言，成本和风险均可控制。而IDE，功能强大且齐全，开发者需要的功能都具备，但是研发成本高，风险大，周期长。

在日常游戏开发中，在选择工具时,我也一直在坚持『若干款开发工具，他们之间独立，小巧且专注，之间的数据通用且可以协作』这样的原则。例如 地图编辑使用TiledMap， 骨骼动画使用Spriter， 图片打压缩和打包使用自己开发的一个小工具……

可以说，Egret的开发工具是走在正确的路上，所以现在的功能缺失啊、各种小bug什么的都不是事，随着时间的推移，都好说。

但是一个完整的的功能强大和齐全的IDE，是一个躲不开的东西。Unity是也是Egret必须面对的对手。毕竟，早晚都要做，这部分应该是最大的难点，也是Egret和其他基于完全基于代码的引擎的最大差异。

我最担心的是 Egret内部对这个开发工具没什么太大的野心，觉得自己有很多其他优点，IDE上差不多就行了，而不去用Unity的高标准要求自己。
我是希望Egret团队能把重心放在工具这方面，而那个Runtime在我看来，其实是可有可无的东西。

『研发开发工具』这个领域我不是很熟悉，也不说太多了，下面就聊一聊Egret的那个Runtime吧。

---

Egret Runtime， 也许只是看起来很美

Egret 一切基于性能的自信，其实都是源于这个Runtime。
在其他方面，无论是Egret Cocos2D-JS 还是我比较推崇的一些国外的同类HTML5引擎，性能其实都差不多的。

『性能』通常不是引擎所要解决的核心问题，而各个引擎所使用的那些优化相关的东西也都是一些通用的、尽人皆知的东西，不存在什么『独门秘笈』。另外在实际场景中，很多优化方法要么有很大的局限性，不具备普遍价值。比如被过度神话的『脏矩形』优化技术。

Egret Runtime做的事情简单说来，就是把 浏览器内置的那个比较慢的HTML5 Canvas，『替换』成一个更高性能的 OpenGL的画布。
原理跟 PhoneGap-FastCanvas 、CocoonJS 以及 Ejecta 有很多相似的地方。

当在Runtime环境中，运行的逻辑大概是这样：
游戏代码 --> Egret引擎 ---> 通过 Runtime,在一个OpenGL的画布上执行渲染。

而在没有Egret Runtime的情况下，运行的逻辑大概是这样：
游戏代码 --> Egret引擎 ---> 在HTML5 Canvas上执行渲染。

在没有Runtime时，Egret就是一个选择了TS作为中间语言的HTML5引擎，没啥特别的，暂不细说。

而Egret Runtime可以以两种形式存在。

第一种，可以脱离浏览器单独使用，这时候Egret 则变身为『支持TS语言的原生游戏引擎』。它的最直接的竞争对手就是 Cocos2D-JSC 、Unity2D 一类的东西 。此时和这两者比， 它除了用了TS，也没啥特色和优势（相反，由于TS，还带来了些劣势）。这第一种情况我想也不是Egret的主要发力点，只是一个『附加价值』，没什么好说的，重点是第二种。

第二种，内嵌在浏览器里，作为一个浏览器底层的插件。这正是Flash插件以前做的事情。不同之处在于你的代码在没有安装这个Runtime的浏览器里也能运行，只是可能会比较卡而已。

第二种方式看起来比较美妙，但现实往往比较残酷：

1. 在iOS上，这条路走不通
2. 在Android，用户无法给自己喜欢的浏览器『安装』这个Runtime，只能期待浏览器内置。
3. Egret Runtime嵌入浏览器的事情，只能靠Egret官方去和浏览器厂商去谈合作，把自己内嵌到浏览器里。

事实上,Egret也确实在 to Business（用2B怕引起误会…）的路上不断的努力着。

• 由于使用了TypeScript，Egret自然成为了微软的战略合作伙伴。
• 他们还与腾讯合作，让Runtime成为腾讯X5浏览器引擎的一部分，这样Android版本的微信、手机QQ、QQ浏览器都会内置Runtime。
• 他们也与小米合作，让小米手机、平板、智能家电的Android系统里的自带浏览器和系统WebView都内置Runtime。
• 由于有了腾讯和小米作为案例，很多小的浏览器厂商以及未来想在HTML5游戏领域布局的App（它们通常是内置个WebView来跑HTML5游戏）也开始主动联系Egret。

Egret的这些努力没什么不对，一个只关注『如何让引擎技术上牛逼，而忽视市场』的引擎厂商是很难生存的。但是这里面也存在着很多的隐患和不确定性：

1. 这些都和iOS没什么关系。
2. 这些合作大多在进行中，未来如何还不确定，风险也未知。举个例子，目前腾讯X5引擎自己的问题都一堆，这时候再加一个Egret进来，会进一步提升引擎自身的不稳定性。未来出了问题，排查起来不轻松。
3. 对于那些主动找Egret合作的中小浏览器以及App而言， Egret对他们的支持力度，以及这些App自身的研发能力都会直接影响到最后的效果。
4. Egret无法敲开真正的浏览器的大门。例如Chrome 和 很多一线厂商的内置浏览器。
5. 类似的事情，在Egret之前也有人尝试过，失败了。 UC 和 欧朋都试过。
6. 使用Egret的开发者要考虑有Egret Runtime 和没有Egret Runtime的两种情况。或者按最差的情况（没有Runtime）来设计自己的游戏，那么此时Runtime的价值自然被大大削弱。
7. 最最重要的： Egret Runtime重点解决的问题是性能，而在未来WebGL在移动端普及之后（这天不远了，iOS 8已经支持，新的Chrome也支持），性能不再是问题，Egret Runtime的价值会被大大削弱。

也许有人会说，WebGL 在移动端的普及还要很久，但是再久也会比ES6的普及来得早，再久也会比Egret成熟的时间要早。（Egret的版本号虽然挺大，到1.x了，但是让我来评价的话，应该还在0.3x的阶段，离一个出色的游戏引擎距离还很远，因为如前所述，我觉得IDE很重要）。

另外，虽然我认可Egret在市场上的努力， 但是最近发生的一些事，让我产生了一些逆反心理。我觉得Egret的本质仍然是技术产品，所以我更希望它能优先考虑从技术和游戏引擎的本职工作上征服我，而不是先在市场营销上取得成功，然后利用市场绑架我（这种事情确实已经发生了）。当然，这些也许是我的技术情结在作祟，对于那些觉得『开发游戏就是赚钱，其他都是扯淡』的人而言，我真的是在扯淡。

---

对 Egret 的一些建议

说了这么多，表达了很多对Egret的不满，和对7yue老师的不敬，但是我必须要说，HTML5游戏领域需要Egret这样的团队，至少他们做了一件很了不起的事情：把HTML5游戏这个领域再次炒的火热起来，而且不是没有营养的虚假炒作，而是真刀真枪的实干。

所以，虽然我前面说了，我写这篇文章不是『为了Egret好』，但我还是『希望Egret好』。
最后提几个充满了我个人喜好，但是可能别人完全不认可的建议吧：

1. 推出纯 JavaScript 版本，如果真的对ES5不满，就搞ES6的。
2. 重点发力开发工具。
3. 那个Runtime只是暂时的权宜之计，别投入太多感情。
4. Egret是一个游戏引擎，一个HTML5/JS游戏引擎，请不要搞成另一个『Flash』。
5. 请先用产品征服我，而不要用市场绑架我。

也许有人会用7yue老师 文章中那最后的几句鸡汤来反驳我，说我的观点是『基于现在去假设未来』,或者说我『没本事创造未来，就知道瞎预测未来』…… 对此，我只想说：这么有人文情话的话题，还是等我们60岁以后（如果我能活到那时候）再来讨论吧。

最后，总结一下我这篇文章，其实就是几个不满：

• 对Egret用TypeScript的不满
• 对Egret中处处流露出的以Flash为重的不满
• 对Egret Runtime的过渡宣传不满
• 对用Egret绑架我的人不满(其实这个和Egret没有直接关系,只能说他们的市场营销和对非技术人员的洗脑很成功)

也许这种在不满情绪的驱使下所写出的文章，都是满满的负能量，毫无实际价值，但是它至少让我『输出个人价值观』的欲望得到了充分的满足，所以，感谢每一位读了它的朋友。

谢谢。

---

[lyDASHsBOK]

干货很多
解答了我对于E的不少疑惑，受教了。感谢。

[devilium]

胖总说得好。其实触乐转 Egret 我一直觉得挺不合适的。媒体要做的应该是从第三方角度的审视，而不是把自述优势的第一方文章扔出来留着读者自己判断去。

[nie-xin]

小胖哥能否抽空出一篇你看好的几个引擎的点评比较？这样会给我这样的菜鸟一些更清晰的方向。

[imzc]

• TypeScript的路线图 generator正在支持中，使用TS一年多感觉很靠谱。ES6遥遥无期的样子
• Egret是支持WebGL渲染的，只是浏览器支持少，默认不使用
• Egret的API其实跟Html的API也很像，前端也容易上手
• 小胖其实是想大家用原生API这样学起来可能更深入

[06wj]

对他们引擎不感冒。。他们的工具texture merger和dragonbones一直在用

[ghost]

“『性能』通常不是引擎所要解决的核心问题” ， 尤赞！

[twinsant]

技术分析客观。

[zerlot]

小胖这篇文章写的不错，就你的几个建议，我觉的还是很中肯的回答一下。
推出纯 JavaScript 版本，如果真的对ES5不满，就搞ES6的。（这个可以搞起，其实成本也不大）
重点发力开发工具。（这个Egret团队百分百赞同，必须发力，光从15年我们计划工具团队增至40个优秀的工具开发工程师就可以了解我的决心了）
那个Runtime只是暂时的权宜之计，别投入太多感情。（目前这个runtime是着重解决碎片化，适配，原生驱动及硬件直接调用的一个加速组件库，它可能未来2年都有很大机会，至于再远的未来，就要看Web技术在这些系统上的进化程度了）
Egret是一个游戏引擎，一个HTML5/JS游戏引擎，请不要搞成另一个『Flash』。（我也开始着手弱化Flash的思维了，因为Flash的开发者群体在向移动web游戏过渡中窗口期就这2年，过去了，也就不存在这个群体了，而且Egret归根结底也是JS的，不是Flash，但是如果可以像Flash一样做到那么成熟的一套产品体系，也算是一大成就了。）
请先用产品征服我，而不要用市场绑架我。（这个我不知道该如何说，我心中也希望用产品征服所有人，但是市场上永远不可能期望所有人都喜欢我们的产品，方案和设计。至于市场方面，我们希望是用市场影响更多人，而非绑架谁，因为在技术市场上，对于一个开发者而言，他们要做决策的成本太低了，喜欢就是yes，不喜欢就可以说No，还谈不到绑架的层面上）

工作太忙了，恕回复简短。
祝顺利，
7yue

[flashlizi]

• 对TS也无爱。
• 不知道真正的前端或者js社区有多少喜欢Egret的？但确实我在一些Flash社区里看到很多没用过的人说Egret不错。。
• 其实，我真想知道国内H5游戏开发者的背景都是些什么情况？不知道小胖有没有这种统计。从我接触的有限环境来看，貌似以前是干多年前端js的H5游戏开发者不多，反而是以前有Flash、java等其他开发经验的人更多些。而他们的引擎开发者也以Flash居多，从自己熟悉的东西出发更有把握，也无可厚非，可以理解。
• 至于模仿Flash，好的东西可以学习借鉴，相似的API也能拉近开发者。只要不把坏的也一并借鉴了就行。
• Egret不仅仅是个H5游戏引擎，而是个商业产品，需要包装营销。现在能做到这样的影响力，无论如何，都是值得肯定的。

[yisibl]

写的非常中肯，但是难免会伤害一些人的「玻璃心」。

看完默默悼念：还是 Flash 大法好！

[shawn0326]

读完小胖的吐槽和7yue的回复，默默点赞

[nshen]

那个Runtime只是暂时的权宜之计，别投入太多感情。 7yue哥~

[jareguo]

完全赞同

[tcper]

楼主真是可以堪称程序员里的作家，码字能力真的很强！

• TS的讨论。
  • 7yue认为TS像ES6，其实微软推出TS的目的并非提前实现ES6，而是更高级更抽象的语言是大势所趋，就比如苹果的swift也是这个思路，语言本身也是生产力工具。当然大可以一直继续写JS，没人拦你，但必须承认高级语言和新特性能够释放生产力。而且用TS这么多高级属性，最后只需要最后加一部编译成JS就可以运行了，何乐而不为？
• Flash API的好坏。
  • 我个人觉得之所以Flash API，不仅仅在于对flash的偏执，而是flash api的显示对象管理就是好，就是比canvas, openGL先进。看看那些用openGL的代码，哪个不是自己封装一堆一堆乱七八糟奇怪的对象？自己另辟蹊径就能比flash API好？我不相信。
• Runtime
  • runtime可以作为webview的补充存在，当你的代码可以在webview里跑，又可以包成一个接近native性能的版本，何乐而不为？

当然egret的最终的发展还是要靠产品说话，没有牛逼的产品就是牛皮吹上天也没用。

[wcsdn]

始终认可敢于做事的人，这是一种担当，也是一种精神。。。
期待你化蛹成蝶时被人奉为的美丽。。。

[vinjn]

说得非常好

[jokerlee]

同意小胖的观点，Egret针对Flash开发者的营销我觉得对于很多开发者是有反作用的。

• 现在很多html5游戏的开发者根本没有flash的经验，二是从web前端开发过来的。typescript对于他们来说反而增加上手门槛。
• 从技术上说TypeScript或者CoffeeScript这种通过预编译转成JavaScript的语言，带来的一个最大问题就是没法在浏览器里直接调试了，而Webstrom的调试器比起Chrome的Developer Tools实在是差太多

[fireyang]

Flash API 可能是对原来as的开发者友好吧，毕竟as阵营的人还是挺多的

[jwu]

小胖说的很在理, 顶一下.

[Wu-Hao]

顶一下

我觉得ts就像是一颗很甜的糖，当你尝了它，你会爱上它，看上去完全没害处，但是你可能没发觉，吃糖会引起糖尿病。

##“ts不是最好的”

没错，大家可以看一下http://githut.info
你可以看到

• js是最流行的语言
• ts只有coffee的17%活跃度
• ts在2014年活跃度一直下滑（相比年初下滑29%），coffee从来没下滑过

那些还在觉得ts会火的人，小心“糖尿病”

##为什么开源引擎不适合用ts

• 有人不喜欢微软
• 有人喜欢动态类型
• 有人觉得“又多了个东西要学”
• 有人喜欢ts的竞争对手（比如coffee）
• 有人不喜欢用小众技术
• 有人不喜欢js transformer
• 一大堆ts vs js的无用讨论（好比说这个issue）

##为什么不要学ts

• 底层还是js，你还是要会js才能debug
• 并不解决js的问题
  • prototyping 继承怎么不好了？
  • 动态类型怎么不好了？

之前有人说了句话，我觉得说的很对，
“不要把特斯拉变成爱迪生”

[Jimmysh]

文章的一些建议还是很不错的.
对于 Egret 我是非常喜欢, 因为我喜欢 AS3. 但是没有正统的学过 JS, Egret 给我带来的就是无比的方便.
所以小胖说的友好度我非常认可

个人建议
想搞 html 游戏开发, 用 Egret, Cocoa2D... 等等, 喜欢那个, 那个觉得顺手就用那个,但这些都不是关键!
最重要的是公司小伙伴们都用它, 团体的力量才是最大, 它可以帮助你们减少合作成本. 纯 JS 就比较难做到这点

我知道小胖不爱用这些, 喜欢纯 JS , 这种事情么 就是 "谁用谁知道" 是坑不是坑, 葡萄是甜是酸,只有用过的人才能体会, 用的好的人才真正理解

一个好的程序员从来不怕掌握几种语言(框架), 因为程序实现万变不离其宗! 不要害怕学习新东西~
一个程序员的真正价值是他的程序思路,逻辑,算法这些脑力值~ 其他的实现方面都一样,手熟而已! 快慢而已! 喜好而已!

[zenany]

赞对 egret 抽丝剥茧、直至核心的剖析。
不懂游戏开发，但认可这几个建议：推出纯 JavaScript 版本、Runtime只是暂时的权宜之计、重点发力开发工具。
任何一个产品都需要去思考自身的定位，搞清楚自己究竟帮助那些人解决了什么问题还是很重要的，不同的服务对象，会导致不同的最终形态和实施路径。

[zhaijialong]

@Wuhao, 吃糖和糖尿病貌似没有关系...

[ustbhuangyi]

作为一个web前端工程师，确实很讨厌ts，之前满怀期待的学习过egret，发现用起来很别扭，于是投入了cocos2djs的怀抱了。

[imokya]

1.没觉得ts方便,反而是诸多束缚.
2.借鉴flash API没什么不好.

[zzm2q]

就一点不太赞同，其他都说得很赞：
ts编译成js, 函数、类、变量也没什么变化，你想用js的方式来，那直接用编译好的js不就行了吗？

[zerlot]

@sqz929，中肯的意见我可以听。但是你说把cocosjs改成ts版再加一些as3的api，就是egret，我觉的错的离谱。如果你不同意，你可以举出egret设计时候先照着cocosjs改，然后再改成as3的例子出来。我真的想不明白如果egret要照着as3做api设计，为何中间要经停一下cocosjs，难道cocosjs跟as3很像么？至于你是出于什么目的在github上这么借题发挥，那是你的想法了，只是这么评价实在很没依据，也很low，不仅抹黑了egret，也抹黑了cocosjs。github是开发者聚集的地方，我回答你的目的是不要让初学者看了你的评论后误人子弟。

[lava-hammer]

作为使用引擎的人，我觉得像Flash也好，像HTML5也好根本不重要。对于商业项目选择引擎，我觉得考虑的主要是2点：
1）可能性：比如老板要开发html5转Native的游戏，那不支持这个特性的引擎，再优秀我也不能选。这是第一位的，其中包括Native可能要集成一堆SDK，引擎要支持我们可以自由导出API到脚本层。
2）易用性：有了可能性，之后就是效率问题，哪个引擎工作效率高。这可以拆分成引擎架构设计问题，工具集问题等。这个到底怎么做，我不是做引擎的，不做评价。但是最终目标是提高开发效率，减少开发者乱折腾的时间。
至于框架像什么，走什么路线，我觉得更想是个哲学问题。普罗大众不太关心，好用就行。
对于Egret，目前试用了一点，感觉还不错。我之前做过cocos2d，没做过Flash。主要的困扰是：
1）引擎功能还比较薄弱，很多游戏功能还不支持，比如Bitmap颜色叠加，以及一些原来可以通过shader做的特效。
2）TS2JS的问题是我开发的时候是TS，debug的时候是JS（在chrome里）。代码不能完全对应。虽然现在我基本能看懂，但是我不清楚某些地方TS会不会翻译的比较晦涩。

最后我觉得一个好引擎一定要有好的文档。这点Egret做的还行，但是还有待进步。而反观cocos2d-x则一塌糊涂。本来上个项目是cocos2d-x的，这个项目也顺接下来的，但是进到3.x之后cocos2d-x的开发给人感觉非常混乱，最新出了cocos引擎一堆问题，文档缺失（和过期）严重，让人提不起兴趣。

[VisualSJ]

@joshuastray
好像还是能扯上点关系的，糖吃多了会胖，胖了容易引起糖尿病~~

[sea-sea]

把看似复杂专业的问题说清晰说明了真是素养文科生飘过

[skcary]

mark

[libins]

最近才上手关注和学习Egret，egret借鉴的是flash中好的一面吧，只是工具方面，感觉还不是太成熟，好在帮助文档比较全和细，加油吧egret!

[saintw]

不能认同更多啊

[dustturtle]

这文笔，不谈了

[yangfan1122]

@tcper
我个人觉得之所以Flash API，不仅仅在于对flash的偏执，而是flash api的显示对象管理就是好，就是比canvas, openGL先进。看看那些用openGL的代码，哪个不是自己封装一堆一堆乱七八糟奇怪的对象？自己另辟蹊径就能比flash API好？我不相信。

超同意这点

[buhichan]

Typescript有类型检查就是模仿FLASH
FLASH是乐色所以TS就是乐色
不应该是这个逻辑吧

[neciszhang]

胖总可以的，很有素养！赞