还不知道typescript是啥的前端童鞋需要做下功课了。
接触typescript挺早的。13年底的时候，公司的牛人在团队内推广typescript，没多久我们就把typescript做的项目搞上了生产环境。玩新东西的初期都是很爽的，但没多久就变成了灾难。团队人员更替，培训/学习成本增加；开发工具不统一，效率极其低下；ts带来的利好被消耗的一干二净，只有无尽的坑。种种不顺，最后不得不把所有ts文件删除。
这是一次不好的经历，后面我很长一段时间都没再写过typescript了。但是，15年发生了两件事，让typescript再次回到我的视线。
一是es6规范的落地，二是visual studio code的发布。这两条正好解决了上面提到的两个主要痛点：语言和工具。
随着es6的普及，应该没几个前端童鞋会说自己不会点es6了吧。typescript最初就是基于es6的，箭头函数、模块、类等等，只不过是在es6的基础上加了个强类型（要是会as就更简单了）。放到现在的前端环境，typescript的学习成本已经很低了，比各种前端框架的学习成本都低，可以放心在团队内推广。
再说开发工具。typescript刚出的时候只有vs、vim、webstorm支持，除了微软自家vs系列，其他编辑器对ts的支持仅仅只有语法检测，智能提示、重命名什么的那是妄想。
而visual studio体积太大，轻量级的express也接近1G了，光这一点就能吓跑一拨童鞋了。然而，去年4月底，visual studio code横空出世，没有vs家族的庞大体积，性能又甩出同源的atom几条街，对typescript和javascript的支持相当给力，简直就是为前端童鞋而生的。今年4月中旬，vs code就会发布1.0版本，也就下周的事了。要不为什么说ms大法好？
除了语言和工具，typescript的生态也在不断完善，DefinitelyTyped上有各种主流框架/类库的头文件，满足各种各样的需求；头文件管理工具tsd(已经废弃，新的工具叫typings)也做的越来越好，ts项目管理一个json文件就搞定。
一门语言，有了良好的生态，要火起来那是迟早的事。
好了，说回正题。
react
第一次看到React.propTypes的时候，心想这不就是interface么，typescript+react指日可待啊。果然，typescript从 v1.6开始支持jsx语法。组件的props和state都可以定义interface，类型检测有了，propTypes拜拜。
直接贴代码：
interface Props {
from: string;
message: string;
}
class Greeting extends React.Component<Props,any> {
render () {
const {from,message} = this.props;
return (
<div>
<p>来自{from}的消息</p>
<p>{message}</p>
</div>
)
}
}
配上vs code,到哪都有的智能提示简直不能再爽，贴张gif感受下。
Greeting这个组件有两个prop，from和message，不传这两个prop或者类型搞错，编辑器都会有提示，state也是一样的道理。这tm就是生产力啊！！！
最终编译出来的文件长这个样子,再搭配webpack简直完美。
前一阵子写的web版cnode就是用typescript+react写的。
node
js不是java之类的静态语言，很多错误都只能在运行的时候才发现，而typescript正好弥补了这一点，强类型让很多错误在开发的时候就能被发现。再有人吐槽node不能搞大型应用，typescript+node分分钟打脸。
除了强类型外，用typescript还可以体验node暂时不支持的es6特性，现在有很多童鞋都是直接写再用babel编译，而typescript生来就具备这一能力，在一定程度上取代了babel的作用。
v1.7的typescript已经支持async/await，异步流程控制不再是问题。koa2发布了，对应的koa.d.ts也有人写好了（感谢DavidCai1993童鞋），现在就是typescript+node的最好时机。
直接看图：
代码和用js写没什么两样，通过头文件，可以很清楚地知道变量类型、函数返回值等信息，不用查api，不怕会写错。
那只剩调试的问题了，typescript和babel一样，都可以通过sourcemap来调试，做好配置，和调试js一毛一样。
以koa2为例：
结语
typescript是好东西，大家快搞起！
typescript是好东西，大家快搞起！
typescript是好东西，大家快搞起！
我这一年内，一直在用typescript写node，偶尔用typescript写react，typescript肯定是很好用的。 但实际遇到的同事都会排斥typescript，相当一部分人有微软恐惧症（ irrational Microsoft hate），自己也说不出不含偏见的理由。
问：javascript为什么产生那么多衍生语言？
答：因为javascript很强大，大牛很多。
问：你可能没有明白我的意思，我是问为什么会产生，关键是为什么会？比如这些语言是解决什么痛点的？
答：因为可以避免javascript的一些坑，写起来比较爽。
问：javascript不是很强大么？为什么会有坑？
答：。。。。。
答：玩javascript的高手多，坑不是问题。
问：那为什么产生这么多衍生语言？
死循环。。。
javascript需要的不是各种衍生语言，而是改善语言本身。在语言本身没有改善之前，我个人更倾向于选择语言的子集来工作，而不会去选择衍生语言。
理由：
1.非标准的东西不确定性太多，现在标准都不稳定，何况是这些衍生的东西？跟着标准走肯定好过跟着某个公司，某个人走。
2.团队协调，每个人有自己的风格喜好，这个可以有，但对团队而言，从长远考虑，把标准吃透远比技术依附于某个公司，某个人强。标准是相对透明可控的。非标准的东西，对个人而言没什么影响，一些项目没人接手，死了就死了，并没有多大影响。但对公司而言，人才队伍建设方向是非常重要的，技术路线是跟着标准走还是跟着某个公司或个人，这个道理大家肯定明白的。
3.众口难调，标准为王。有的人自己很喜欢一样东西，会产生很强烈的传教冲动，也希望别人会喜欢，形成小团体，小派别。尤其在编程语言问题上，会产生莫名其妙的信仰问题。某新技术一出来，自己很喜欢，别人却不用，别人就被定义为保守，偏见。解决这个问题就是统一标准，行业标准 > 事实标准 > 团队标准。当团队里大部分人都认可并熟练运用某非标准的技术时，这个技术作为团队标准才可以使用，其他情况尽量选择行业标准，没有行业标准选择事实标准。有的时候别人不用某技术，并不代表就是保守，偏见，别人有解决方案，为什么非要去再学习一个非标准的东西？
微软本身没有问题，有问题的是不透明和控制，而大多数程序员都不愿意有被束缚和控制的感觉，微软已经意识到这个问题，正在做出改变。只要是开源的，成为标准的东西，谁家的不重要，重要的是能解决问题。
你的观点我挺认同的。
我没学过java、c#那些服务端语言，一毕业就是做js开发。我觉得js已经很好了，灵活、容易，连带觉得其他脚本语言都挺好。对javascript为什么产生那么多衍生语言这个问题我认为都是写服务端语言的人转去写js后搞出来的。
一些人不喜欢/不习惯或者说受不了js的语法/写法，索性按照自己的习惯搞一套，所以有了coffee，然而这并没什么卵用，解决不了什么问题。
另一些就是认为js还有很大的提升空间，冲着去改善的，所以引进了一些其他语言的语法、概念，dart、ts就是这种。这对js的发展是好事，最主要的是能提高生产力，能解决问题。
@coordcn 我到觉得说js强大 和 说js有那么多坑 都是对的。。也不矛盾。。。
js 确实是一门 有很多优点 和很多缺点的语言
大公司是制定标准的。。小公司都是跟随标准的。。小公司跟随的标准其实也都是大公司指定出来的。。所谓的标准委员会还不是都是大公司那群人，又有几个能顾忌自己公司的利益。。
强大 = 过渡使用 = 看不明白 = 坑
的确不矛盾，从某种意义上来说，是必然的。就像英雄联盟里的瞎子，这种英雄天生就是拿来秀的，一些强大而灵活的语言也是这样，高手秀起来，漂亮！普通人要么根本玩不溜，要么就秀死了。坑越多的语言，越有区分度，越能分辨水平，高手本身就是坑出来的。javascript语言要应对的问题规模越来越大，要秀，还是要稳，我想首要的应该是稳。ES6里加入一些稳的元素，但由于兼容的原因，秀的成分并没有去除，希望后续版本能继续做得更好。
我个人更喜欢简单的东西，c++与c相比我更喜欢c，javascript与lua相比我更喜欢lua，道理都是相同的，虽然后者没有前者强大，但后者比前者简单。我为什么更喜欢的简单的东西，因为我觉得我脑子不适用于复杂的东西。
标准更多是协作，妥协，基于共同利益，解决共性问题而形成的。只顾自己利益标准就很难建立起来，没有标准各自要做很多重复劳动，各自利益都是受损的。
在团队成员意见一致，技术到位的情况下，选择非标准的技术作为团队技术也是没有问题的。一味的唯标准是有碍创新的，很多标准都是先有好的应用，成为事实标准，最后再成为行业标准的。具体怎么选择归根到底还是团队喜好问题，喜欢，hold得住，一切都不是问题。
@coordcn typescript的独特地方在于： 1、typescript本质上是：ES＋可选的类型 2、对开发工具友好，开发和调试效率高（这个楼主应该有体会） 你可能不知道的是： 1、typescript是ES的超集，如果只需要ES的子集，也可以在typescript里只写这样的子集（例如我，即使ES6里有class，我也尽量不用） 2、typescript本身是开源的（例如我，也贡献过代码），没有不透明和控制 3、typescript是ES的超集，和ES的标准一致
这里是typescript的设计目标（https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals ），里面明确表示： Align with current and future ECMAScript proposals. Preserve runtime behavior of all JavaScript code. Be a cross-platform development tool. Do not cause substantial breaking changes from TypeScript 1.0.
typescript会出现的原因在于：在大项目中，写好js很难，但js在很多方面却有事实上的统治地位，不能不用。 类型系统和工具支持，明显会简化js大项目的开发难度。 即使不用typescript，facebook也推出了类似的类型系统：https://github.com/facebook/flow
不针对谁的说，可能更类似于这样的问题：在你经历的大的js项目中，你是怎么处理大规模代码带来的开发难度的？ 而目前的解决方案无外乎3种： 1、严格的jsDoc，对函数、参数、返回值、类型、结构等等添加注释，并保持代码和注释一致 2、typescript，不需要注释类型 3、flow，也不需要注释类型，但目前开发工具支持度不太好
而从我的开发经历来说，typescript是目前体验最好的一种。
你选择用语言的超集，我选择用语言的子集，目标其实都是一致的，避免语言坑。
这本身就说明了避坑的方法有多种，你也列出了很多种方法。各人的选择本质上是成本和能力的问题，你或许能力强一点，选择了超集，我能力弱一点，选择子集加注释。我上面已经说过了，团队选择非标准的技术，只要大家意见一致，hold得住，是没有问题的。但是，我们不能因为自己喜欢了，自己用得爽，就要求别人也用。就如你所言，别人是有替代的，大家自然会根据自己的能力，喜好选择适合自己的编码方式。
我个人认为lua的设计比javascript好得多，干净得多，可以完全用形式同步代码来编写异步程序，如果我也向你推荐openresty，你不用，我就认为你有偏见，这合适么？你认为最好的，别人未必，这个道理大家应该都懂的。我本来不想回这个帖子的，就是看到你说你同事的问题，我才讲了几句。别人有现成的舒适的解决方案，为什么非要去学习一个非标准的东西？不学就是偏见？这显然不合适。
我并不是说大家不要用typescript，不要用微软的东西，我也不可能不知道这东西是开源的，.net都开源了，这东西会闭源么？而是强调用与不用，要依据团队的能力，技术积累来决定，并不是某个人用了某个技术，觉得好，团队就一定要用，尤其是这种有很多种方案的情况，选择谁，我的观点是标准优先，其次在能力具备的情况下，也可以选择团队能够hold住的非标准技术。
项目规模绝对不是理由，规模越大，道路的选择越要慎重。看看那些招聘帖就会明白，人才，是最贵的，也是最难找的。美食，美人，美景都上了，我要找的人在哪里？
作为长期的潜水员，也来发言下。 @hellopao 首先支持下楼主，对本帖很👍。 @dd1994 明显你被某些人误导了。 @coordcn 看似你说的要尊重个人喜好的意思，但字里行间透入的也是带了不少个人情感的。
我个人认为lua的设计比javascript好得多
对于靠javascript 吃饭的来说， 用lua 和javascript 的比较是不合适的，因为大多数的使用场景lua是无法去做javascript能替代的工作，但typescript 不一样，大部分javascript能做的事情都可以切换到typescript来做的。
对于你的自问自答的笑话； 一个回答，javascript 的强大不在于语言的强大（作为曾经烂透的语言，槽点特别多），而在于生态的强大（已经遍布到各个角落了），nodejs 也是这个道理。 为何有掌握typescript 有必要的愚见，理由如下： 首先javascript 是有缺陷的：
- 缺少类型支持。君不见多少框架重造了多少轮子呀， isNumber, isFunction, isArray, isXXX.
- OO 太弱，翻开javascript的历史，模拟个继承和实例化看着都是幸酸都是泪呀。
- 可读性非常的差，100个人可以有100种的写法风格，javascript 难不在实现功能呀，难的在于看懂人家的代码。
- 对IDE的支持太差，没有一款IDE对javacript能明白理解的，对于强烈依赖IDE和普罗大众的程序猿这个是有多悲催呀，你要查看函数定义，要重构，要查阅API 是多困难呀。
其次为甚么不是ES6呢？ 这里吐槽下标准的问题，从长远意义来说，标准是很重要的，她能达成一些稳定性，和对各个厂商的约束和平衡，比如typscript也是被这个约束的，编译、兼容都离不开。 但问题如下：
- 标准的进度是很慢长的，ES6 仍远远不能满足现代开发的需求，如OO的支持、IDE的支持、代码可读性、异步写法等，ES6还是个过渡方案，且较于typescript 还是较差的方案。
- 标准的自主性是很差的，受制于各个厂家的利益，很多时候无法从语言本身去优选方案（typescript 的进展很快，不少新的优秀语言特性在加入 2.0 的特性是很大的亮点）。
看似你说的要尊重个人喜好的意思，但字里行间透入的也是带了不少个人情感的。
我讲的主要都是团队选择问题，我认为团队选择应以团队能力和团队共识为基础，在没有这些时以标准为基础，我恐怕不是主要表达尊重个人喜好的意思，我恰恰认为不能因为某个人喜欢，某个人用得爽，就去要求其他人也使用。这里的核心问题不是这个东西有多好，而是这个东西是有替代方案的。既然有选择，那选择自己用得舒服得，并与行业标准同步的技术就无可指责，我是针对上面一个朋友所谓的偏见说发帖的。看来牵涉到语言，终究是要触发莫名其妙的信仰。这种信仰自然也会影响人的理解能力，鉴于这种情况，我再次强调下我的观点，我绝对没有表达要大家一定要以标准为准，不要用衍生语言的意思，我要表达的是以团队共识为基础，基于团队原有的技术储备，优先选择已经成为标准的技术方向，说白了，只要团队hold住，自己撸一个语言也无所谓。尊重别人的喜好，这是基本的礼貌，强推是不礼貌的，恐怕这个问题不需要我来说，而且我重点也没说这个东西。
关于lua和javascript的比较，我说的是语言设计，在语言功能类似的情况下，lua设计更加简洁。我并不是说lua要替代javascript，lua连事实标准都只能勉强，怎么可能存在替代问题？
你提到了异步问题，建议你去看下lua是怎么实现异步的。openresty，fibjs都可以看一看，不是要你也用，但学习一下思想总不会错。很多人看到 async/await 就惊呼是异步的终结，我真不希望javascript这么没追求。。。
至于为什么要用，为什么不要用，我已经讲得很清楚了，你的方案再好，也是一家之言，并不是非要用你的方案。我有标准可用，标准存在问题的地方，选标准的子集，形成团队规范，你说的问题不也同样避免了么？建议看看nodejs的lib文件夹里的代码，nodejs库规模算是比较大，比较复杂了，人的解决方案不也挺好？如果有兴趣的话，也可以再看看libuv的源代码，看看c语言怎么抽象的，怎么利用面向对像思想的，面向对像并不是说非要语言层面支持才行，更关键的是思想（这个问题也可以延伸到基于模块的重用（接口重用，API重用），还是基于代码的重用，很显然代码重用是低级的，不稳定的，接口和API才是相对稳定的，从这个意义上说，面向对像里的东西并不是完全正确的，过度使用反而有害）。从ES5到ES6也没见什么类型问题，OO问题，可读性也没差，开发关键还是看人。先把语言的子集玩溜，然后逐步了解一些坑，学会避免，有一定基础再去尝试语言的超集，我想大部分人都是按照这个套路来的，除非个别天才。有的人觉得子集就能胜任大部分工作了，个人能力也有限，就继续用子集，学习成本低还能避部分坑，加上些团队规范就行了。有的人觉得要使用强大的超集，这些人能力要强一些，但请照顾一下使用子集的兄弟，这个选择真不是偏见，就是能力和喜好而已。
@coordcn 关于团队技术选择，恰恰说明了typescript 重要性（当然引入一个新东西，总是有新的成本在的，如果你只是强调这个成本，我无话可说，less,sass 也是同样的问题），typescript 大部分特性都命中javascript项目当前的痛点。 当然最终选不选择这个是团队自己平衡利弊去决定的，我看楼主所说的是目前typescript 的生态已经日趋成熟，可以投入到生产环境了（这个也是我最近尝试重新拾取体会到的，很早前试过坑不少搁置了），这个也是我👍楼主的主要原因。 关于异步，我认同有更好的实现，但目前在平衡各种方案中async/await已经是较优的方案了，至于javascript 是不是只追求到这里，如果你想推进她就去为她贡献代码，而不是在这里牢骚下，如果不，她也不会停止这个前进。
OO问题，可读性也没差，开发关键还是看人。
还是基于代码的重用，很显然代码重用是低级的，不稳定的，接口和API才是相对稳定的，从这个意义上说，面向对像里的东西并不是完全正确的，过度使用反而有害
这么多自我矛盾的话，我也是醉了。
建议好好看看nodejs的代码吧，看看人家的思路，人家代码怎么组织的。人家没用面向对像思想？stream怎么实现的？nodejs代码可读性比你typescript差？
别人的话都没看明白，就醉了。。。真是酒不醉人人自醉啊。真是中了我那句话，碰到语言问题，就会有莫名其妙的信仰，别人说不得不同的声音。我说的是这个东西不是不可替代，人家不用有人家的自由。我没说typescript这不好那不好，一句也没有，我的话并不会伤害typescript半根豪毛。
为了便于你的理解，我把我的话重新贴一遍，同时也善意的提醒下，把别人的话断章取意是非常不礼貌的。
如果有兴趣的话，也可以再看看libuv的源代码，看看c语言怎么抽象的，怎么利用面向对像思想的，面向对像并不是说非要语言层面支持才行，更关键的是思想（这个问题也可以延伸到基于模块的重用（接口重用，API重用），还是基于代码的重用，很显然代码重用是低级的，不稳定的，接口和API才是相对稳定的，从这个意义上说，面向对像里的东西并不是完全正确的，过度使用反而有害）
这句话和那句话有什么矛盾？抽象能力本质上跟语言无关，libuv用c语言不也做了很好的抽象？思想就是面向对像的，nodejs用原生的javascript不也做了很好的抽象。这就是跟人相关的能力，跟语言无关的，某个人抽象能力有问题，并不会因为换了语言就会有改变。错误的抽象，烂用面向对像反而是有害的，我这样的观点你应该是接触过的。基于模块的重用比基于代码的重用更加高级，更加稳定你不太可能反对吧？这些思想跟语言相关么？这只跟能力相关。
为了帮助你理解我的文字，我只好打了一段补丁，否则你可能又要醉了。。。
@vellengs 只有编辑器提示是优点,其他的都是缺点 有类型必然会衍生出接口和泛型 复杂度和代码量必然会膨胀 并不适合浏览器这种宿主环境 另外OO只适合高度抽象的领域 对于业务应用和流程控制来说,OO并不是一个最好的选择,因为实际上码农接受的业务经验都是后验性的,还没有几个码农能预知业务的变化,提前抽象出一堆业务接口,在业务需求变化的时候刚好能用上 就类型而言js有Object和Function这两种类型就完全够用了 js现在要做的只是解决可读性的问题, 就是把实际异步执行的代码 表现成 看起来象同步的样子就行了或者用几个关键字 yield/await/async 在来约定异步的写法规范 OO的可读性也是这么过来的,最早的写代码不是这样写的,用了几个关键字实cclass/public/private 写得人多了,大家都这样写,自然就看懂了
真正的经验之谈，有的人中面向对像毒太深了，面向对像只是解决问题的一个可选方案而已，有的人却把它看成编程的全部了。。。
你提到泛型我就想起了c++，我赶快去写了两段c代码压压惊，特么c里面竟然有个void，特么指针竟然可以随意强制转换的，这可不得了，这跟弱类型的有什么区别？这是要出事情的。类型很重要么？只要我愿意，我想让它是什么类型就是什么类型；类型不重要么？我特么都不知道参数是什么类型，我写什么程序？一些程序员宁愿依赖一些语法糖，也不愿意真真弄清楚自己在干什么？
这样的代码你么怕不怕？就是这样的代码在同一个文件里被复制了四次你们怕不怕？
有的人肯定怕死了，严重反正违反DRY原则。
int luaio_streq_64(const char *s1, const char *s2, size_t n) {
if (n <= LUAIO_SHORT_STRING_LENGTH) {
if (s1 == s2) return 1;
const char *ss1 = s1 + n;
const char *ss2 = s2 + n;
switch (n) {
case 64:
if (*(uint64_t*)(ss1 - 64) != *(uint64_t*)(ss2 - 64)) return 0;
case 56:
if (*(uint64_t*)(ss1 - 56) != *(uint64_t*)(ss2 - 56)) return 0;
case 48:
if (*(uint64_t*)(ss1 - 48) != *(uint64_t*)(ss2 - 48)) return 0;
case 40:
if (*(uint64_t*)(ss1 - 40) != *(uint64_t*)(ss2 - 40)) return 0;
case 32:
if (*(uint64_t*)(ss1 - 32) != *(uint64_t*)(ss2 - 32)) return 0;
case 24:
if (*(uint64_t*)(ss1 - 24) != *(uint64_t*)(ss2 - 24)) return 0;
case 16:
if (*(uint64_t*)(ss1 - 16) != *(uint64_t*)(ss2 - 16)) return 0;
case 8:
if *((uint64_t*)(ss1 - 8) != *(uint64_t*)(ss2 - 8)) return 0;
case 0:
return 1;
case 63:
if (*(uint64_t*)(ss1 - 63) != *(uint64_t*)(ss2 - 63)) return 0;
case 55:
if (*(uint64_t*)(ss1 - 55) != *(uint64_t*)(ss2 - 55)) return 0;
case 47:
if (*(uint64_t*)(ss1 - 47) != *(uint64_t*)(ss2 - 47)) return 0;
case 39:
if (*(uint64_t*)(ss1 - 39) != *(uint64_t*)(ss2 - 39)) return 0;
case 31:
if (*(uint64_t*)(ss1 - 31) != *(uint64_t*)(ss2 - 31)) return 0;
case 23:
if (*(uint64_t*)(ss1 - 23) != *(uint64_t*)(ss2 - 23)) return 0;
case 15:
if (*(uint64_t*)(ss1 - 15) != *(uint64_t*)(ss2 - 15)) return 0;
case 7:
if (*(uint32_t*)(ss1 - 7) != *(uint32_t*)(ss2 - 7)) return 0;
return *(uint32_t*)(ss1 - 4) == *(uint32_t*)(ss2 - 4);
case 62:
if (*(uint64_t*)(ss1 - 62) != *(uint64_t*)(ss2 - 62)) return 0;
case 54:
if (*(uint64_t*)(ss1 - 54) != *(uint64_t*)(ss2 - 54)) return 0;
case 46:
if (*(uint64_t*)(ss1 - 46) != *(uint64_t*)(ss2 - 46)) return 0;
case 38:
if (*(uint64_t*)(ss1 - 38) != *(uint64_t*)(ss2 - 38)) return 0;
case 30:
if (*(uint64_t*)(ss1 - 30) != *(uint64_t*)(ss2 - 30)) return 0;
case 22:
if (*(uint64_t*)(ss1 - 22) != *(uint64_t*)(ss2 - 22)) return 0;
case 14:
if (*(uint64_t*)(ss1 - 14) != *(uint64_t*)(ss2 - 14)) return 0;
case 6:
if (*(uint32_t*)(ss1 - 6) != *(uint32_t*)(ss2 - 6)) return 0;
return *(uint16_t*)(ss1 - 2) == *(uint16_t*)(ss2 - 2);
case 61:
if (*(uint64_t*)(ss1 - 61) != *(uint64_t*)(ss2 - 61)) return 0;
case 53:
if (*(uint64_t*)(ss1 - 53) != *(uint64_t*)(ss2 - 53)) return 0;
case 45:
if (*(uint64_t*)(ss1 - 45) != *(uint64_t*)(ss2 - 45)) return 0;
case 37:
if (*(uint64_t*)(ss1 - 37) != *(uint64_t*)(ss2 - 37)) return 0;
case 29:
if (*(uint64_t*)(ss1 - 29) != *(uint64_t*)(ss2 - 29)) return 0;
case 21:
if (*(uint64_t*)(ss1 - 21) != *(uint64_t*)(ss2 - 21)) return 0;
case 13:
if (*(uint64_t*)(ss1 - 13) != *(uint64_t*)(ss2 - 13)) return 0;
case 5:
if (*(uint32_t*)(ss1 - 5) != *(uint32_t*)(ss2 - 5)) return 0;
return *(ss1 - 1) == *(ss2 - 1);
case 60:
if (*(uint64_t*)(ss1 - 60) != *(uint64_t*)(ss2 - 60)) return 0;
case 52:
if (*(uint64_t*)(ss1 - 52) != *(uint64_t*)(ss2 - 52)) return 0;
case 44:
if (*(uint64_t*)(ss1 - 44) != *(uint64_t*)(ss2 - 44)) return 0;
case 36:
if (*(uint64_t*)(ss1 - 36) != *(uint64_t*)(ss2 - 36)) return 0;
case 28:
if (*(uint64_t*)(ss1 - 28) != *(uint64_t*)(ss2 - 28)) return 0;
case 20:
if (*(uint64_t*)(ss1 - 20) != *(uint64_t*)(ss2 - 20)) return 0;
case 12:
if (*(uint64_t*)(ss1 - 12) != *(uint64_t*)(ss2 - 12)) return 0;
case 4:
return *(uint32_t*)(ss1 - 4) == *(uint32_t*)(ss2 - 4);
case 59:
if (*(uint64_t*)(ss1 - 59) != *(uint64_t*)(ss2 - 59)) return 0;
case 51:
if (*(uint64_t*)(ss1 - 51) != *(uint64_t*)(ss2 - 51)) return 0;
case 43:
if (*(uint64_t*)(ss1 - 43) != *(uint64_t*)(ss2 - 43)) return 0;
case 35:
if (*(uint64_t*)(ss1 - 35) != *(uint64_t*)(ss2 - 35)) return 0;
case 27:
if (*(uint64_t*)(ss1 - 27) != *(uint64_t*)(ss2 - 27)) return 0;
case 19:
if (*(uint64_t*)(ss1 - 19) != *(uint64_t*)(ss2 - 19)) return 0;
case 11:
if (*(uint64_t*)(ss1 - 11) != *(uint64_t*)(ss2 - 11)) return 0;
case 3:
if (*(uint16_t*)(ss1 - 3) != *(uint16_t*)(ss2 - 3)) return 0;
return *(ss1 - 1) == *(ss2 - 1);
case 58:
if (*(uint64_t*)(ss1 - 58) != *(uint64_t*)(ss2 - 58)) return 0;
case 50:
if (*(uint64_t*)(ss1 - 50) != *(uint64_t*)(ss2 - 50)) return 0;
case 42:
if (*(uint64_t*)(ss1 - 42) != *(uint64_t*)(ss2 - 42)) return 0;
case 34:
if (*(uint64_t*)(ss1 - 34) != *(uint64_t*)(ss2 - 34)) return 0;
case 26:
if (*(uint64_t*)(ss1 - 26) != *(uint64_t*)(ss2 - 26)) return 0;
case 18:
if (*(uint64_t*)(ss1 - 18) != *(uint64_t*)(ss2 - 18)) return 0;
case 10:
if (*(uint64_t*)(ss1 - 10) != *(uint64_t*)(ss2 - 10)) return 0;
case 2:
return *(uint16_t*)(ss1 - 2) == *(uint16_t*)(ss2 - 2);
case 57:
if (*(uint64_t*)(ss1 - 57) != *(uint64_t*)(ss2 - 57)) return 0;
case 49:
if (*(uint64_t*)(ss1 - 49) != *(uint64_t*)(ss2 - 49)) return 0;
case 41:
if (*(uint64_t*)(ss1 - 41) != *(uint64_t*)(ss2 - 41)) return 0;
case 33:
if (*(uint64_t*)(ss1 - 33) != *(uint64_t*)(ss2 - 33)) return 0;
case 25:
if (*(uint64_t*)(ss1 - 25) != *(uint64_t*)(ss2 - 25)) return 0;
case 17:
if (*(uint64_t*)(ss1 - 17) != *(uint64_t*)(ss2 - 17)) return 0;
case 9:
if (*(uint64_t*)(ss1 - 9) != *(uint64_t*)(ss2 - 9)) return 0;
case 1:
return *(ss1 - 1) == *(ss2 - 1);
}
} else {
int ret = luaio_strncmp(s1, s2, n);
return ret ? 0 : 1;
}
}
@yakczh 有类型必然会衍生出接口和泛型在理， 技术复杂度要增长是必然，但代码量必然会膨胀不能认同， 不适合浏览器这种宿主环境（但这个是编译的呀，并非要运行浏览器）。 OO是不是好选择不好说，但OO编程在javascript 领域需求是很现实的。
@vellengs 我说的代码量膨胀是 同样的功能,用类型系统实现 要多写额外的代码 异步流程的代码在编译运行以后代码调试出错定位这都是额外的复杂度 关于OO实现js领域需求,这个说再多也没用,按你的逻辑,一切不重要,重要的是人的能力足够,抽象能力足够,现在有个很现实的需求,需要一个抽象能力强的人写出一套js的电商系统,然后就跟http/get/post一样放到哪家公司立马就能用,我们公司马上掏钱就买 ,不差钱,就差一个抽象能力强的程序猿
刚进入新公司，项目用的是typescript写的，已经做的很大了，也很复杂，代码量巨大，一个函数都有几百行的代码，编译速度真是坑爹，修改代码每次都要等十几秒才能编译。选择nodejs原因就是因为它的精简，结果用了typescript以后搞得又像java那样复杂。最关键的是做这个系统的人全部离职了，对于新来的很难入手。
