标签：需要 开发人员 代码 JavaScript 类型 TypeScript myVar 消亡
JavaScript 需要消亡
I hope you’re unhappy.
很少，当我想要参与我的受虐倾向时，我会让自己参与一个需要（或使用 JavaScript 会变得更容易）的项目。这是一个软件开发，相当于需要建造一座桥，然后选择只用牙刷砍倒你需要的树来建造这座桥。不，我没有夸大其词。
看，我很清楚有一个 原因 近三年来，JavaScript 一直是 Web 的权威语言。它不是特别难学（尽管它很难掌握），它适用于所有可能使用的浏览器，并且几乎是唯一有效的操作 DOM 的方法。所有这一切都很好，花花公子。然而，我认为我们坚持使用 JavaScript 这么长时间的唯一原因是因为每次尝试替换或改进它（除了一个例外，我们将在后面讨论）都是巨大的失败。 JavaScript 不是 好的 语;只是替代方案是戏剧性的 更差 .以下是我持有这种观点的一些原因的非常精简的集合，其中散布了一些“迷人”且非常具有描述性的语言。
我在看什么？
JavaScript 存在 C++ 共有的问题；有很多方法可以解决给定的问题，所有这些方法都是 技术上 有效，这意味着两个 JavaScript 开发人员可以拥有完全不同的代码库，尽管这些代码库具有相同的用例。一个更容易识别的例子可以在 JavaScript 处理类的方式中找到，考虑到它被吹捧为面向对象的语言，它应该处理得很好。这是一个例子：
我的班级{
我在哪里；
构造函数（myVar）{
这个.myVar = myVar;
}
} const myObject = new MyClass(3);
控制台.log(myObject.myVar);
很简单，对吧？我们声明一个名为 我的课 ，我们给它一个以变量作为参数的构造函数，然后我们稍后在代码中将该类实例化为一个对象。这种语法几乎与其他 OOP 语言（如 Java 和 C#）处理类声明和对象实例化的方式相同。然而，这是踢球者 - 这只是语法糖。你实际上并没有在这里创建一个类。相反，您正在创建一个原型。下面的代码片段是 功能相同 你在上面看到的：
函数我的函数（myVar）{
这个.myVar = myVar;
} MyFunction.prototype.myVar = 3;
console.log(MyFunction.prototype.myVar);
现在，我知道你在想什么。如果我们从不实例化，这有什么相同之处 我的功能 作为一个对象，而只是改变 我的变量 直接地？这难道不能与更改类中的静态字段而不是实例化类相提并论吗？答案是否定的——JavaScript 中的一切都是对象。因此，一位开发人员可以选择遵循传统的 OO 设计模式并使用类，而另一位开发人员则可以使用原型设计。这两种设计本质上是做同样的事情，但是如果你不习惯 JavaScript 中的原型，你对第二个代码片段的最初反应将是（完全有理由的）困惑。
许多其他使用 OO 概念的语言的优点之一是它们的语法是通用的。例如，在 C++ 中，有 一种句法模式 写作课。同样，在 C# 和 Java 中，类的设计是普遍可识别的，因为这些语言只提供一种语法正确的类编写方式。虽然有多种可能的方法来解决同一个问题并没有什么明显的错误，但是当两个开发人员能够编写完全不同的代码来解决同一个问题时，它可能会出现问题——这在 JavaScript 中很普遍。它不仅限于类或 OO 概念。
类型歧义
JavaScript 不允许你严格定义类型；类型是从代码的上下文中推断出来的。因此，每个变量只能由 是，容易， 或者 常量。 有人会认为这会使事情变得更容易，这是可以原谅的，在某些情况下，这完全没问题——一个小程序可能不需要严格定义的类型，如果有明确的注释或代码写得很好，其他开发人员最能做到可能会推断给定函数在接收参数时需要什么类型。然而，在更大的代码库中，类型推断成为一个巨大的、破坏项目的问题。
考虑一个庞大的 Web 应用程序，它有一个用 JavaScript 编写的复杂而错综复杂的后端，它使用 Node.js 和 Express 之类的东西。这个应用程序可能有很多功能，可能需要也可能不需要非常特定的数据类型或对象才能正确执行。如果有人进来并添加了一些使用错误数据类型调用这些函数之一的代码，那么整个应用程序现在可能会陷入困境，直到所述开发人员找出正确的类型。该功能实际上也有可能 做 接受错误的数据类型，但对该参数做了一些意想不到的事情，例如对不应显示的对象进行字符串化，由于传入的参数无效而停止异步函数执行等。
冒着热议的风险，冗长总是比模棱两可更可取。我需要确切地知道一个函数做了什么，它需要什么参数，以及如果我搞砸了会发生什么。我不喜欢审查其他代码库的过程主要由猜测组成，我也不喜欢编写一个函数只是为了忘记它稍后接受的数据类型，这需要比指定类型所需的更多时间投入论据旁边。
这很好地融入了一种可以整理 JavaScript 的许多怪癖的语言……
你可能应该使用 TypeScript
Maybe God really does exist.
TypeScript 理所当然地在 Web 开发人员中获得了相当多的赞誉，原因很容易理解。一方面，我提到的类型推断问题通过引入严格定义的类型立即得到解决。以本文开头的代码片段为例，现在转换为等效的 TypeScript 代码：
我的班级{
var myVar：数字；
构造函数（myVar）{
这个.myVar = myVar;
}
} 常量 myObject : MyClass = new MyClass(3);
控制台.log(myObject.myVar);
只需对代码进行两次更改，我们现在就可以立即清楚地了解该程序的许多方面。我们确信 我的变量 是类型 数字 （数据类型的集合，包括 int、double、float 等），我们知道 我的对象 是类型 我的课 .考虑到这个代码片段有多小，这些看起来可能是微不足道的变化，也许它们确实如此，但更大的程序从这种清晰性中受益匪浅，并防止了许多因类型模糊而引起的问题。俗话说——在开发中犯一个需要一点点努力来修复的简单错误，比在生产中犯一个导致偏头痛的错误要好得多。
当然，TypeScript 并不能解决 JavaScript 的所有问题。但很明显，这是一次大规模的升级，我看不出有什么理由不在任何 Web 项目中采用。几乎所有最流行的框架（例如 React 和 Angular）都支持使用 TypeScript，您也可以使用该语言进行后端工作。
TypeScript 有可能永远杀死 JavaScript，我们都会因此而变得更好。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
本文链接：https://www.qanswer.top/29400/14351201
标签：需要,开发人员,代码,JavaScript,类型,TypeScript,myVar,消亡 来源： https://www.cnblogs.com/amboke/p/16685277.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。