回复内容：
-----------------------------2015年3月27日更新-----------------------------2015年3月25日，Google做出了一个针对Dart的重大决定，原文在Dart News & Updates: Dart for the Entire Web
总结这篇文章，有几个要点：
Dart is now officially only a Coffescript alternative. Today, with this official announcement, the great dream of Dart as a "javascript.next" has been abandoned by the Dart team. Dart will never be integrated in Chrome. It will run only if transpiled to javascript with the dart2js compiler.
Dart已经正式成为Coffeescript的备选；
原本Dart team想把Dart语言变为"javascript.next"的伟大梦想基本被放弃；
Dart将不会整合进入Chrome；
Dart将只会专注于Dart to JS的编译器工作；
片外话，Google和微软决定合作在AngularJS上使用TypeScript。原文在Microsoft & Google developer connection on TypeScript Angular 2
看到上述这些，只能说去年我们将Egret Engine选定在TypeScript上实属幸运之举。
---------------------------------------------------------------------------------
本来一直都在知乎潜水，但是看到楼上各位华山论剑点到了Egret，而且各持己见。我觉得我作为操盘Egret产品和技术的人，总归要回复几句，但是在诸位看官进入正文前，我先澄清一下，我的回复不会就以下几个问题展开讨论（为什么不讨论，相信各位资深看官都懂）：
1. HTML5有没有未来
2.开源好还是闭源好
3.Web，Hybrid和Native哪家好
4.2D没3D牛B
我想单就Egret本身而言，给出我关于以下几个问题的想法。
1. Egret为何用TypeScript？为何不用Dart,AtScript或者其他？
TypeScript（TS）是一个严格意义上JavaScript超集，而且它目前的1.4版本的语言设计更接近于ES6，如果只是单纯认为TypeScript是微软出的一个开源语言的，请认真去http://TypeScriptLang.org深入了解一下这个开源项目，了解以下微软的首席架构师为何会针对JavaScript做了这么个玩意。
那么为何Egret会选用TS呢？
首先，我们认为Dart的形式针对很多会使用JS或AS3的开发者而言（尤其是初学者这个最大的群体），学习的成本曲线较陡，而谷歌又是一个在技术上“太过”创新的公司，跟随一个有可能“朝令夕改”的技术去制作一款产品，而且将整个Egret的工具和服务的体系都悬于它之上，实在有些让我坐卧难寝。谷歌的AtScript的目标又过于宏大，瞄准了ES7，但是就目前的H5的技术推进而言，下一个JS的标准是看齐ES6。我们想做一款创新好用的产品，但是首先我考虑的是先要创作一个能用的产品。回到TS，它目前版本是1.4，即将在2015出现2.0，语言的结构设计无限趋近与ES6的标准，有了module，有了Proxy，还会有很多更类似于ActionScript3.0的语法。微软还提供了一个TS的编译器，可以在编译时为开发者提供很多帮助，而且我相信以微软的实力，做个编译器的水平还是很高的。目前的JavaScript恰恰有很多设计层面和开发层面的缺陷，TS都能或多或少的弥补这些问题。选用TS这个开源项目，能再现阶段很好的帮助JS开发者创作更有规模，更成熟，更有质量的游戏项目。
其次，我们可以用TS基于Canvas来封装跟Flash ActionScript3.0的API结构设计，而且，我们仅仅封装对于游戏有帮助的部分。我在Adobe的10多年，全部铺在了Flash产品和技术上，Flash是个庞然大物，当初Flash团队之所以放弃AS3到AS4，AVM2到AVM3的项目，很大程度上是Core的部分太复杂了，经历了几代架构师和开发的调整，升级重构的成本已经无法估量，简单来说，就是当时没人改的了，所以，我们也不可能投入研发去自己做一个complier或者virtual machine去让AS3交叉编译为JS，君不见Adobe曾经宣布的AS3到JS的Falcon交叉编译项目，3年了都没动静，最后随同Flex一起捐给了Apache基金会么。Egret的API设计只是借鉴模仿了Flash AS3里跟游戏有关的API部分，做了减法，因为Egret Engine的定位不是想让开发者拿去既可以做广告，又可以做minisite，又可以做Video，又可以做游戏。我们只想在core上保持精简，如果开发者对不同的游戏类型有需求，比如状态机，物理，粒子等等，都做到了core之外的game library里。我2014年初离开Adobe时候，中国还有接近30万的Flash开发者，其中90%是游戏相关，这是一个宝贵的开发者社区群体，他们对于Web页游的开发和理解远远超过了任何使用其他web前端技术做网页游戏的群体。Egret使用TS，一方面是为了让JS游戏开发人员更舒服些，另一方面是考虑到Flash AS3这个开发群体，不争取的话，慢慢都流失掉了，很可惜。下图是我们Egret Engine在API设计上与Flash AS3 API上的对比。
第三，我们使用TS，还有一个想法。将来的JS也是迟早会跟ES6看齐的，等将来所有浏览器都统一支持下一代JS的时候，现在使用Egret的开发者都已经熟悉了ES6那套做法，而Egret几乎可以0成本的直接将TS换为下一代JS的代码，平滑过渡所有开发者，比JS现有体系过渡到下一代的体系成本都低，更顺滑，何乐而不为？
2.我们2014年一口气做了一堆工具，而没有一上来就做个集成的开发环境呢？
我在这里要回答的有2点。在技术和产品的进化上，第一条真理是：天下武功，唯快不破。第二条是，长鞭理论无处不在。第三条是：工作流是工作效率提升的根本。以上三条重要性依次降低，当一个CTO和CIO做了产品形态和研发的决策时，请倒推。好了，不讲大道理，说一说Egret的做法，Egret里我带的这帮人以前是做Flash Pro，Flash Builder，Flex GUI和众多工具及框架的技术，很有经验。但是经验不能完全当做生产力，经验不能当饭吃。经验告诉我们的是，要想在市场立足，在最短时间内做出来的产品的“核”也就是中心思想很重要，它不必拘泥于是否先要有个IDE来承载这种形态，市场需要的是最有效率的工作流，其次才是一招打遍天下的IDE集成开发环境，工作流的形态可以先出现在最初的若干款产品里，他们之间独立，小巧且专注，之间的数据通用且可以协作，对于研发而言，成本和风险均可控制。而IDE，功能强大且齐全，开发者需要的功能都具备，但是研发成本高，风险大，周期长。按照Egret Engine的双周迭代速度，团队潜心于一上来就要打造一个IDE的节奏是不对的。就好像你希望快走，但是又总有一条腿迈不出去的情况一样，这个节奏的结果就是容易扯着蛋。但是2015年，我们也会做出一个第一版的IDE，叫Egret Builder。
（2015年1月26日小更新：Egret IDE形态将在Egret Wing这款可视化GUI编辑器上升级，也就是第一版Egret Wing是GUI编辑器，第二版将是全功能IDE，开发H5游戏的环境将和使用Flash Builder开发Flash项目一样）
3.说了引擎和工具，Egret你们想怎么商业化呢？
商业化的问题其实在这里我不想说太多，我只想说，我们除了引擎，工具，我还让团队做了个运行时。也就是将来Egret的技术体系就是三位一体，Engine，Tools，Runtime。关于Runtime的细节，我也不想多谈，大家可以去http://egret-labs.org上看看Egret Runtime的产品介绍页，就明白我们为啥要针对H5做个Runtime。很多明眼人一看就会说，这不就是个Flash Player么？！答案是Yes，也是No。
Yes的部分是我们的团队原来都是做Flash的，受Flash影响颇深。Flash Player里具备很多优秀的Web游戏设计思想都是很赞的，我们就想我们可以用C/C++和OpenGL围绕着这些设计思想，再做一个取代webview的游戏加速器，让开发者基于Egret引擎开发的H5游戏，可以直接通过这个Runtime加速。No的部分是Flash Player是to C的，要让用户去装，而Egret Runtime是to B的，集成到平台app里，作为一个库，当用户在平台里玩游戏时候激活，玩家是不知道Egret Runtime存在的，我们也不打算对玩家去刷什么存在感。Egret Runtime是为了解决H5游戏性能，适配，系统底层调用和碎片化的问题而生的一个产品。在Egret Runtime上，我们跟各大平台的合作关系也很融洽，为什么？因为我们就是他们平台内部的一个组件，生命周期受平台app的控管，你激活我，我就干活，你移除了我，我就进入sleep模式，丝毫不影响人家平台业务，还能提高H5游戏的用户体验，也不骚扰用户，何乐而不为？尤其在Android上，一个activity级别的控件是让平台恐惧的，而一个view模式下的控件，平台是喜欢的。下图是Egret Runtime的HighLevel架构图：
看了这张架构图，我想诸位看官应该知道商业机会在哪里了。看了这张架构图，我想诸位看官应该知道商业机会在哪里了。4.Egret现在就是个2D的，木有竞争力啊！
近一年内，Egret Engine的确是2D的，但是大伙不都是以进步的眼光看待事物么？Egret也一样，秉着天下武功，唯快不破的思路，我们规划了一下2015年的Egret Next，我们也在预研3D的部分，code name是HummingBird（请原谅我们团队就是喜欢鸟），更细节一点的计划图在这里：
当然，我们现在已经开始做了一些了，不然我也不敢说出来找虐。当然，我们现在已经开始做了一些了，不然我也不敢说出来找虐。（2015年1月26日小更新：Egret 3D第一版预研Demo视频，10万个Triangle级别，物理系统，可破坏的mesh，光效阴影，原生多点触摸及虚拟摇杆，可H5，原生，Runtime全支持，H5为WebGL，Runtime和原生为OpenGL es或DirectX(Windows移动平台））
5.说了半天，你们的套路到底是啥？
来看这张图，我们想为H5或者叫做使用H5(JS/TS)技术的web游戏开发者打造这么一套环境：
（当然，随着时间推移，这图里面的每个环节可能都会过期）（当然，随着时间推移，这图里面的每个环节可能都会过期）所以，说H5移动游戏也好，说Web移动游戏也好，说用脚本开发native也好，工作流齐全了，这些还算是问题么？
好了，头一次在知乎写了这么多东西，希望对各位有所帮助，各位要吐槽的话，请扔鸡蛋，别扔板砖。
我自己作为Egret的技术管理人，在我10多年的职业生涯里，信奉这么几句话：
1. 永远不要基于现在去假设未来。
2. 永远不要尝试用一个成功打败另一个成功。
3. 预测未来的最好方式就是创造未来。
4. 就是干！
谢谢各位，
7yue
接着潜水去了。 我来匿名吐槽一下 。怎么感觉楼主和上边的回答都把Egret引擎前景和html5游戏开发前景绑定了呢？？？
由于html5游戏出现已经不是一年两年了，国外早已有数不清的比较成熟html5游戏引擎了，而且都发展多年，拿出来几乎各个都比现阶段的egret强，我随便列几个
2d方面：
- Parser.js
- Panda.js
- kiwi.js
- flixeljs
- Babylon.js
- Three.js
其他google一下还能搜到一堆html5游戏引擎，比如jawsjs impactjs craftyjs ....
而Egret现阶段只是模仿flash的架构，而flash架构本身就不是一个游戏引擎架构，只是一个渲染引擎，而纯渲染引擎在国外也有更成熟的pixi.js，webgl canvas都支持。框架上egret更单薄，说白了也就是个对canvas的包装，比如针对低效率设备游戏最常用的tilemap都没有，只是整合了几个现有的开源件，比如龙骨p2.js，他们首要目标好像也不是增加开源引擎的功能，而是对周边工具的闭源投入非常多，连visual studio插件都做了，这是其他引擎在这个阶段时所没有的。
那问题来了，为什么刚刚起步的Egret会受到这么大的关注呢？ 以至于楼主以为html5游戏前景和egret游戏呢？
走中国特色的html5游戏引擎路线，优先中国开发者市场，学习cocos2dx先进经验。想在html5上再火一把。
与前边提到的闷声做技术的引擎不同，Egret 有钱！
你是怎么知道Egret的？是在github上吗？不是。他们不是在github上有名而让其他人知道的，他们走的是在其他渠道推广，求网友到github加star的路线
他们每发布一个版本都会发统一的公关文到各大站点。一个神经猫+egret传奇的软文，你知道得花多少钱推广才能人人都知道吗？现在已经html5梦工厂的田爱娜也被挖了过去，基本上以后国内的任何html5开发者大会，你都会看到egret的宣传讲座了。
当然egret也有优势，他们更了解的中国开发者，中国开发者不会在乎各种闭源工具是怎么回事，构建工具为啥要自己写而不基于grunt.js或gulp.js，他们需要的是你能一键发布，然后就适配各种小米锤子手机了。 以下仅代表个人观点。
## 先为 Egret，也为 html5 游戏引擎洗地：
Egret最大的风险在于：技术上没有被市场证明成功过。
Egret 在小游戏上已有大量成功案例，小游戏是 Egret 目前的主打，这一块的技术风险其实不大。至于大型项目，抛开技术，Egret 暂时确实不够成熟，还轮不到技术评估。
它不安于做HTML5游戏，试图通过TypeScript，来入侵手机游戏市场。
手游就不能是H5了么……
反观Egret，技术路线上一是严重依赖其他技术……
TypeScript是开源的，而且 Egret 随时都可以弃用 TypeScript，直接使用 JavaScript
而且他现在还仅仅是一个2D引擎。真正想要吸引开发者的注意力，那么它必须是一款3D引擎。否则就只能在各类小游戏或者独立游戏圈里面生存下去。
cocos2d-x 不解释
Egret的开源模式也是很有问题的
目前开源社区的力量可以忽略
所以我更建议Egret走闭源发展模式
cocos2d-x 不解释
html5本身就是为了网页小效果、在线小游戏而存在的，也是它擅长的领域，搬到其它领域就没优势了。即便一段时间后也不适合做大项目。
不敢苟同，参考 还要多少年, 前端开发才能像客户端开发那样轻松？
它是一款游戏引擎。游戏引擎功能可以简单，但速度上必须要快。
桌面上，Flash都能胜任各大MMORPG页游了，H5自然不在话下，只是开发工具是否好用的问题，这正是我等引擎开发团队追求的目标。
手机上，H5确实有弱势，但：1. 不是所有游戏都需要吃光硬件 2. 不是所有游戏都是重度游戏 3. 就连苹果的新机发布间隔也缩短到半年了 4. 别忘了摩尔定律（想想3年前，想想3年后）
此外，似乎被人遗忘的是，H5强大的跨平台能力（别局限于手持设备），以及热更新能力。
## 我认为目前的 Egret 还有一些问题：
- TypeScript 减轻了 JavaScript 大规模开发的困难，但语言受众仍然太小。Egret 选择它虽然戳中了前 Flash 开发人员的痛点，但 TypeScript 只有依托于 Visual Studio 才能体现出优势，这对跑不动 Windows 虚拟机和不屑用 IDE 的开发者吸引力不足。
- Egret 的工具链都比较分散，有点小米加步枪的感觉，缺乏一个所见即所玩的开发环境，整体体验和它所效仿的 Flash 差距明显。
- Egret 就像是 web 版的 cocos2d-x，缺乏强力的商业模式。
html5游戏前景会很好，但永远不会成为游戏市场中的主流。
上面太多长篇大论的，但都回避了一个事实：
主流的游戏，一定会榨取光硬件系统的资源。
无论PC还是移动平台，都符合这个规律
而且硬件本身一旦进步，游戏程序第一时间就跟进了。
有用FLASH游戏来反驳的。但没有考虑到页游爆发的大环境（当时国内主机市场小众，手游还没起来）。
但本质问题是什么呢，浏览器框架的游戏，性能上永远低于同硬件条件下的原生游戏。在同样条件下，用户永远会选择性能更好的产品。
那为什么说前景很好呢?因为html5游戏很适合作为商业品牌在移动互联网上传播。类似神经猫那样的小游戏，已经逐渐出现在各大企业的传播渠道上。这是一个大趋势，但这不是我们熟悉的，主流的游戏产品。 html5 做游戏最大的风险不在于技术，而在于技术以外的几个问题：
1. 移动平台上浏览器的用户使用时间比例从几年前的40%掉到了现在的14% 还在不断的掉。
APP的使用体验无论如何是远高于浏览器的，即使浏览器里用html5
2. 页游的衰退率居高不下的一个重要原因是在桌面上没有入口，一个桌面上没入口的游戏怎么能够跟有入口的游戏比回访呢
3.做这样一个假设，在APP例如微博客户端里面嵌html5游戏，甚至把微博打造成最大的游戏平台，所有小伙伴们不去APPstore 提交Native游戏，而是去微博上提交html5游戏,你看苹果封杀不封杀微博客户端。
综上所述，html5在移动上成为主力游戏开发平台的机会已经一去不复返了，只能做早期flash做的一些小游戏，互动广告，用它来开发严肃的商业游戏是自寻死路 在程序员的世界是这么理解的：
if(条件不满足){
这个事儿不靠谱;
return false;
}
但是商业公司却是这样的理解的：
do{
想办法去满足条件。
}while(条件不满足);
赚钱();
不管你列出多少问题，只要这个问题是可以解决的，商业公司都会不遗余力的去做，这个世界总要有一堆做事的人去解决问题吧，难道玩玩嘴炮就能把HTML5玩活？
如果万事俱备了，还能有Egret什么事儿？
这就像最近罗胖说的一个故事一样，关于从欧洲大陆穿越海底铺设一条电缆到美洲大陆用来发电报的那货一样，你们觉得impossible，但是人家Just do it .等你觉得，wow，amazing。人家已经开始数钱了。 11年app,想跨平台用H5做，结果问题非常多，性能内存都极坑，半年的项目最终放弃了，然后游戏考虑过cocos2d-js,后面发现支持非常不成熟，jsb也是一堆坑，然后发现了Lua ..至从有了quick,就再也对h5的东东不感冒了. 好像大多谈h5的都在谈未来,寄希望有一天H5标准统一，厂商支持，硬件提升，用户买单，现在14年底，感觉H5还是没成为主流，未来还要再等, 游戏这个行业等不起的。 2014年12月25日 11:21:18 update: 我这个答案是写给小白看的，内容比较浅显一些，主要回答我对H5游戏开发和Egret Engine 这个游戏引擎的未来的看法。在回答之前不知道 @马鉴 7yue兄也会来回答，不然我就不费事写这么多了o(︶︿︶)o ，更多干货可以看他的答案。
Egret labs合作伙伴飘过(在他们官网首页上列举的合作伙伴中，logo比较特别的那个)。。。
在这里我主要回答两个问题，一个是H5游戏的现状和未来，二是Egret社区的现状和未来，兼点评一下其他人的答案。主观色彩比较浓重，大家随便看看。
一般来说我用专业术语是比较严谨的，但在这里为了讨论方便，我用H5来指代现行的和正在进化着的Web技术，包括CSS3、2D Canvas、Webgl、ECMAScript和它的小伙伴们。
第一个问题，H5游戏有前途吗？
我个人是比较看好H5的前景，尤其是在这个移动互联网的时代，Web技术的触角必然会深入到各个领域，包括题主关心的游戏领域。
当然H5目前仍然存在着不少缺点，包括大家所提到的性能较弱、碎片化问题和JS这门语言自身的缺点等等。但这不能抹杀H5自身的魅力，用户到达成本低，这是H5的杀手级优势。基于这个优势，我认为H5前景必然是广阔的，更别提H5开发还有着开发效率高、部署迭代迅速等优势。
用户到达效率高于一切，这在互联网过去几十年的历史里，已经被反复证实过。假如你将运行效率置于用户到达效率之上，那么自然会产生不一样的观点。
而H5也不是一成不变的，如运行效率、碎片化，和JavaScript自身的坑，这些令人困扰的问题已经在不断改善，Web技术也正在以一日千里的速度进化着。大家不妨回想一下，在IE的时代，在Android WebKit的时代，Web的开发和体验有多么痛苦，但时至今日我们已经有不少优秀的开发框架和app级的web应用，这一切要归功于一代代程序员的不断努力。Web技术更是已经越过了浏览器的边界，正在入侵app的领域，大家可以看一下手机淘宝、手机百度、京东等。
而在移动游戏领域，变化也在悄然发生着，最受欢迎的2d游戏引擎Cosos2d已经支持用JavaScript开发并同时编译成H5和原生app版本，听说Unity也将提供H5支持。
综上，Web技术有着不可替代的优势，而劣势正在逐渐改观，参考互联网几十年的发展历程和近年来Web技术的爆发式发展，我认为H5游戏的前景不可限量。移动app的web化、Hybrid化趋势，两大游戏引擎的动向，也多多少少证明了这个观点。
再说Egret Engine。
Egret labs的小伙伴们是比较有想法的，Egret Engine整个设计与 Adobe Flash 体系一脉相承，在众多H5 游戏和绘画引擎里，Egret是比较成熟而活跃的。再加上它依托于一个商业公司，在技术和商业的推动下，使得 Egret 社区成为国内H5游戏开发社区中最活跃的一个，也捎带着使TypeScript在H5游戏开发领域得到迅速推广。ps其实我对TypeScript颇不满，相对于ActionScript3缺失太多特性，我更希望将AS3直接编译成js这个设计。
为了避免像有些答案那样隔着空气将js和h5的那些陈词滥调翻来覆去地说，在这里我要提一下Egret Engine的设计。
Egret Engine代码以TypeScript写就，编译成js后运行于js 引擎之上，可以驱动多种renderer，目前已经支持2D canvas renderer和 web gl renderer，基于native renderer的支持也基本完成。
捎带提一下，程序代码运行于js引擎，驱动多种renderer，Cocos2d-js和阿里Hilo也采用了相似的设计。
由于核心类源码与renderer剥离得比较彻底，假如Egret labs
愿意的话，完全可以加入flash renderer，或者其他什么的绘图引擎，也可以将TypeScript换成JavaScript、ActionScript3(我希望换成AS3)或其他什么脚本语言，或者编译成其他什么东西，这样整个Egret生态圈都能比较无痛地迁移。
也就是说，虽然我对H5和Egret Engine的未来相当有信心，但假如情况有变的话，Egret 完全可以迁移到其他语言和运行环境里。这样Egret生态圈可以受益于H5的发展，而不会受限于H5、JS，甚至是某一个具体的平台。
当然Egret 目前这个生态圈的缺点也是有的，文档不够完善，工具链和开发环境远远比不上Adobe Flash，甚至跟Unity等相比还有不少差距，游戏引擎本身也还存在一些问题。但好在Egret Labs相当务实，这些问题相信会一步步得到解决。最重要的是，这一套东西已经可以跟上时代的要求。
综上，我们有如下结论：
1. H5方兴未艾，用户到达效率高这个优势无可替代，而运行效率等劣势正在不断改善，市场需求在那里摆着，大家要有这个信心。
2. 即使对H5心有顾虑，Egret Engine也是个相当不错的东西，剥离引擎和renderer的设计、语言转译的便利，使得Egret生态圈不必受制于某种语言或某个运行环境。浏览器不行你还可以用native renderer嘛啊哈哈。
3. 要是能用AS3代替TypeScript就好了，('・ω・')
====
私货很多的答案点评部分
冯冲
一句话，只要w3c和whatwg不同心协力html5成不了主流。
不过就技术而言Egret引擎本身还是不错的，但今后命运什么样不好说，因为它的命运完全被掌握在html5的两大标准组织手中。
点评：2d Canvas或Webgl只是Egret 的某个renderer，而且2d canvas的 api 已经差不多定好了，这么说危言耸听了点吧。
Jare Guo
## 我认为目前的 Egret 还有一些问题：
TypeScript 减轻了 JavaScript 大规模开发的困难，但语言受众仍然太小。Egret 选择它虽然戳中了前 Flash 开发人员的痛点，但 TypeScript 只有依托于 Visual Studio 才能体现出优势，这对跑不动 Windows 虚拟机和不屑用 IDE 的开发者吸引力不足。
Egret 的工具链都比较分散，有点小米加步枪的感觉，缺乏一个所见即所玩的开发环境，整体体验和它所效仿的 Flash 差距明显。
Egret 就像是 web 版的 cocos2d-x，缺乏强力的商业模式。
我不认为这些是致命的，我相信 Egret 想得比我看的长远。
点评：真做过这个的，跟别人打嘴炮的，写出来的答案就是不一样。我基本认同Jare Guo的观点，也推荐他的答案，但TypeScript不一定要用 VS 开发，我们团队都用 WebStorm 体验也很好。
匿名用户
Egret最大的风险在于：技术上没有被市场证明成功过。
点评：答案较长，不多复制了。我认为这个答案是不了解，或者有偏见。
Egret Engine 在引擎和renderer的处理上，原理与Cocos2d-js基本相通，js引擎跑控制流，通过统一的api驱动renderer。
要等市场证明成功再进入，这本身就有些跟不上时代的意思。更何况用脚本语言写的游戏，包括移动游戏，这事并不新鲜，Lua能做到，js为什么做不到呢。 端游换了电脑，还需要下载。页游和电脑无关，打开网页就玩。所以页游可以抢些端游的市场。
而手机呢，下载一次游戏后，手机随身带。想玩就玩，不用打开浏览器，再进游戏。所以移动端的页游和PC端的页游 不是一个概念。
-----------------------------------------------------
2015/6/23更新，6个月后，新的认识：
如果有渠道有入口，H5还是有机会的，但是要把握好H5的特性。
一直在关注市面上的H5游戏，垃圾小游戏确实有一大堆，稍微重度点的多为页游的H5移植版，或者native游戏的H5移植版。对于玩家来说，游戏内容一样，完native和玩H5，差别不大。
现在的手游玩家可以分两拨，一拨是小白玩家，一拨是被手游教育过的玩家。小白玩家，不用说，啥游戏都可以high起来；但是对于被教育过的玩家，就不再满足于消灭星星什么的了。被教育过的玩家的需求是什么呢？（感兴趣的可以看生理学上的韦伯定律，和心理学上的锚点效应）人都喜新厌旧，玩家也一样。第一天吃鱼翅，美味极了。第二天吃也不错。但是天天吃，吃上半年看看。保证以后听到鱼翅就吐！所以对于H5游戏来说，如果没有自己的特点，对于玩家来说也会吐。H5游戏有个自身的特有的属性，那就是社交。一条分享，一个连接，一个二维码就能传播开了。想想《神经猫》就知道这个社交属性的有多厉害。所以最好的切入点，是把社交做强！
话说回来，聊聊引擎。对于我这个码农来说。哪个好用用哪个！关键要把握住技术本质的东西，是种思想。框架+功能=游戏。框架装不同的功能生产不同的游戏。框架我习惯用pureMVC。做页游的结构为：基于flash，pureMVC+插件化改造+mornui。做H5的话，现在基于Egret，pureMVC+插件化改造+egretWing。为什么选Egret，主要是看中其背后的渠道。
最后，如果你错过了页游，如果你错过了native游戏，那么不要错过了H5！
友情提示：垃圾评论一律封号 加我微信：826096331拉你进VIP群学习群