引入 javascript

by James Wright

詹姆斯·賴特(James Wright)

在您JavaScript項(xiàng)目中引入類型安全性？ 再想一想 (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:

自從我第一次發(fā)布本文以來，我就聽到過關(guān)于JavaScript中類型安全的各種反爭論，盡管我仍然相信許多項(xiàng)目不需要使用類型化JavaScript超集，但我承認(rèn)我在發(fā)布此文章時(shí)過于倉促文章。 一些合適的用例隨后引起了我的注意：

• 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背后的低級(jí)渲染引擎Glimmer是用TypeScript編寫的，以促進(jìn)單態(tài)調(diào)用站點(diǎn) ，在由V8和可能的其他JavaScript引擎執(zhí)行時(shí)有助于提高性能

• 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

  由于項(xiàng)目龐大， Visual Studio Code受益于TypeScript。 鑒于它作為桌面應(yīng)用程序分發(fā)，因此在我看來，擁有一個(gè)代碼庫而不是在構(gòu)建時(shí)協(xié)調(diào)各個(gè)軟件包是一個(gè)明智的選擇

• 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 (當(dāng)然是我自己的一個(gè)項(xiàng)目，所以這里可能有偏見！)是用TypeScript編寫的，以便消費(fèi)者可以為Web編寫大型的模塊化游戲，同時(shí)可靠地減少由于拼寫錯(cuò)誤和其他JavaScript問題引起的運(yùn)行時(shí)錯(cuò)誤。動(dòng)態(tài)性質(zhì)

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.

我還意識(shí)到，使用TypeScript編寫較小的庫并使用在構(gòu)建時(shí)生成的類型定義同時(shí)發(fā)布它們，可以使它們與類型化和傳統(tǒng)JavaScript項(xiàng)目無縫集成，從而為開發(fā)人員提供了更廣泛的技術(shù)選擇。

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.

今天，我遇到了一篇有關(guān)JS ++推出的文章，該文章聲稱“修復(fù)JavaScript缺乏類型安全性”。 有趣的是，我們已經(jīng)有了TypeScript ， ST-JS和Scala.js ，它們可以幫助開發(fā)人員最終實(shí)現(xiàn)相同的目標(biāo)。

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

在著手介紹這一長篇文章之前，請?jiān)试S我重點(diǎn)強(qiáng)調(diào)以下三點(diǎn)：

• 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

  之前，我已經(jīng)編寫了有關(guān)建立簡單TypeScript項(xiàng)目的教程 。 我看到了偽善，但是自從一年多以前發(fā)表以來，我的觀點(diǎn)已經(jīng)改變

• 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
  強(qiáng)類型和靜態(tài)類型是至關(guān)重要的范例。 前者提供了代碼中所代表的實(shí)體，它們之間的關(guān)系以及所期望提供的功能的透明性，而后者則是復(fù)雜系統(tǒng)中重要的編譯時(shí)安全網(wǎng)。 我來自C＃背景，所以我對此有第一手經(jīng)驗(yàn)
• I also love JavaScript, given its inherent flaws, many of which have been addressed with ECMAScript 6 and 7
  考慮到JavaScript固有的缺陷，我也很喜歡JavaScript，其中許多缺陷已通過ECMAScript 6和7進(jìn)行了解決。

So why am I generally against static typing in JavaScript?

那么，為什么我通常反對JavaScript中的靜態(tài)類型？

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如此強(qiáng)大的語言是其弱類型的本質(zhì)。 通過類型強(qiáng)制實(shí)現(xiàn)邏輯分支很簡單，而且創(chuàng)建任意類型的對象實(shí)例非常容易。 此外，缺乏編譯功能(除非使用諸如Babel這樣的編譯器或編譯工具)，只要代碼不會(huì)導(dǎo)致任何怪異的行為，開發(fā)速度就非?？臁?在我看來，這就是使其對于前端和簡單后端(例如IoT)開發(fā)如此強(qiáng)大的原因。

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.

我個(gè)人認(rèn)為，如果開發(fā)的系統(tǒng)如此復(fù)雜以至于需要類型安全，那么應(yīng)該使用一種支持其核心的語言。 用JavaScript編寫包含復(fù)雜數(shù)學(xué)運(yùn)算的指導(dǎo)系統(tǒng)簡直是瘋狂。

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工具和超集的主要擔(dān)心是，它們可以編譯為JavaScript。 因此，這些程序在動(dòng)態(tài)環(huán)境中運(yùn)行，因此仍然可能發(fā)生相同的副作用。 例如，TypeScript可以是靜態(tài)類型的(即在編譯時(shí)收集并分析類型信息)，但是必須完全相信生成的代碼仍將按預(yù)期運(yùn)行。 是的，當(dāng)然，即使是靜態(tài)類型的語言也通常會(huì)編譯成較低級(jí)別的語言，然后通常對其進(jìn)行解釋，但是這些目標(biāo)語言肯定是通過打字作為一等公民而設(shè)計(jì)的； 例如，Microsoft的.NET JIT編譯器在編譯為本機(jī)代碼之前仍對中間語言執(zhí)行運(yùn)行時(shí)類型檢查 。

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?

此外，在進(jìn)行前端開發(fā)時(shí)，我仍然保持思維定勢，應(yīng)該使用JavaScript來補(bǔ)充 HTML和CSS解決方案，例如向元素添加類，對后端服務(wù)進(jìn)行HTTP調(diào)用等。雖然Web在創(chuàng)作框架方面已經(jīng)成熟較大的，基于UI的應(yīng)用程序(僅供參考，我也使用React.js和Vanilla JS編寫了較大的應(yīng)用程序；我倆都愛)，我更喜歡保持JS的輕量化。 我了解實(shí)際上這并不總是可能的，但是如果后端系統(tǒng)充當(dāng)基本業(yè)務(wù)邏輯的源頭，那么前端代碼將變得更輕便，冗余度也將減少。 在這方面，類型系統(tǒng)會(huì)帶來什么好處？

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.

按照前端軟件的大小，我目前的工作是針對總體系統(tǒng)的每個(gè)方面編寫集中的Web應(yīng)用程序。 與我們商店的一個(gè)大型單頁應(yīng)用程序相反，該應(yīng)用程序包含產(chǎn)品列表視圖，產(chǎn)品詳細(xì)信息視圖和購買過程視圖，我們?yōu)樗鼈兲峁┝烁髯缘腘ode.js支持的應(yīng)用程序。 顯然，就松散耦合和彈性而言，這是最佳實(shí)踐，但是從代碼角度來看，它可以更輕松地將重點(diǎn)放在前端某個(gè)區(qū)域的實(shí)現(xiàn)上。

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?

我的最后一個(gè)論據(jù)是： JavaScript真的很難學(xué)習(xí)嗎？ 如前所述，ECMAScript 5本身是一種有缺陷的語言。 例如，不同的函數(shù)調(diào)用模式以及它們?nèi)绾斡绊?#96;this`關(guān)鍵字以及缺少塊作用域，可能會(huì)使初學(xué)者感到困難。 但是，有了ECMAScript 6，再加上大量的驚人資源，就很容易克服并意識(shí)到這些問題。 為什么不跳過中間人直接學(xué)習(xí)語言呢？

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!

最后我會(huì)說我是所有打字方法的愛好者，但是有些方法比其他方法更適合某些情況。 如果JavaScript在開發(fā)團(tuán)隊(duì)及其項(xiàng)目中無處不在，那么它對于大多數(shù)前端軟件來說都是最佳的，那么肯定不需要超集。 另外，還有一大堆本來就是類型安全的語言，所以別再發(fā)明輪子了！

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

引入 javascript

總結(jié)

以上是生活随笔為你收集整理的引入 javascript_在您JavaScript项目中引入类型安全性？ 再想一想的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。