标签 TypeScript 下的文章

TypeScript 的使用率在不断上升,Svelte 的开发者 Rich Harris 解释了为什么反其道而行,从 TypeScript 切换到 JavaScript 和 JSDoc。

Svelte 的一个将 TypeScript 转为 JSDoc 的拉取请求引起了一些困惑的评论。评论中有人说:“这个改变是出于什么原因呢?我在到处寻找这个问题或相关讨论,但我没有找到。” 随后,这个问题在 GitHub 上因“讨论过于激烈”而被锁定回复。

在上个月的一次 Svelte Society 采访中,Harris 提供了进一步的背景信息,他说:“我们决定要做的一件事就是在 Svelte 核心代码库中脱离 TypeScript,转向使用 JavaScript。这里有一些细微的复杂性我未曾充分解释。”

他持有的观点是:“类型是非常好的,但是 TypeScript 确实有些困扰…… 当你开始使用 .ts 文件后,你就必须有相应的工具来支持…… 当你使用像 TypeScript 这样的非标准语言时,你会遇到很多阻碍,我已经开始认识到这并不值得。因此,我们将我们所有的类型都放入了 JSDoc 注解中,我们也能获得所有的类型安全性,但没有任何的缺点,因为它就是 JavaScript,所有的东西都在注解中,你可以直接运行代码。这就是我们在 Sveltekit 代码库中所做的,它在 Svelte 4.0 中表现得非常好,所以我们决定对 Svelte 同样采取这种方式,因为这将让我们能够更快速地前进。”

虽然 Svelte/SvelteKit 并非最受欢迎的 JavaScript 框架,但它却是广受好评的框架之一。

开发者倾向于使用 TypeScript,主要因为他们发现强类型降低了错误的发生率,并提升了编码过程中的体验,如代码自动补全和即时帮助等功能。然而,令人惊讶的是,主要做为 API 文档工具的 JSDoc,也可以进行类型检查。这项功能已直接内置在 Visual Studio Code 中,如 这篇文档 所述。开发者只需在 JavaScript 文件顶部加上:

// @ts-check

正如文档中的解释,“当无法推断出类型时,可以利用 JSDoc 注解进行明确说明”。这个特性实际上是由 TypeScript 提供支持,这意味着在实际环境下,TypeScript 和 JSDoc 是相辅相成的。

不过,一个易被忽视的细节是,Harris 主要是在针对库开发的上下文里关注 TypeScript。他认为切换到 JSDoc 在开发应用时,“可能收益不大”,他说道:“如果你在开发一个应用,无论怎样你都不可避免地需要一个构建步骤。你需要优化代码,需要代码压缩,需要打包各种资源。而如果你在构建一个库,我将极力推荐你使用 JSDoc。”

Harris 在 Hacker News 进一步 补充,“Svelte 的用户无需担心,这个变动不会影响到你与 Svelte 使用 TypeScript 的能力——从 Svelte 导出的函数仍然会有所有熟悉的 TypeScript 好处,如类型检查,智能感知,内联文档等”。他坚定地表示:“我们对 TypeScript 的承诺比以往任何时候都更为坚决。”

(题图:DA/e20ff1ee-6388-42ce-8d82-66bc6eebf63c)


via: https://devclass.com/2023/05/11/typescript-is-not-worth-it-for-developing-libraries-says-svelte-author-as-team-switches-to-javascript-and-jsdoc/

作者:Tim Anderson 译者:ChatGPT 校对:wxy

TypeScript 5.0 即将完成,抢跑装饰器功能

TypeScript 团队已经推出了 5.0 RC,完整版本计划于 3 月 14 日发布。它最大的新功能是 ECMAScript 装饰器,这个功能可以通过名为装饰器表达式的注解来扩展类,允许以可重复使用的方式定制类及其成员。但装饰器目前不是 ECMAScript 2023 年草案的一部分。这意味着 TypeScript 的开发者将比 ECMAScript 规范更早获得这一功能。此外,TypeScript 5.0 编译器比以前快了约 10%。

消息来源:Dev Class
老王点评:我觉得 TypeScript 更好、更严谨。

GNOME Shell 和 Mutter 合成器已经脱离了 GTK3

GNOME Shell 现在将只依赖于 GNOME-Desktop-4 / GTK4,X11 显示代码已经脱离了 GTK3,并且 GTK3 也不再作为 Mutter 库/执行程序的依赖关系。GNOME-Shell 对 GTK3 的强制依赖已被放弃,而现在只有一个对 GTK4 运行环境的软链接。当然,仍然有一些依赖 GTK3 的应用,比如 GIMP 现在还在努力往 GTK3 上迁移,甚至还有一些依赖 GTK2 的应用。

消息来源:Phoronix
老王点评:很高兴能看到 GNOME 44 发布时摆脱了 GTK3。

欧洲推动设立月球时区

这个想法是去年年底在荷兰举行的一次会议上提出的,世界各地的航天组织同意迫切需要建立 “共同的月球参考时间”。目前,月球任务是按照操作航天器的国家的时间运行,一个国际公认的月球时区将使大家都方便。目前正在辩论是否应该由一个单一的组织来设定和维持月球上的时间。每个月球日的时间长达 29.5 个地球日,而且每天增加约 56 微秒。

消息来源:AP News
老王点评:或许以后每个星星都需要自己的时区。

下文是 James Henry(@MrJamesHenry)所提交的内容。我是 ESLint 核心团队的一员,也是 TypeScript 布道师。我正在和 Todd 在 UltimateAngular 平台上合作发布 Angular 和 TypeScript 的精品课程。

本文的主旨是为了介绍我们是如何看待 TypeScript 的以及它在加强 JavaScript 开发中所起的作用。

我们也将尽可能地给出那些类型和编译方面的那些时髦词汇的准确定义。

TypeScript 强大之处远远不止这些,本篇文章无法涵盖,想要了解更多请阅读官方文档,或者学习 UltimateAngular 上的 TypeScript 课程 ,从初学者成为一位 TypeScript 高手。

背景

TypeScript 是个出乎意料强大的工具,而且它真的很容易掌握。

然而,TypeScript 可能比 JavaScript 要更为复杂一些,因为 TypeScript 可能向我们同时引入了一系列以前没有考虑过的 JavaScript 程序相关的技术概念。

每当我们谈论到类型、编译器等这些概念的时候,你会发现很快会变的不知所云起来。

这篇文章就是一篇为了解答你需要知道的许许多多不知所云的概念,来帮助你 TypeScript 快速入门的教程,可以让你轻松自如的应对这些概念。

关键知识的掌握

在 Web 浏览器中运行我们的代码这件事或许使我们对它是如何工作的产生一些误解,“它不用经过编译,是吗?”,“我敢肯定这里面是没有类型的...”

更有意思的是,上述的说法既是正确的也是不正确的,这取决于上下文环境和我们是如何定义这些概念的。

首先,我们要作的是明确这些。

JavaScript 是解释型语言还是编译型语言?

传统意义上,程序员经常将自己的程序编译之后运行出结果就认为这种语言是编译型语言。

从初学者的角度来说,编译的过程就是将我们自己编辑好的高级语言程序转换成机器实际运行的格式。

就像 Go 语言,可以使用 go build 的命令行工具编译 .go 的文件,将其编译成代码的低级形式,它可以直接执行、运行。

# We manually compile our .go file into something we can run
# using the command line tool "go build"
go build ultimate-angular.go
# ...then we execute it!
./ultimate-angular

作为一个 JavaScript 程序员(这一刻,请先忽略我们对新一代构建工具和模块加载程序的热爱),我们在日常的 JavaScript 开发中并没有编译的这一基本步骤,

我们写一些 JavaScript 代码,把它放在浏览器的 <script> 标签中,它就能运行了(或者在服务端环境运行,比如:node.js)。

好吧,因此 JavaScript 没有进行过编译,那它一定是解释型语言了,是吗?

实际上,我们能够确定的一点是,JavaScript 不是我们自己编译的,现在让我们简单的回顾一个简单的解释型语言的例子,再来谈 JavaScript 的编译问题。

解释型计算机语言的执行的过程就像人们看书一样,从上到下、一行一行的阅读。

我们所熟知的解释型语言的典型例子是 bash 脚本。我们终端中的 bash 解释器逐行读取我们的命令并且执行它。

现在我们回到 JavaScript 是解释执行还是编译执行的讨论中,我们要将逐行读取和逐行执行程序分开理解(对“解释型”的简单理解),不要混在一起。

以此代码为例:

hello();
function hello(){
    console.log("Hello")
}

这是真正意义上 JavaScript 输出 Hello 单词的程序代码,但是,在 hello() 在我们定义它之前就已经使用了这个函数,这是简单的逐行执行办不到的,因为 hello() 在第一行没有任何意义的,直到我们在第二行声明了它。

像这样在 JavaScript 是存在的,因为我们的代码实际上在执行之前就被所谓的“JavaScript 引擎”或者是“特定的编译环境”编译过,这个编译的过程取决于具体的实现(比如,使用 V8 引擎的 node.js 和 Chome 就和使用 SpiderMonkey 的 FireFox 就有所不同)。

在这里,我们不会在进一步的讲解编译型执行和解释型执行微妙之处(这里的定义已经很好了)。

请务必记住,我们编写的 JavaScript 代码已经不是我们的用户实际执行的代码了,即使是我们简单地将其放在 HTML 中的 <script> ,也是不一样的。

运行时间 VS 编译时间

现在我们已经正确理解了编译和运行是两个不同的阶段,那“ 运行阶段 Run Time ”和“ 编译阶段 Compile Time ”理解起来也就容易多了。

编译阶段,就是我们在我们的编辑器或者 IDE 当中的代码转换成其它格式的代码的阶段。

运行阶段,就是我们程序实际执行的阶段,例如:上面的 hello() 函数就执行在“运行阶段”。

TypeScript 编译器

现在我们了解了程序的生命周期中的关键阶段,接下来我们可以介绍 TypeScript 编译器了。

TypeScript 编译器是帮助我们编写代码的关键。比如,我们不需将 JavaScript 代码包含到 <script> 标签当中,只需要通过 TypeScript 编译器传递它,就可以在运行程序之前得到改进程序的建议。

我们可以将这个新的步骤作为我们自己的个人“编译阶段”,这将在我们的程序抵达 JavaScript 主引擎之前,确保我们的程序是以我们预期的方式编写的。

它与上面 Go 语言的实例类似,但是 TypeScript 编译器只是基于我们编写程序的方式提供提示信息,并不会将其转换成低级的可执行文件,它只会生成纯 JavaScript 代码。

# One option for passing our source .ts file through the TypeScript
# compiler is to use the command line tool "tsc"
tsc ultimate-angular.ts

# ...this will produce a .js file of the same name
# i.e. ultimate-angular.js

官方文档中,有许多关于将 TypeScript 编译器以各种方式融入到你的现有工作流程中的文章。这些已经超出本文范围。

动态类型与静态类型

就像对比编译程序与解释程序一样,动态类型与静态类型的对比在现有的资料中也是极其模棱两可的。

让我们先回顾一下我们在 JavaScript 中对于类型的理解。

我们的代码如下:

var name = 'James';
var sum = 1 + 2;

我们如何给别人描述这段代码?

“我们声明了一个变量 name,它被分配了一个 “James” 的字符串,然后我们又申请了一个变量 sum,它被分配了一个数字 1 和数字 2 的求和的数值结果。”

即使在这样一个简单的程序中,我们也使用了两个 JavaScript 的基本类型:StringNumber

就像上面我们讲编译一样,我们不会陷入编程语言类型的学术细节当中,关键是要理解在 JavaScript 中类型表示的是什么,并扩展到 TypeScript 的类型的理解上。

从每夜拜读的最新 ECMAScript 规范中我们可以学到(LOL, JK - “wat’s an ECMA?”),它大量引用了 JavaScript 的类型及其用法。

直接引自官方规范:

ECMAScript 语言的类型取决于使用 ECMAScript 语言的 ECMAScript 程序员所直接操作的值。

ECMAScript 语言的类型有 Undefined、Null、Boolean、String、Symbol、Number 和 Object。

我们可以看到,JavaScript 语言有 7 种正式类型,其中我们在我们现在程序中使用了 6 种(Symbol 首次在 ES2015 中引入,也就是 ES6)。

现在我们来深入一点看上面的 JavaScript 代码中的 “name 和 sum”。

我们可以把我们当前被分配了字符串“James”的变量 name 重新赋值为我们的第二个变量 sum 的当前值,目前是数字 3。

var name = 'James';
var sum = 1 + 2;

name = sum;

name 变量开始“存有”一个字符串,但现在它“存有”一个数字。这凸显了 JavaScript 中变量和类型的基本特性:

“James” 值一直是字符串类型,而 name 变量可以分配任何类型的值。和 sum 赋值的情况相同,1 是一个数字类型,sum 变量可以分配任何可能的值。

在 JavaScript 中,值是具有类型的,而变量是可以随时保存任何类型的值。

这也恰好是一个“动态类型语言”的定义。

相比之下,我们可以将“静态类型语言”视为我们可以(也必须)将类型信息与特定变量相关联的语言:

var name: string = ‘James’;

在这段代码中,我们能够更好地显式声明我们对变量 name 的意图,我们希望它总是用作一个字符串。

你猜怎么着?我们刚刚看到我们的第一个 TypeScript 程序。

当我们 反思reflect我们自己的代码(非编程方面的双关语“反射”)时,我们可以得出的结论,即使我们使用动态语言(如 JavaScript),在几乎所有的情况下,当我们初次定义变量和函数参数时,我们应该有非常明确的使用意图。如果这些变量和参数被重新赋值为与我们原先赋值不同类型的值,那么有可能某些东西并不是我们预期的那样工作的。

作为 JavaScript 开发者,TypeScript 的静态类型注释给我们的一个巨大的帮助,它能够清楚地表达我们对变量的意图。

这种改进不仅有益于 TypeScript 编译器,还可以让我们的同事和将来的自己明白我们的代码。代码是用来读的。

TypeScript 在我们的 JavaScript 工作流程中的作用

我们已经开始看到“为什么经常说 TypeScript 只是 JavaScript + 静态类型”的说法了。: string 对于我们的 name 变量就是我们所谓的“类型注释”,在编译时被使用(换句话说,当我们让代码通过 TypeScript 编译器时),以确保其余的代码符合我们原来的意图。

我们再来看看我们的程序,并添加显式注释,这次是我们的 sum 变量:

var name: string = 'James';
var sum: number = 1 + 2;

name = sum;

如果我们使用 TypeScript 编译器编译这个代码,我们现在就会收到一个在 name = sum 这行的错误: Type 'number' is not assignable to type 'string',我们的这种“偷渡”被警告,我们执行的代码可能有问题。

重要的是,如果我们想要继续执行,我们可以选择忽略 TypeScript 编译器的错误,因为它只是在将 JavaScript 代码发送给我们的用户之前给我们反馈的工具。

TypeScript 编译器为我们输出的最终 JavaScript 代码将与上述原始源代码完全相同:

var name = 'James';
var sum = 1 + 2;

name = sum;

类型注释全部为我们自动删除了,现在我们可以运行我们的代码了。

注意:在此示例中,即使我们没有提供显式类型注释的 : string: number ,TypeScript 编译器也可以为我们提供完全相同的错误 。

TypeScript 通常能够从我们使用它的方式推断变量的类型!

我们的源文件是我们的文档,TypeScript 是我们的拼写检查

对于 TypeScript 与我们的源代码的关系来说,一个很好的类比,就是拼写检查与我们在 Microsoft Word 中写的文档的关系。

这两个例子有三个关键的共同点:

  1. 它能告诉我们写的东西的客观的、直接的错误:

    • 拼写检查:“我们已经写了字典中不存在的字”
    • TypeScript:“我们引用了一个符号(例如一个变量),它没有在我们的程序中声明”
  2. 它可以提醒我们写的可能是错误的:

    • 拼写检查:“该工具无法完全推断特定语句的含义,并建议重写”
    • TypeScript:“该工具不能完全推断特定变量的类型,并警告不要这样使用它”
  3. 我们的来源可以用于其原始目的,无论工具是否存在错误:

    • 拼写检查:“即使您的文档有很多拼写错误,您仍然可以打印出来,并把它当成文档使用”
    • TypeScript:“即使您的源代码具有 TypeScript 错误,它仍然会生成您可以执行的 JavaScript 代码”

TypeScript 是一种可以启用其它工具的工具

TypeScript 编译器由几个不同的部分或阶段组成。我们将通过查看这些部分之一 The Parser(语法分析程序)来结束这篇文章,除了 TypeScript 已经为我们做的以外,它为我们提供了在其上构建其它开发工具的机会。

编译过程的“解析器步骤”的结果是所谓的抽象语法树,简称为 AST。

什么是抽象语法树(AST)?

我们以普通文本形式编写我们的程序,因为这是我们人类与计算机交互的最好方式,让它们能够做我们想要的东西。我们并不是很擅长于手工编写复杂的数据结构!

然而,不管在哪种情况下,普通文本在编译器里面实际上是一个非常棘手的事情。它可能包含程序运作不必要的东西,例如空格,或者可能存在有歧义的部分。

因此,我们希望将我们的程序转换成数据结构,将数据结构全部映射为我们所使用的所谓“标记”,并将其插入到我们的程序中。

这个数据结构正是 AST!

AST 可以通过多种不同的方式表示,我使用 JSON 来看一看。

我们从这个极其简单的基本源代码来看:

var a = 1;

TypeScript 编译器的 Parser(语法分析程序)阶段的(简化后的)输出将是以下 AST:

{
  "pos": 0,
  "end": 10,
  "kind": 256,
  "text": "var a = 1;",
  "statements": [
    {
      "pos": 0,
      "end": 10,
      "kind": 200,
      "declarationList": {
        "pos": 0,
        "end": 9,
        "kind": 219,
        "declarations": [
          {
            "pos": 3,
            "end": 9,
            "kind": 218,
            "name": {
              "pos": 3,
              "end": 5,
              "text": "a"
            },
            "initializer": {
              "pos": 7,
              "end": 9,
              "kind": 8,
              "text": "1"
            }
          }
        ]
      }
    }
  ]
}

我们的 AST 中的对象称为节点。

示例:在 VS Code 中重命名符号

在内部,TypeScript 编译器将使用 Parser 生成的 AST 来提供一些非常重要的事情,例如,发生在编译程序时的类型检查。

但它不止于此!

我们可以使用 AST 在 TypeScript 之上开发自己的工具,如代码美化工具、代码格式化工具和分析工具。

建立在这个 AST 代码之上的工具的一个很好的例子是: 语言服务器 Language Server

深入了解语言服务器的工作原理超出了本文的范围,但是当我们编写程序时,它能为我们提供一个绝对重量级别功能,就是“重命名符号”。

假设我们有以下源代码:

// The name of the author is James
var first_name = 'James';
console.log(first_name);

经过代码审查和对完美的适当追求,我们决定应该改换我们的变量命名惯例;使用驼峰式命名方式,而不是我们当前正在使用这种蛇式命名。

在我们的代码编辑器中,我们一直以来可以选择多个相同的文本,并使用多个光标来一次更改它们。

Manually select matches

当我们把程序也视作文本这样继续操作时,我们已经陷入了一个典型的陷阱中。

那个注释中我们不想修改的“name”单词,在我们的手动匹配中却被误选中了。我们可以看到在现实世界的应用程序中这样更改代码是有多危险。

正如我们在上面学到的那样,像 TypeScript 这样的东西在幕后生成一个 AST 的时候,与我们的程序不再像普通文本那样可以交互,每个标记在 AST 中都有自己的位置,而且它有很清晰的映射关系。

当我们右键单击我们的 first_name 变量时,我们可以在 VS Code 中直接“重命名符号”(TypeScript 语言服务器插件也可用于其他编辑器)。

Rename Symbol Example

非常好!现在我们的 first_name 变量是唯一需要改变的东西,如果需要的话,这个改变甚至会发生在我们项目中的多个文件中(与导出和导入的值一样)!

总结

哦,我们在这篇文章中已经讲了很多的内容。

我们把有关学术方面的规避开,围绕编译器和类型还有很多专业术语给出了通俗的定义。

我们对比了编译语言与解释语言、运行阶段与编译阶段、动态类型与静态类型,以及抽象语法树(AST)如何为我们的程序构建工具提供了更为优化的方法。

重要的是,我们提供了 TypeScript 作为我们 JavaScript 开发工具的一种思路,以及如何在其上构建更棒的工具,比如说作为重构代码的一种方式的重命名符号。

快来 UltimateAngular 平台上学习从初学者到 TypeScript 高手的课程吧,开启你的学习之旅!


via: https://toddmotto.com/typescript-the-missing-introduction

作者:James Henry 译者:MonkeyDEcho 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

TypeScript 是一种基于 JavaScript 衍生的语言,是由微软为了使大型 Web 应用开发更容易而创造的一种语言,现在已经发布了 2.0 里程碑版本

在用于大型开发时, JavaScript 由于其固有的特性而面临一些挑战。其它的静态编译语言,如 C#、Java 和 C++ 在每次开发人员敲下“编译”时会进行全面的错误检查,而 JavaScript 直到运行时才会做错误检查。这意味着,从输入错误到像对非数字进行数学运算这样的错误用法都根本不会遇到检查,所以,用户不走运的话就会遇到这些问题。而在 TypeScript 中,微软的目标是引入一些其它语言也提供的检查和校验,而依然保持和 JavaScript 的兼容性,并可以编译成 JavaScript。

根据介绍,TypeScript 2.0 引入了一些新功能,改进了性能、增强了 JavaScript 兼容性,并在 TypeScript 进行编译时扩大了错误检查的范围。TypeScript 2.0 中的一大进步就是给予开发人员对 null 值的更大控制。

null 用于表示变量根本没有值,它被其发明人戏称为“价值十亿美元的错误”。一次又一次,程序总是由于没有正确检查一个值是否是 null 值而掉到坑里。但是不管好与不好,所有主流的编程语言都支持这个 null 的概念。

TypeScript 2.0 引入了许多新的特性,但是其中最大的特性就是对 null 值的控制。在 TypeScript 2.0 中,开发人员可以可以启用一种新的行为,以默认防止变量赋值为 null。当启用该选项时,默认情况下变量必须有一个值,且这个值不能是 null。这可以让编译器发现变量没有初始化的错误。

TypeScript 似乎赢得了许多 JavaScript 开发者的拥护,谷歌采用它来开发 Angular 2 框架,而 Visual Studio、Visual Studio Code、Eclipse、Emacs、Vim 等等开发环境也都支持 TypeScript。微软已经把它作为社区驱动的项目进行了开源,目前已经有超过 150 个独立贡献者参与了该项目,这已经是雷蒙德拥抱开源的成功典范之一。

之前我们还哀叹,谷歌的 AngularJS 2.0 的稳定版看起来年底也未必能见到,然而,在 9 月 14 日谷歌总部召开的一个会议上,突然就宣布最终的稳定版发布了——而这距离前一个版本 RC7 的发布才过去了一天。

AngularJS 2.0 的开发始于 2014 年秋天,最初计划是一年后发布正式版本,然而随着项目的日渐庞大,就日复一日的拖延下来了,不过,还好,终于在两年后正式发布了。

这个最终版,按照其官方的说法是:

“最终版”意味着什么?意味着它的稳定性已经得到了大范围用例的验证;意味着它已经针对产品化、文件尺寸和性能进行过优化;意味着借助预编译技术和内置的延迟加载机制,我们可以确信你能发布出最快、最小的应用,并且横跨浏览器、桌面和移动平台;意味着为开发人员准备的 Angular CLI 和风格指南得到了大幅强化。

为什么这么期待 AngularJS 2 呢?这个框架是一个革命性的 Web 开发框架,它在 2010 年 10 月的时候,采用微软的 TypeScript 重写后,更是如虎添翼,不但性能提升、功能增强,资源占用也更少了。不过,有一个不好的消息是, AngularJS 2.0 和 1.x 是不兼容的,因此如果是用 1.x 编写的应用,可能面临着大量的重写和移植工作。

作为一个持续了两年才开发完的前端框架,它的功能特性和亮点显然不是我们一篇短文就可以道尽的,因此这里只是提到一些最引人注目的特性:

  • 提前(AOT)编译
  • 内置按需加载
  • 新的 Angular 命令行接口
  • Angular 样式指南
  • 支持 ES5 和 ES6
  • 集成 React Native 和 NativeScript
  • ……

好了,渴望尝试的 AngularJS 用户们,可以从其官网 https://angular.io/或[GitHub](https://github.com/angular/angular)上下载,这里还有一个[五分钟入门教程](https://angular.io/docs/ts/latest/quickstart.html)。(显然,你知道的,这些都是墙外的。)另外,也有一个官方认可的中文站可以去访问:https://angular.cn/

微软终于发布了 TypeScript 2.0 的第一个 RC 版本。TypeScript 是一个简化版的 JavaScript 语言,被大量用于各种 Web 项目,包括下面提到的著名的 AngularJS 框架。

TypeScript 2.0 中主要的特性是“ 标签结合 tagged unions ”,这个特性可以将两个不同的数据结构联合到一起。你可以把它想象成将一个圆圈和一个方块放一起,这个隐喻来自微软解释标签结合的博文中。

支持标签结合的语言包括 C++、 Scala、 F#、Rust 和 Swift 等等。支持这种特性的原因是,标签结合可以改进类型安全,并减少经常困扰开发者的类型错误。

而另外一方面,Google 也有一些动作……

Google 已经谈论 AngularJS 2.0 很久了。很多人都期望 Google 能在去年底发布 2.0 的稳定版,不过我们听说,就算是到了今年年底也不会见到稳定版。

不过,也快了!Google 今天宣布发布了 Angular 2.0 RC6,支持国际化(I18N)、更多的表单功能,并由于对 Ahead of Time (AoT) 的兼容和支持 ES6 2015 模块而改进了性能。

同时 Google 也宣布发布了 Angular Material 1.1,这是一个 AngularJS 的 UI 组件包。Angular Material 2.x 当前还处于 alpha 阶段,看起来会在 AngularJS 2.0 发布之后才会面世。当前,Angular Material 2.x 已经从 6 个组件增加到了 18 个组件了。