最近尝试着使用 Taro 写一个微信小程序，Taro 是京东凹凸实验室开发的一款使用 React 语法多端统一开发解决方案， 其实也就是使用 React 语法编写一次，使用不同的编译方式编译出 BATT 各家小程序，React Native 程序。
Taro 在对各端支持上还有一些差异，在开发的时候有一些细节需要关注。 而目前小程序基本只有微信小程序比较热门，而且腾讯推出云开发，可以一定程度省去后端的工作量， 所以目前入门基本只关注微信小程序就足够了。
背景
作为一名后端工程师，对前端（Web 端，App 端）经验还是比较缺失的， JavaScript 也是第一次真正认真地接触。
由于使用 React 的语法，所以说到的 JavaScript 基本都含 JSX。
JavaScript 从入门到放弃
由于 JavaScript 的资源相对多，所以入门的时候没有太多犹豫就选择了 JavaScript，而不是大热的 TypeScript， 也正是由于这个选择，才会让我感觉到为什么现在 TypeScript 会大热。
JavaScript 最大的特点应该就是自由，动态语言的弱类型系统，类型之间可以随意转换，而且转换发生在运行时， 写代码的时候看起来都没有问题，可是运行起来之后，可能就会出现各种各样的报错。
在网络调用时，由于对类型没有预先的考虑，基本就是把同一个函数复制到另一个位置， 修改一下使用的参数，就又堆叠了几行代码。
TypeScript
TypeScript 和 JavaScript 几乎可能无缝转化，我把一个 JavaScript 的文件后缀改成 TypeScript 之后， 把一些变量的类型补上，就可以编译通过了。 但是也就是这个补充类型的过程中，开始思考这些类似的地方，我应该把他们抽象出来。
类型系统
强类型系统可以在编译时做出足够多的检查，减少运行时的错误，运行时错误只能依赖于对 App 的各种各样的测试， 而我们都知道，测试也是很难做到面面俱到的，所以让错误出现在编译期，显然是更好的选择。
Interface
TypeScript 的特点就是在 JavaScript 中加入了类型检查，而最核心的特性之一就是 Interface 所实现的 鸭子类型 。
interface 也是在 JavaScript 中没有的， interface 指定了成员们的类型，主要用途也正是做更多的类型检查。
interface 规定的是一系列约束，而不需要实例显示去实现，当实例满足 interface 中的约束时，
那实例就可以用到这个 interface 。
当他走路像鸭子，叫起来像鸭子，游泳也像鸭子，那他就可以称为鸭子
由于在 JavaScript 中，函数是一等公民，和其它类型无异，所以在 interface 中，
我们可以列出来需要的变量和其类型，同样的，我们也可以列出来需要实现的函数。
最后，在 TypeScript 编译成 JavaScript 之后， interface 的信息是会被删除掉的，
也就是 interface 的检查只发生在 TypeScript 中。
Class
ECMAScript 6(ES6) 正式给 JavaScript 世界引入了 Class 。TypeScript 在这个基础上又衍生出了自己的特性。
首当其冲就是 static 属性，可以让你在没有实例时，直接使用类函数，最常见的用法就是用于新建一个类的实例。 这样就可以把新建实例的函数也归到类的定义中。
通常，我们不需要把 Class export 出去，只 export 对应的 “构造函数” 就可以了，交互可以通过 interface 完成。
后话
当然，我 JavaScript 只是使用了比较短暂的时间，很多地方没有深入理解，没有领会到正确的用法， 但也正是这样，我反而觉得 JavaScript 自由性让人在上手的时候，只关注于能实现就行， 而不关注软件工程中的程序设计。
反观 TypeScript，强制的类型检查，让人不自觉地考虑，这个地方是否应该有一个类？ 学习的时候，很快就会看到 Interface，Class，都是熟悉的味道，很自然地就会想， 我这里是否能抽象，后面这里是否可以复用。
JavaScript 是一个很伟大的语言，在前端有着无与伦比的统治力， 有着面向对象的特性，有函数式编程的特性，熟练之后可以写出各种花式的代码， 但是我还是更喜欢死板一点的 TypeScript，简单上手就可以写出不错的代码，后续也可以在这个基础上不断迭代。