typescript是前端还是后端

TypeScript是JavaScript的一个超集，添加了可选的静态类型和面向对象编程，因此它可以在任何使用JavaScript的地方使用，包括前端和后端。TypeScript是由微软开发的一个开源编程语言，它能通过TypeScript编译器或Babel转译为JavaScript代码，可运行在任何浏览器，任何操作系统。TypeScript扩展了JavaScript的语法，任何现有的JavaScript程序可以不加改变的在TypeScript下工作。

TypeScript 诞生于微软（Microsoft），由 C# 首席架构师、.NET（dotnet）创立者 Anders Hejlsberg 设计开发。TypeScript 简单来说就是强类型系统的 JavaScript。它是 JS 的超集（Superset），也就是说，TS 支持 JS 中所有语法，并且还扩展了很多面向对象编程（OOP）的一些功能。TypeScript 首个公开版本 0.8 于 2012 年 10 月发布，并受到了 GNOME 之父 Miguel de Icaza 的称赞，不过他指出 TypeScript 的最大缺点是它缺乏成熟的 IDE 支持，例如当时唯一能支持 TS 只有运行在 Windows 上的 Visual Studio，因此 Mac 和 Linux 使用者无法有效使用 TS 编写项目。不过，这个缺点很快被克服了。1 年之后，很多编辑器，例如 Eclipse、Sublime、Vim 等，都开始支持 TypeScript 语法。如今，绝大多数主流编辑器都能有效支持 TypeScript。而有了 TypeScript 的加持，你在 IDE 中就可以爽快的享受 TS 特有的自动完成（Autocomplete）以及类型提示（Typing Hint），以便于编写可靠而高质量的代码。正如官网中对 TypeScript 的一句话介绍：“Typed JavaScript at Any Scale”。

面向接口编程

TypeScript 的设计理念来自于面向接口编程（IOP），一种基于抽象类型约定（Abstract Type Constraint）的程序设计模式。要真正了解 TypeScript，首先得了解面向接口编程的概念和原理。最初引入 IOP 概念的论文《面向接口编程》发表于 2004 年，它属于面向对象编程（OOP）体系的一部分，是更为先进和独立的编程思想。作为 OOP 体系的一部分，IOP 更加强调规则和约束，以及接口类型方法的约定，从而让开发人员尽可能的关注更抽象的程序逻辑，而不是在更细节的实现方式上浪费时间。很多大型项目采用的都是 IOP 的编程模式。

上图是 IOP 编程模式的示意图，在 Java 或 C# 这样的 OOP 语言中，随处可见这样的处理方式。类型（Class）的方法（Method）由接口（Interface）来约定，而类型中需要实现（Implement）接口中定义的抽象方法。例如 IService 接口定义了 Request(url)、Auth(usr, pwd) 方法，而这个接口不管这两个方法如何实现，只是将方法的名称、参数与返回值定义下来，而具体的实现，即就是实现该功能的核心代码，将在 Service 这个类中完成。

这样注重抽象方法约定的设计模式对于构建大型项目来说具有非常大的优势。首先，它不要求编程人员在程序开发早期或设计系统阶段编写任何核心代码，从而编程人员可以将主要精力放在架构设计以及业务逻辑，避免浪费过多时间在思考具体实现上。其次，由于 IOP 中多了接口这一抽象层，避免将核心代码细节暴露给开发者，不熟悉该模块的开发者可以从文档、名称、参数、返回值等来快速推断程序逻辑，这大大的降低了程序复杂性以及维护成本。最后，IOP 可以让编程变得更灵活，它天生支持多态（Polymorphic），可以作为 OOP 中类继承（Class Inheritance）的有效替代。可能很多初学者会抱怨说这种设计理念让编程变得臃肿，但不得不说这种附加的约束能够让大型项目在面对复杂性和多变性时显得更加稳定和反脆弱。

读者可能会问，这跟 TypeScript 有什么关系？其实，如果你用 TS 编写过大型项目，应该能够意识到 IOP 这种理念在 TS 中发挥的作用。接下来，本文将介绍 TS 的一些核心概念，这将有助于读者进一步理解 TS 的特性以及它为何适合大型项目。

用 TS 构建大型项目

对于大型项目，你首先联想到的是什么？对于不同领域的开发工程师来说，可能有不同的理解。不过单就软件行业来看，一个软件开发项目被称作 “大型项目”（Large Project），通常意味着将涉及大量的功能模块，从而具有较高系统复杂性（Complexity）。一个大型项目的成功，除了满足传统项目管理中的周期、预算控制以外，还需要注重质量，从软件工程角度看来就是可靠性（Robustness）、稳定性（Stability）、可维护性（Maintainability）、可扩展性（Scalability）等等。就像建筑工程一样，你一定不希望自己设计的建筑是摇摇欲坠的，你需要它尽可能的稳固，在狂风暴雨下屹立不倒，同时可以灵活修缮维护。而为了保障这些非功能性需求或者质量要求，必须要有一些明确的规范和标准，在建筑工程里也许是工程图纸、精密测量等，而在软件工程里则是代码规范（Coding Standard）、设计模式（Design Patterns）、流程规范（Process Standard）、系统架构（System Architecture）、单元测试（Unit Testing）等等。其中的代码规范和设计模式尤为重要，因为这是整个软件系统的基础。没有代码，将没有软件程序；而没有好的代码规范和设计模式，将没有好的代码，也就没有可靠的软件程序，有的只是源源不断的程序 Bug 和系统崩溃。TypeScript 可以在代码规范和设计模式上极大的提高代码质量，进而增强系统的可靠性、稳定性和可维护性。

代码规范

代码风格经常是前端项目的痛点，这个可以用 JavaScript 风格检测工具 ESLint 来规范。但是，ESLint 无法解决类型方面带来的问题。只有 TypeScript 可以静态检测在类型层面上可能出现的问题。如果用 TS 来编写前端项目，我会建议对所有可能的变量和方法都用类型约束。而且尽可能不要用 any 类型，因为 any 类型可以涵盖所有其他类型，相当于没有类型，这也失去了类型系统的意义。

跟纯 JS 相比，TS 虽然多了一些额外的类型声明代码，但它却因此而获得了更好的可读性、可理解性和可预测性，因此也会更加稳定和可靠。如果你是从 JS 转到 TS 的初学者，请尽可能克制住不要用 any，这会毁了你的规范和标准。如果你是前后端分离的架构而且在用纯 JS 写前端，在没有明确且可靠的后端接口数据结构约定时，你可能会被迫使写很多类型判断的代码，这跟在静态语言中用反射（Reflect）一样会污染整个代码风格。

TS 其实就是在 JS 上多了一个静态类型系统，没有什么其他的魔法。但就是这个 “小小的” 的附加功能让代码变得规范和可维护，从而成为大型前端项目的首选。很多高级前端工程师都喜欢用 React 或 Angular 来构建大型项目，就是因为它们能支持 TS。不过近期发布的 Vue 3 也及时的加入了 TS 的支持，让它能够胜任大型项目的开发。