那时候还没有全栈开发这一说，不过想想自己似乎 10 年前就开始了这种工作状态。我过往的技术经历比较复杂，在我们那个年代最主要的软件还是以 Windows C/S 架构为主，搞过 Socket 通信、写过 ARP 病毒，研究过 MFC 的 Thunk 技术；后来慢慢又接触了 C#、 Java ，还深深记得刚从 DAO 转入到 Hibernate 时的那种懵逼。

那时候觉得学什么都特别的开心，计算机专业学的还是“科学”与“技术”，也没有“互联网行业”这一说，我们这一行都还叫做“软件行业”，培训班都还在教你如何做网页。《晓松奇谈》里面有一集讲歌坛那个“白衣飘飘的年代”，我觉得 2000 年-2010 年这 10 年就似乎是我的那个“白衣飘飘的年代”。那时候技术还比较神秘，大家都以研习 Windows Undocumented API 为荣，我记得我还打印了一本 Intel x86 汇编的小册子随身携带；那时候以为掌握了 Hook 就掌控了操作系统，以为会用 Ethereal 就监听了全世界。

我记得那是一个午后，我的导师花了两个小时给我讲解 JavaScript 的基础语法。这应该算是我从业多年来，最快速最密集学习的一门语言了。我还依稀记得那“ 22 条军规”：

变量类型有 numer 、 string 、 bool......
定义变量用 var
if & for 跟 C 语言一样
function 跟 C 语言一样
class 的语法是...
访问成员变量必须带上 this 指针
闭包是......
......

就这么从头到尾讲完了这 10 来条语法，然后导师对我说：“恩，差不多就这些了，你先开工吧，明天我来检查......”。 WTF ！！！就像驾校司机刚告诉了你如何启动汽车、如何操作刹车、油门，就对你说：“差不多了，明天你开车去趟......”。好吧，一个“老司机”就这么上路了，反正写啥都是在写 BUG 。

作为那个年代的三大神兽语言 C++、 C#、 Java ，我基本上都同时在写。不过他们都是 Class First 语言，以面向对象为核心，类是一等公民，定义一个类也是各种繁文缛节（相对于动态语言来说）。所以我在第一次见到 JavaScript 这种动态语言时，我的内心是震撼的，犹如从三维世界进入到四维世界的那种“宏大”，那种难以描述的“自由”。

为了防止有人喷我，特地做一下说明，不然一堆屁话就来了： 1 、回头来看，我如此的震撼并不是因为 JavaScript 语言本身的精妙，而是因为动态语言相对于静态语言的自由程度； 2 、我之前的技术经历主要是在 C++，并未接触过动态语言； 3 、 JavaScript 语言也有很多糟粕，不算“优秀”的语言，但并不影响我对它的喜爱； 4 、 Ruby 也是我喜爱的语言之一。

一个 JavaScript 的类（准确的讲是指模拟 C++ 里同一概念的类），它身上的属性、方法可以被动态的添加、删除、修改；一个函数可以作为变量到处传递，还有 lambda 表达式，可以直接写在函数的参数里面作为 Callback ，这在当时的 C++/Java 里面简直不可想象。

在 C++ 里面，底层的很多网络库都是 C 语言实现的，所以一个 C++ 的成员函数是不能直接直接做为 Callback 函数传给底层 lib 的，而是要传递一个类的 static 方法，然后再想办法从这个 static 方法跳回到成员方法。 MFC 的 Thunk 技术就是在解决这一问题。直至今天在 Java 里面要实现一个 Callback 还需要写一大堆 Interface 、 Listener 什么的，真的是非常繁琐（ Java 8 已经支持 lambda 表达式了，通过引入编译工具可以在 Android 开发里面使用，强烈推荐）。

而最最重要的一点就是 JavaScript 的世界观其实就是一张 Hash 表，至少我的理解是这样的。这就是一个 key-value 的世界，所有类、对象都是 Hash 表，数组也是。 key 就是对象属性， value 可以是普通变量，也可以是函数，也可以是一个对象，等等。只是恰好如果 value 是一个变量，我们习惯称它为成员属性，如果 value 是一个函数，我们习惯称它为成员函数。而 Prototype 原型链也只不过是 Hash 表的一种存储结构，原型链查找也就是一种 Hash 查找算法而已。

10 年前，用了一个下午爱上了 JavaScript ，而 10 年后又遇上了 TypeScript 。这 10 年中大部分时候还是在用 C++ 和 Java 来工作，所以 JavaScript 的一些痛苦，感受并没有像 “职业”开发者那样深，不过也还是遭遇到了不少的坑。变量不用定义就能用，偶尔代码写错一个字就成了一个新变量，为此却要付出大量的 debug 时间；早期调试也相对比较痛苦，这几年工具越来越完善了，不过做为一个从 Visual Studio 入门的开发者，看别的平台的调试方法总觉得不够傻瓜。

遇上 TypeScript 虽然没有 10 年前遇上 JavaScript 那样轰轰烈烈，但是也算喜爱有加。遇上 Javascript （遇上动态语言）我觉得解决的是精神生活的问题，而遇上 TypeScript 算是解决了物质生活的问题。以前开发 JavaScript 时的部分脏活累活都可以被消灭了。

这里才刚刚开始

先简单科普一下 TypeScript ：

TypeScript 是由微软开发的一种基于 JavaScript 语法的语言，且已经支持了 ES6 、 ES7 语法。你可以理解它为 JavaScript 的超集，也可以理解为 JavaScript 的增强版。 TypeScript 代码不能直接运行，需要通过编译器编译成 JavaScript 文件才能使用，所以依然可以在浏览器环境或者 node 环境下无缝使用。

好了，跑题了这么久，我终于要说为什么要从 JavaScript 转到 TypeScript 了，它到底解决了什么问题。

编译期类型检查

最最重要的能力就是：

编译期类型检查
编译期类型检查
编译期类型检查

重要的事情要说三遍。有了编译期类型检查再也不用担心变量写错名字、错误的类型赋值、写掉对象属性这些基本问题了。虽然无时无刻都需要书写类型信息，但是我相信这是值得的。部分 JavaScript 开发者可能会觉得有点繁琐，其实相信从静态语言转到 JavaScript 的开发者一定会感觉到非常亲切，所以主要还是一个先入为主的习惯问题。相对于这些付出，收益是巨大的。尤其在大型项目里面，后面接手的同事再也不用去“猜测”一个 Callback 返回的变量到底是什么类型了。

以下是 JavaScript 代码：

var name;                   //定义变量

function getName(type) {    //定义函数
    return ...
}

class Person {              //ES7 下的类定义
    name = '';
    age = 18;

    getName() {
        ...
    }

    getAge() {

    }
}

以下是 TypeScript 代码：

var name: string; //定义变量

function getName(type: string):string {  //定义函数
    return ...
}

class Person {              //类定义
    private name: string = '';
    private age: number = 18;

    public getName(): string {
        ...
    }

    public getAge(): number {

    }
}

大家可以发现，最基本的语法其实就是在所有的变量或者函数的定义时，在变量名字的后面加多了一个类型信息。相较于传统静态语言的语法，基本上就是把类型信息从前面移到了后面而已。

我们再来看一下调用代码：

let name: string = obj.getName()   //编译通过
let name: number = obj.getName()   //编译失败
let name = obj.getName()           //编译通过
let nameOther: number = name       //编译失败

第一行编译通过，因为类型一致
第二行编译失败，因为类型不一致
第三行编译通过，因为 name 没有指定类型， TypeScript 编译器会自动推导，认为 name 变量也是 string 类型
第四行编译失败，因为 name 被推导为 string 类型，而 nameOther 是 number 类型，类型检查失败。

所以其实我们可以看到， TypeScript 也并不是无时无刻都必须要写上类型信息，只要定义时类型信息足够丰富，我们也可以选择性的偷懒。

最近有看到一种言论说：

连 C# 都在拼命动态化，为何要让 JavaScript 变成一个静态语言？

其实我觉得这里是有一些误解的：“静态类型检查并不等于静态语言或者说静态化”。

动态语言虽然可以在运行期动态改变类型，但是一个变量类型的改变也是受“业务需求”影响的。我相信没有谁会因为喜欢炫技而在代码里面不断改变一个变量的类型信息。而大部分时候，是因为业务的需求再配合语言的动态优势，可以让一个变量在不同阶段存储不同类型的数据。

我们回忆一下，其实大部分时候一个变量在它生命周期内依然是同一种类型一直用到销毁。只有小部分时候有那么几个变量会偶尔存储 number ，偶尔存储 string ；或者在服务器返回的数据里面，根据 errCode ，在 json 里面取出余下不同的信息。

所以一言以蔽之就是说：

“即使是动态语言，一个变量在生命周期内，它的类型变化可能性是非常有限的”。

那么 TypeScript 非常好的解决了这个问题，那就是“联合类型（ Union ）”。相信有过 C 语言基础的同学，对 Union 一定不会陌生。 Union 就是说一个变量可以时而为 A 类型，时而为 B 类型，到底是什么类型，这个由开发者自行判断。

这不正好和“服务器返回的 json 数据格式”的情况非常吻合么？我们通过检查 errCode （在 restful API 下，更提倡用 header 来返回错误信息）来判断余下部分应该为 Data 域还是是 Error 域。

一个 Union 的变量定义：

let name: number | string;
name = 123;                     //编译通过
name = "danney";                //编译通过
name = true;                    //编译失败

上述代码编译成 JavaScript 的 ES5 版本为：

var name;
name = 123;
name = "danney";
name = true;

对比可以发现，其实 TypeScript 完全没有没有给你带来什么学习成本和使用不便，它真的是在帮你，帮你检查类型、帮你排除那些粗心大意的小错误。

除此之外，在 TypeScript 里面还有很多突破静态类型的方法，比如你可以把一个变量强转为 any 类型，这样就不受编译器类型检查限制了。所以再也不要误认为 TypeScript 把 JavaScript 静态化了。

代码智能提示

习惯了在 Visual Studio 上的番茄工具，以及 Android Studio 和 XCode 上的智能提示功能，切到 JavaScript 时，真是有一些不习惯，虽然目前几大主流的 Web 开发工具也有提示功能，但是我觉得还是不够完善和智能。

毕竟 TypeScript 语言天生是带有类型信息的，可以完美识别出一个对象的类型，它自身有哪些属性和方法，然后调用这些方法时，也能智能匹配出它的函数原型。

说到这里就不能不提 Visual Studio Code 了，简称 VSCode 。 VSCode 是微软新一代的轻量级跨平台开发工具，虽然也叫 Visual Studio ，但是我觉得和传统的 Visual Studio 家族工具已经没有太大关系了。它更像 WebStorm 或则 Sublime Text 这样的 Web 开发工具，轻量级、跨平台，支持各种语言或者平台插件， Debug 也很方便。

用 TypeScript 做开发，基本上 VSCode 就是标配了。 VSCode 自带 TypeScript 插件，完美智能提示，类型推导，让你的开发效率极大提升。有意思的是 VSCode 和 TypeScript 编译器也是用 TypeScript 语言开发的，这就像一个鸡生蛋蛋生鸡的问题。很多年前我就是在想 Java 编译器也是由 Java 语言开发的，那么最早的 Java 语言又是用什么来编译的呢？

其实答案很简单，现代编译器基本上都不是从零裸写的，而是先书写这门语言的“语法描述文件”，然后由“编译器生成器”来读取“语法描述文件”，从而生成一个“编译器”。所以无论是 Java 还是 TypeScript ，都是先用别的语言来创建一个最基本的编译器，再用这门语言来开发自己的新版编译器。

JavaScript 混合编程

很多同学一定担心 TypeScript 的生态环境不够丰富，相关的 lib 不够多，这一点完全不用担心。因为 TypeScript 和 JavaScript 可以在一个工程里面混合编程， TypeScript 的文件后缀是 .ts ， JavaScript 的文件后缀是 .js 仅此而已。 ts 文件里面依然用 import 或者 require 来引入一个 module 。

唯一的问题就是因为引入的 JavaScript 模块因为没有类型信息，会导致 VSCode 的智能提示无法使用而已。有智能提示时算是一个补充，没有智能提示时我觉得也不算吃亏。

不过其实这个问题基本上已经解决了，那就是 TypeScript 在编译为 JavaScript 时，可以自动产生一个叫做 .d.ts 的文件，它就是 js 的头文件，和 C 语言的 .h 文件一个道理。所以当一个编译后的 TypeScript 作为一个 lib 发布时，会附上 .js 和 .d.ts 两种文件。这样别人在导入你的 lib 时，也会获得智能提示功能。

那么对于一个基于 JavaScript 开发的老牌 lib ，有没有办法也能智能提示呢？答案是肯定的。那就是现在有大量的开发者在为老牌 lib 人肉编写 .d.ts 文件。并且微软提供了一个叫做 typings 的工具，可以为你在线查找并下载一个 lib 的 .d.ts 文件。 typings 和 npm 使用类似，最新的 typings 也已经统一到 npm 工具上了，即使用 npm 就可以下载 .d.ts 文件了。还有最新版的 VSCode 也能做到自动分析你的包依赖，然后后台自动下载 .d.ts 文件。不用担心 JavaScript lib 没有 .d.ts 文件，连微信小程序的头文件都已经有了。

编译质量

对于担心 TypeScript 编译质量不如人手写优化的同学，你们也完全不用怕。 TypeScript 编译逻辑主要有两部分，一部分是去掉类型信息，回归正常 JavaScript 语法；另外一部分就是翻译 ES6 和 ES7 语法，我目测编译结果和 babel 基本上一致，所以 babel 的编译结果如果你都不担心， TypeScript 的编译结果也就没什么好担心的了。

但是假如你连整个编译过程都觉得不能忍受的话，那一定是你写的代码太少。你来开发 iOS 和 Android 试试？当年 Windows QQ 编译一次可是要 40 分钟啊，我们一般都是点一下编译按钮，然后就去吃饭了。记得以前有从 JavaScript 入门的同学转去做 Android 开发时，狂吐槽分号的问题，我想说：真的是你见识的东西太少。可以热爱 JavaScript ，但是不要让它蒙了你的眼。

调试

VSCode 提供了完善了调试工具，非常方便。因为我基本上是在 node 环境下开发， Web 调试不好说，不过 node 下再也不用蹩脚的弹到 Chrome 里面去 debug 了。 TypeScript 编译后会自动生成 souremap 文件，所以 debug 时是不会涉及到编译后的 js 源文件的。就好像 C 语言编译成汇编后，你 debug 时也不用关注汇编一样。

所以另外一个需要注意的就是团队开发时，如果要修复 bug ，千万千万不要修改编译后的 js 源文件。因为之前在网上看到有人在吐槽他用 TypeScript 开发的代码，编译成 js 上线后，有同学吭哧吭哧拿 js 代码去修复 bug ，还一个劲吐槽原作者。脑子是个好东西，希望他也有。所以一定要避免在一个项目里面有的人用 TypeScript 开发，有的人用 JavaScript 开发。要么全都用，要么就别用。

其他

相比于 CoffeeScript 等变种 JavaScript 语言， TypeScript 语法几乎保持不变，没有什么学习难度。说学习曲线陡峭或者觉得团队内部不好培训、不好推进的，我真心觉得这个行业的从业者素质可能确实需要提升。

其他几个不错的新增语法点：

TypeScript 提供了 enum ，我个人超级喜欢
TypeScript 提供了泛型，解决了不少问题
TypeScript 支持 JSX 语法，做 ReactJS 和 React-Native 开发的同学应该会非常喜欢

差不多就这些了，拥抱 TypeScript 吧，希望你也会喜欢！

TypeScript

JavaScript

编译

变量

90 条回复 • 2019-05-17 15:53:21 +08:00

joeyFuck

2017-01-15 22:35:53 +08:00

总觉得 TS 流行不起来，因为要多写代码

lucky215

2017-01-15 22:47:03 +08:00

目前来讲没有看到 TS 吸引我的地方，我觉得 es 挺好，加上 eslint 足够

peneazy

2017-01-15 23:04:57 +08:00 via Android

我觉得 js 从业者不易过早使用 ts ，要经过对 js 的深层次理解再用 ts

Wangxf

2017-01-15 23:23:38 +08:00

说 ts 适合大项目到底是有多少前端程序员做的是大项目？

neugls

2017-01-16 00:30:48 +08:00

ts 和 haxe 比，我更喜欢 haxe, http://www.haxe.org, 有不了解 haxe 的朋友可以看一下。

FrankFang128

2017-01-16 00:39:13 +08:00

@Wangxf 这个吐槽我给满分

vietor

2017-01-16 07:53:31 +08:00 via Android

别把自己编程风格不好怪罪到语言身上，好像赵匡胤似的。

murmur

2017-01-16 08:10:01 +08:00

老子写 js 就是喜欢他的无类型你让我写 ts 好气啊
现在就看 10 年内 web asm 能不能起来，到时候直接换 JAVAscript 我才不要 ts

ragnaroks

2017-01-16 08:49:15 +08:00

事实上,写过 js 再来写 ts 会异常蛋疼,写过 ts 再来写 js 毫秒级过渡.
辛亏在写 js 前我是写 C#的.

agtc

2017-01-16 08:49:51 +08:00

ts 还是很不错的，最近发现很多库使用 ts

ragnaroks

2017-01-16 08:50:36 +08:00

还有,可能是因为强迫症,我一定要写明类型,js/php 这种都写个注释注明类型,c#绝对不用 var,不然看着难受

ChefIsAwesome

2017-01-16 09:01:11 +08:00

ts 的好处是它基本就是 js 加强类型。对从其他强类型语言过来的人来讲，它是入门 js 的好东西。对于已经写了很久 js 的人来讲，强类型的吸引力有那么大吗？

think2011

2017-01-16 09:14:53 +08:00

没敢花时间去学 TS 的原因除了公司不可能给用之外，还有几年前用过 coffeescript ，那时候 github 上很多项目也是 coffeescript 写的，但如今已经完全不同了。

hauk0101

2017-01-16 09:22:11 +08:00 via Smartisan T1

@Wangxf 游戏行业用的多

hanzichi

2017-01-16 09:22:47 +08:00

@murmur 哈哈，我也是

corona

2017-01-16 09:22:58 +08:00

TS 是一群做 JAVA 的人去写的，对于写习惯写 js 的人来说，这种方式就是一个累赘，还是没有兴趣是用 TS

sagaxu

2017-01-16 09:28:24 +08:00 via Android

之前用 coffeescript ，现在用 kotlin ，与 ts 无缘了

xcatliu

2017-01-16 09:42:57 +08:00

支持楼主的分享。

@joeyFuck 我认为 ts 的缺点不是要多写代码，而是有更高的学习成本。

很多 js 程序员认为 js 已经是最优秀的语言了，不愿意也不屑于去接受 Interface, Generics 等 OOP 的概念。
不看好 TypeScript 没问题。不过建议去了解一下它的基本概念，会有所收获的。

顺便打个广告： https://github.com/xcatliu/typescript-tutorial

dong3580

2017-01-16 09:46:58 +08:00

@xcatliu
看起来似乎大约就是 js 加了类型。。。 233333 不知道我的理解对不对，

CrispElite

2017-01-16 09:49:41 +08:00

我接受 Interface, Generics 等 OOP 的概念，但是我不愿意也没有兴趣学习 typescript 。我更愿意花时间接触前端之外的内容

robertlyc

2017-01-16 09:50:52 +08:00

宁可 es 原教旨主义也不用极端的 ts

seki

2017-01-16 10:00:37 +08:00

变量不用定义就能用，偶尔代码写错一个字就成了一个新变量，为此却要付出大量的 debug 时间

看到这句话的我表示……

rongyiran

2017-01-16 10:04:29 +08:00

呵呵，
我去年接触 js 上手就是干
下午面试，面完之后直接就是干 js 代码
现在用 react native ，
之前就是做 Android 原生开发，
从 java 转 js ，你不知道是有多痛苦！

MinonHeart

2017-01-16 10:07:44 +08:00

V8 SoundScript
我丢 https://github.com/v8/v8/wiki/Experiments%20with%20Strengthening%20JavaScript#soundscript

janstk

2017-01-16 10:08:47 +08:00

ts 写的很爽啊。

miniwade514

2017-01-16 10:10:34 +08:00

复杂应用里可以节省一些调试时间，典型特征：多个组件、存在数据通信、前端维护状态。没这些需求的话，强类型也没提供什么明显的价值。

xcatliu

2017-01-16 10:12:30 +08:00

@corona
ts 不是一群做 Java 的人写的，是一群做 C# 的人写的。

murmur

2017-01-16 10:12:31 +08:00

@xcatliu 前台兼职后台 java(springmvc+mybatis)的表示，正统 oop 我都写过， js 那套 oop 你习惯的了么？山寨的都不好说，因为他底层还是原型链啊
所以等啥时候 js 真正把自己的 oop 做出来了再谈语法的问题
何况 ts 跟 java 比语法还是丑陋

xcatliu

2017-01-16 10:15:44 +08:00

@dong3580 核心内容就是 js 加了类型。
另外还加了一些 js 中不存在的概念比如接口（ Interfaces ）、泛型（ Generics ）、枚举类型（ Enums ）等

xcatliu

2017-01-16 10:34:43 +08:00

@murmur @CrispElite 我支持 js 程序员去了解和学习其他语言，正统的 oop 更好。

> 很多 js 程序员认为 js 已经是最优秀的语言了，不愿意也不屑于去接受 Interface, Generics 等 OOP 的概念。
> 不看好 TypeScript 没问题。不过建议去了解一下它的基本概念，会有所收获的。

以上两句话针对一些偏执于 js 的人。

> 何况 ts 跟 java 比语法还是丑陋

是丑陋了很多，为了兼容原生 js 。

> 所以等啥时候 js 真正把自己的 oop 做出来了再谈语法的问题

coffee ts 等的发展推动了 es oop 的发展。

ibegyourpardon

2017-01-16 10:39:10 +08:00

坐等 webassembley ……

xcatliu

2017-01-16 10:39:42 +08:00

@dong3580 还有一点是，代码提示不是一般的爽。

jyootai

2017-01-16 10:42:47 +08:00

弱类型语言非要转向强类型来写不觉得很蛋疼么, 我觉得这是一种倒退, 又回到以前的时代

xjp

2017-01-16 10:45:17 +08:00 via iPhone

ts 目前对于 js 的优势就两点 1 各种新的 es 标准实现 2 变量类型

但是有一个致命的问题不能直接运行那和使用 babel 有什么区别

等到哪天浏览器可以直接支持 ts 的话可以考虑转写 ts

xcatliu

2017-01-16 10:48:47 +08:00 via iPhone

@xjp 浏览器永远都不会直接原生支持 ts 的 🤣

jswh

2017-01-16 10:53:19 +08:00

我用 TS 就是为了他的自动补全，哈哈哈

zhuangzhuang1988

2017-01-16 11:06:21 +08:00

@jswh 我也是..

murmur

2017-01-16 11:08:46 +08:00

@xjp 兄弟你这 ID 危险啊

crysislinux

2017-01-16 11:24:01 +08:00

ts 有时候会影响 js 的表达能力啊，有时候还是蛮头疼的。

Perry

2017-01-16 11:45:25 +08:00

用过 TypeScript 开发 Angular 2 就知道 TypeScript 的益处。
但是前提是开发 Angular 2 。。。

learnshare

2017-01-16 11:48:09 +08:00

@xcatliu 说不准哦

TypeScript 的好处嘛，不是写起来快，而是写起来可靠

PythonAnswer

2017-01-16 11:49:57 +08:00

es3 es5 es6 只跟主流是不是有点古板？

xcatliu

2017-01-16 12:14:04 +08:00 via iPhone

@learnshare 请问你回复的是哪一条 🤔

learnshare

2017-01-16 12:31:18 +08:00

@xcatliu
>浏览器永远都不会直接原生支持 ts 的

@learnshare
>说不准哦

rupert

2017-01-16 12:34:06 +08:00

@neugls 看了下 Haxe ，语法更怪
```
var people = [
"Elizabeth" => "Programming",
"Joel" => "Design"
];
```

不喜欢 babel, 每次改个代码都要等， 1s 也是等啊。不过现在前端不用 babel 就写不了项目了，好在 node 可以不用

sammo

2017-01-16 12:34:45 +08:00

TypeScript 相对 Java, C#, C++ 的优点是它可以编译到 JavaScript

neugls

2017-01-16 12:37:53 +08:00

@jyootai 不是说弱类型转到强类型是一种倒退，真的，你如果去写一个项目，大一点，如果要修改一个地方，如果是弱类型，你会感觉不敢下手，不知道这个地方一改，会不会引起其他什么问题，而且这个问题还没法在编译调试的时候弄出来，如果是强类型的，通过编译器类型判断，很快就能找到有问题的代码，项目质量就比较可控。

我现在写 php 就这样子，一年前写的代码，我现在能看懂，但是这么久了，只能大概的总体，一个变量为什么用，在哪地方有用了，这个真的不记得了，如果我贸然一改，鬼知道哪里会出问题，一旦上线了，后果会很严重

这就是我为什么喜欢强类型，编译型语言的原因，相比 ts, Haxe 他是编译型的， ts 每一个文件生成一个 js 文件， Haxe 是把所有的 haxe 文件生成一个单独的 js 文件，我觉得这种模式很好。

我就在用 haxe 和 pixi.js 结合做一个项目，还在写

大家可以去看看 Haxe

uxstone

2017-01-16 13:22:38 +08:00

动态类型一时爽，代码重构火葬场

chemzqm

2017-01-16 13:40:21 +08:00

typescript 适合有计划、有架构的大型项目。
现实是创业项目基本都是无组织、无计划方式糙快猛开发上线的， typescript 会增加很多额外成本，其实 flow 也不错，相对 typescript 更加灵活些。

xcatliu

2017-01-16 13:41:04 +08:00

@neugls 生成一个单独的 js 文件还是多个 js 文件应该属于工程的范畴。
应用到真实环境的项目， TypeScript 需要先编译成 js ，再根据（ Webpack or Browserify 等）配置打包成一个或多个 js 文件。

我推荐项目中需要有三个目录：

- src: 源文件
- lib: 编译好的文件，供其他（不使用 TypeScript 的）模块使用
- dist: 打包好的用于生产环境的文件（放到 html 中）

这套规则用到各种环境（ es6 ， coffee 等）都屡试不爽。当然看情况可以只有 src, lib 或 src, dist

nozama

2017-01-16 13:53:16 +08:00

据说 WASM 今年就要发布了
Web 端以后的趋势是回归原生、静态类型（也许只是我希望...），交给编译器编译成 WASM 就完了。从这个角度，比起 C#/ C++ , TS 就没什么优势

gxm44

2017-01-16 14:05:03 +08:00

@Wangxf 同感

xylitolLin

2017-01-16 14:07:02 +08:00

坚决拥护 native javascript 不动摇

gxm44

2017-01-16 14:13:44 +08:00

@murmur 是的

murmur

2017-01-16 14:18:06 +08:00

@uxstone 现实的原则是宁可推翻不重构。。

eoo

2017-01-16 14:39:05 +08:00 via Android

坚决拥护 JavaScript

xcodebuild

2017-01-16 15:48:45 +08:00

@uxstone 不管什么类型，没有充足的测试去做重构都是火葬场。。

qdwang

2017-01-16 16:14:04 +08:00

@nozama wasm 要先做个 gc ，才会比较方便各种语言编译成他，目前只能手动管理内存

xcodebuild

2017-01-16 16:39:52 +08:00

@xcatliu 谢谢你的 tutorial ，写的很赞

2017-01-16 16:57:54 +08:00

Class First 是这个意思？我觉得楼主还需要学习一个。

个人觉得 ts 也就那样吧，编程体验有点类似 C++

abcbuzhiming

2017-01-16 17:19:59 +08:00

我对这东西的看法很简单，当年 JScript 没有能成功的事情，你换个名字重来一遍也不会成功的

xcatliu

2017-01-16 17:28:17 +08:00 via iPhone

@codefalling 😁

aroa

2017-01-16 18:09:02 +08:00

喜欢 typescript 很大的原因就是写的爽，我写类型的原因只是为了更好的补全（逃
而且写一些短代码的时候，基本没写过类型，大部分都能自动推导出来

jswh

2017-01-16 18:14:35 +08:00

另外，现在已经不用 typings 了，直接 npm 搜索 @types/the-types-project 就好了

qdwang

2017-01-16 18:39:08 +08:00

世界上有三种机器人。

第一种机器人特点
* 你告诉他要做什么，他就去做什么
* 碰到做不下去的事情，他继续做，直到自己毁坏

第二种机器人特点
* 你告诉他要做什么，他就去做什么
* 碰到做不下去的事情，他会停止，并告诉使用者哪里做不下去了

第三种机器人特点
* 你告诉他要做什么和做事情的规则，他会先思考能不能做
* 如果不能做，他会告诉使用者哪里为什么不能做

第二种机器人的使用者的特点是，会在下指令的时候把做事情的规则与要做的事情在自己大脑里推演好。

如果你对自己大脑推演逻辑的准确性与速度很有信心的话，完全可以选择第二种机器人来使用。

啊，原来 V2EX 好像都是选择第二种机器人的天才耶~

fds

2017-01-16 18:49:05 +08:00

哈哈，没想到推广 ts 还挺困难。我个人感觉 ts 用起来还是挺舒服的， IDE 补全、自动格式化、易于重构。当然我是后端……不过看前端的各大框架也都基本都支持 ts 呢。

civet

2017-01-16 20:53:19 +08:00 via iPhone

我用 ES4 楼主别拦我

magicdawn

2017-01-16 21:28:26 +08:00

调试是个问题...
在 VSCode 上可以调试 ts, 但是其他环境 / 场景下呢, 例如调试 bin script, 例如调试 mocha test, 例如...
VSCode 写 app 还行, 我要是写 lib, 估计是瞎...

bombless

2017-01-16 21:47:15 +08:00 via Android

公司同事感受不到 IDE 提示带来的好处，对类型本身也没啥概念，跟 cto 推荐完 ts 后自己再想感觉其实也没法在我公司落地了 233 。

realpg

2017-01-16 22:28:24 +08:00

你们这些搞前端的，非得把行业碎片化到极致你们才开心么……

greatbody

2017-01-16 22:50:58 +08:00

TypeScript 的确很好，现在正在修改 definitely-typed

maomaomao001

2017-01-16 23:51:58 +08:00 via Android

你们都不看原文的嘛。。。。明明只是类型提示而已。。。。。并不是强类型啊。。。
而且还明明那么好。。。。

lhc70000

2017-01-16 23:56:43 +08:00

个人感觉对于大一点的项目还是 ts 省心得多。不过这样硬推广感觉不会有什么效果，毕竟用不到的当然不会觉得需要。等到觉得写 vanilla javascript 力不从心的时候程序员自然会去找更好的解决方法。

chengzi

2017-01-17 00:10:16 +08:00

你们这些搞前端的，非得把行业碎片化到极致你们才开心么……

yuxuan

2017-01-17 00:10:54 +08:00

不加入我就是喜欢弱类型喜欢打开控制台就是干的感觉

HaiYu

2017-01-17 00:22:45 +08:00

如果要开发比较复杂的应用，可以考虑 Angular2 和 TS 。 TS 背后是微软， Ng2 背后是谷歌，还是很靠谱的，像一些游戏框架对 TS 支持就比较早。大型系统考虑重构、测试、 Debug 什么的用原生 JS 就比较棘手了，不过大多数前端做的项目还是很轻的，用 TS 学习成本什么的反而高了，辩证的看吧，但是不考虑应用场景的无脑拥护都是不成熟的表现。

jiyinyiyong

2017-01-17 00:45:50 +08:00

楼主写惯了类型看到 TypeScript 毫无压力, 我写惯了 everything is an expression 再碰 js 觉得很难受.

hasbug

2017-01-17 09:14:55 +08:00

不懂，我还是继续学习 JavaScript 吧，免得成了邯郸学步。

fzhw88

2017-01-17 09:32:06 +08:00 via Android

严格模式能解决大部分问题，非得搞个新语言吗

polun

2017-01-17 09:46:20 +08:00

@Wangxf 一语中的。

iyangyuan

2017-01-17 09:48:29 +08:00

觉得多此一举，如果这不是在羞辱 JavaScript ，那么就是在羞辱你自己

coolcoffee

2017-01-17 16:46:06 +08:00

typescript 和 javascript 的争议不亚于 PC 和 Mac 哪个更好用，我都已经死心了，好用就自己用着，说服别人只是自己的一厢情愿而已，想换的自然会切换过来。

mingyun

2017-01-17 21:47:27 +08:00

前端真会玩

beginor

2017-01-18 08:31:55 +08:00 via Android

ts 是 js 的超集，所有的 js 都是 ts ，如果你不打算直接写 ts ，用来辅助编写 js 也是很爽的。

不管你是在用 WebStorm ，还是用 VS code ，比如执行 `npm install jquery @types/jquery` 之后，写 ts 自然不用说，写 js 也有奇效！