引入 javascript

by James Wright

詹姆斯·赖特(James Wright)

在您JavaScript项目中引入类型安全性？ 再想一想 (Introducing Type Safety To Your JavaScript Project? Think Again)

更新— 2017年2月1日 (Update — 1st February 2017)

I’ve heard various counter-arguments regarding type safety in JavaScript since I first published this article, and while I still believe a lot of projects do not require the use of a typed JavaScript superset, I admit that I was too hasty in publishing this article. Some appropriate use cases have subsequently grabbed my attention:

自从我第一次发布本文以来，我就听到过关于JavaScript中类型安全的各种反争论，尽管我仍然相信许多项目不需要使用类型化JavaScript超集，但我承认我在发布此文章时过于仓促文章。 一些合适的用例随后引起了我的注意：

• Glimmer, the low-level rendering engine behind Ember, is written in TypeScript to promote monomorphic call sites, aiding performance when executed by V8 and potentially other JavaScript engines

  Ember背后的低级渲染引擎Glimmer是用TypeScript编写的，以促进单态调用站点 ，在由V8和可能的其他JavaScript引擎执行时有助于提高性能

• Visual Studio Code benefits from TypeScript due to the sheer size of the project; given that it’s distributed as a desktop application, having one codebase rather than reconciling individual packages at build time is, in my opinion, a sensible option

  由于项目庞大， Visual Studio Code受益于TypeScript。 鉴于它作为桌面应用程序分发，因此在我看来，拥有一个代码库而不是在构建时协调各个软件包是一个明智的选择

• Sect (admittedly a project of my own, so there’s potential bias here!) is written in TypeScript so that consumers can write large, modular games for the web while reliably reducing runtime errors resulting from misspellings and other issues that arise as a result of JavaScript’s dynamic nature

  Sect (当然是我自己的一个项目，所以这里可能有偏见！)是用TypeScript编写的，以便消费者可以为Web编写大型的模块化游戏，同时可靠地减少由于拼写错误和其他JavaScript问题引起的运行时错误。动态性质

I have additionally realised that writing smaller libraries in TypeScript and publishing them with the type definitions generated at build time simultaneously enables their seamless integration with typed and traditional JavaScript projects, thus giving developers a wider technological choice.

我还意识到，使用TypeScript编写较小的库并使用在构建时生成的类型定义同时发布它们，可以使它们与类型化和传统JavaScript项目无缝集成，从而为开发人员提供了更广泛的技术选择。

Nonetheless, for posterity’s sake, here’s the original article in its entirety.

尽管如此，为了后代的缘故，这是本文的全文。

Today, I encountered an article regarding the launch of JS++, which claims to “fix JavaScript’s lack of type safety.” Funnily enough, we already have TypeScript, ST-JS, and Scala.js, which assist developers in ultimately achieving the same goal.

今天，我遇到了一篇有关JS ++推出的文章，该文章声称“修复JavaScript缺乏类型安全性”。 有趣的是，我们已经有了TypeScript ， ST-JS和Scala.js ，它们可以帮助开发人员最终实现相同的目标。

Before I launch into this tirade, allow me to highlight three important points:

在着手介绍这一长篇文章之前，请允许我重点强调以下三点：

• I’ve previously written a tutorial on establishing a simple TypeScript project. I see the hypocrisy but my opinions have changed since I published it over a year ago

  之前，我已经编写了有关建立简单TypeScript项目的教程 。 我看到了伪善，但是自从一年多以前发表以来，我的观点已经改变

• Strong typing and static typing are vital paradigms. The former provides transparency over the entities represented in one’s code, their relationships, and the functionality they may be expected to provide, while the latter is an important, compile-time safety net in complex systems. I come from a C# background, so I have first-hand experience of this强类型和静态类型是至关重要的范例。 前者提供了代码中所代表的实体，它们之间的关系以及所期望提供的功能的透明性，而后者则是复杂系统中重要的编译时安全网。 我来自C＃背景，所以我对此有第一手经验
• I also love JavaScript, given its inherent flaws, many of which have been addressed with ECMAScript 6 and 7考虑到JavaScript固有的缺陷，我也很喜欢JavaScript，其中许多缺陷已通过ECMAScript 6和7进行了解决。

So why am I generally against static typing in JavaScript?

那么，为什么我通常反对JavaScript中的静态类型？

Predominantly, what makes JavaScript such a powerful language is its weakly-typed nature; it’s trivial to implement branches of logic via type coercion, and it’s so easy to create object instances of an arbitrary type. Furthermore, the lack of compilation (unless one is using a transpiler or build tool such as Babel, for example) makes development incredibly fast, as long the code doesn’t result in any bizarre behaviours. In my opinion, this is what makes it so powerful for frontend and simple backend (e.g. IoT) development.

最主要的是，使JavaScript如此强大的语言是其弱类型的本质。 通过类型强制实现逻辑分支很简单，而且创建任意类型的对象实例非常容易。 此外，缺乏编译功能(除非使用诸如Babel这样的编译器或编译工具)，只要代码不会导致任何怪异的行为，开发速度就非常快。 在我看来，这就是使其对于前端和简单后端(例如IoT)开发如此强大的原因。

I personally believe that if one is developing a system so complex that it requires type safety, then one should be using a language that supports it at its core; writing a guidance system, which involves complex mathematical operations, in JavaScript is insane.

我个人认为，如果开发的系统如此复杂以至于需要类型安全，那么应该使用一种支持其核心的语言。 用JavaScript编写包含复杂数学运算的指导系统简直是疯狂。

My main concern with these JavaScript tools and supersets is that they compile to, well, JavaScript; these programs are consequently running in a dynamic context, thus the same side effects could still occur. TypeScript, for example, may be statically typed (i.e. type information is gathered and analysed at compile-time), but one must have full confidence that the resulting code will still run as expected. Yes, of course even statically-typed languages are usually compiled to a lower-level language, which is then typically interpreted, but these target languages were surely designed with typing as a first-class citizen; as an example, Microsoft’s JIT compiler for .NET still implements runtime type-checking of its intermediate language before compiling to native code.

我对这些JavaScript工具和超集的主要担心是，它们可以编译为JavaScript。 因此，这些程序在动态环境中运行，因此仍然可能发生相同的副作用。 例如，TypeScript可以是静态类型的(即在编译时收集并分析类型信息)，但是必须完全相信生成的代码仍将按预期运行。 是的，当然，即使是静态类型的语言也通常会编译成较低级别的语言，然后通常对其进行解释，但是这些目标语言肯定是通过打字作为一等公民而设计的； 例如，Microsoft的.NET JIT编译器在编译为本机代码之前仍对中间语言执行运行时类型检查 。

Furthermore, when undertaking frontend development, I’m still of the mindset that JavaScript should be used to complement HTML and CSS solutions e.g. adding classes to elements, making HTTP calls to backend services etc. While the web has matured in terms of frameworks for authoring larger, UI-based applications (FYI, I have written larger apps with React.js and vanilla JS too; I love both), I prefer to keep my JS as light as possible. I understand that this isn’t always a possibility in reality, but if backend systems serve as the source truth for fundamental business logic, then frontend code becomes lighter and less redundant; in this respect, what benefits will a type system bring?

此外，在进行前端开发时，我仍然保持思维定势，应该使用JavaScript来补充 HTML和CSS解决方案，例如向元素添加类，对后端服务进行HTTP调用等。虽然Web在创作框架方面已经成熟较大的，基于UI的应用程序(仅供参考，我也使用React.js和Vanilla JS编写了较大的应用程序；我俩都爱)，我更喜欢保持JS的轻量化。 我了解实际上这并不总是可能的，但是如果后端系统充当基本业务逻辑的源头，那么前端代码将变得更轻便，冗余度也将减少。 在这方面，类型系统会带来什么好处？

Following my point of the size of frontend software, my current work entails writing concentrated web applications for each concern of the overarching system; as opposed to one large single-page application for our shop, which contains a product list view, a product details view, and a purchase journey view, we have respective Node.js-backed apps for them. Evidently, this is a best practice in terms of loose coupling and resilience, but from a code point of view, it allows one of focus more easily on the implementation of one area of our frontend.

按照前端软件的大小，我目前的工作是针对总体系统的每个方面编写集中的Web应用程序。 与我们商店的一个大型单页应用程序相反，该应用程序包含产品列表视图，产品详细信息视图和购买过程视图，我们为它们提供了各自的Node.js支持的应用程序。 显然，就松散耦合和弹性而言，这是最佳实践，但是从代码角度来看，它可以更轻松地将重点放在前端某个区域的实现上。

My final argument is this; is JavaScript really that difficult to learn? As I’ve said before, ECMAScript 5 itself is a flawed language; the different function invocation patterns and how they affect the `this` keyword and lack of block scoping, for example, can make it difficult for beginners. However, with ECMAScript 6, plus the plethora of amazing resources out there, it’s easy to overcome and be aware of these issues. Why not just skip the middle man and learn the language directly?

我的最后一个论据是： JavaScript真的很难学习吗？ 如前所述，ECMAScript 5本身是一种有缺陷的语言。 例如，不同的函数调用模式以及它们如何影响`this`关键字以及缺少块作用域，可能会使初学者感到困难。 但是，有了ECMAScript 6，再加上大量的惊人资源，就很容易克服并意识到这些问题。 为什么不跳过中间人直接学习语言呢？

I’ll close by saying I’m a fan of all typing approaches, but some suit certain scenarios more than others. If JavaScript works best for the majority of frontend software, given its ubiquity within development teams and their projects, then surely it doesn’t need a superset. Additionally, there is a truckload of languages that are inherently type safe, so stop reinventing the wheel!

最后我会说我是所有打字方法的爱好者，但是有些方法比其他方法更适合某些情况。 如果JavaScript在开发团队及其项目中无处不在，那么它对于大多数前端软件来说都是最佳的，那么肯定不需要超集。 另外，还有一大堆本来就是类型安全的语言，所以别再发明轮子了！

翻译自: https://www.freecodecamp.org/news/stop-bringing-strong-typing-to-javascript-4da0666cba6e/

引入 javascript