引入 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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。