typescript ?:
Strap yourself in. In this guide, we compare when it’s absolutely vital to be using TypeScript, the strictly-typed programming language, and when it makes sense to stick to vanilla JavaScript
束手无策。在本指南中，我们比较了何时使用TypeScript(严格类型的编程语言)绝对至关重要，以及何时使用原始JavaScript是有意义的
Have you heard of that little programming language called TypeScript? You know, the one that Microsoft made? The one that’s kinda blowing up?
您是否听说过这种称为TypeScript的编程语言？ 您知道，微软制造的吗？ 一个有点炸 ？
Maybe you were like me, a true JavaScript purist. I was doing just fine building things with React and Node without types. Prop types and Joi validation have been treating me just nicely, thank you.
也许您像我一样，是一位真正JavaScript纯粹主义者。 我使用无类型的React和Node进行了很好的构建。 道具类型和Joi验证对我很好，谢谢。
Maybe you caved at some point and gave it a shot. Started playing with it. Maybe you hated it because it reminded you of Java. Maybe you got annoyed with how you couldn’t be super productive right away.
也许您在某个时候屈服了并且试了一下。 开始玩。 也许您讨厌它，因为它使您想起了Java。 也许您对如何立即无法高效生产感到恼火。
These were some of my own initial sentiments when I first started with TypeScript.
当我刚开始使用TypeScript时，这是我最初的一些想法 。
I certainly didn’t see the benefit… up until I started experiencing some really annoying stuff. Things like builds not failing when they should, buggy code and typos finding their way into production code somehow in addition to finding it increasingly challenging to express my designs in a really clean object-oriented way.
我当然没有看到好处……直到我开始体验一些非常烦人的东西。 诸如构建之类的东西在应有的情况下不会失败，错误的代码和错别字以某种方式进入生产代码，除了发现以一种非常干净的面向对象的方式来表达我的设计越来越困难。
9 months later into using TypeScript, I’ve built new features in Angular apps for clients, I began compiling Univjobs's React / Redux front-end with TypeScript and ported all of our backend services to TypeScript from vanilla Node.js, refactoring mass amounts of code along the way.
9个月后，使用TypeScript，我在Angular应用中为客户端构建了新功能，我开始使用TypeScript编译Univjobs的React / Redux前端，并将我们所有的后端服务从原始Node.js移植到TypeScript，从而进行大规模重构大量的代码。
In this article, we’ll take a look at some of the most common scenarios and identify when it might be vital to use TypeScript, and when we could probably just do without it and stick to vanilla JS.
在这篇文章中，我们将看看一些最常见的情况，并确定何时可以使用打字稿重要的，当我们很可能只是没有它，并坚持做香草 JS。
为什么今天的讨论比以往任何时候都重要 (Why this discussion matters today more than ever)
I’ve come to the very important conclusion that depending on your situation, context, project, skill level, and other factors, that it’s actually dangerous for your project to NOT be using TypeScript today.
我得出一个非常重要的结论，即取决于您的情况，上下文，项目，技能水平和其他因素，对于您的项目而言，今天不使用TypeScript实际上是很危险的。
The front-end space, for one, is getting more and more complex. Certain features that were once considered bleeding-edge, are now very much standard user experience assumptions.
一方面，前端空间变得越来越复杂。 曾经被认为是前沿技术的某些功能现在已经成为非常标准的用户体验假设。
For example, it’s almost always expected that your app is still going to work offline in some capacity. And when users ARE online, it’s also usually expected that they’re going to get real-time notifications without having to refresh the page.
例如，几乎总是希望您的应用程序仍将以某些容量脱机工作。 而且，当用户在线时，通常也希望他们无需刷新页面即可获取实时通知。
These are some pretty steep (but definitely not unrealistic in 2019) demands.
这些要求非常苛刻(但在2019年绝对不现实)。
Before we dive into different scenarios, we should actually talk about the three categories of really hard software problems to be solved.
在深入探讨不同的场景之前，我们实际上应该谈论要解决的三类真正的硬软件问题。
3类硬软件问题 (3 Categories of Hard Software Problems)
Generally speaking, there are three of these. The Performant System Problem, the Embedded System Problem, and the Complex Domain Problem.
一般来说，其中有三个。 性能系统问题，嵌入式系统问题和复杂域问题。
1.绩效系统问题 (1. The Performant System Problem)
Let’s talk about Twitter for a sec.
让我们谈论一下Twitter。
Twitter is actually a really simple concept.
Twitter实际上是一个非常简单的概念。
You sign up, you make tweets, you like other people’s tweets and that’s pretty much it.
您注册，发表推文，喜欢其他人的推文，仅此而已。
If Twitter is that simple, why couldn’t someone else do it?
如果Twitter这么简单，为什么其他人不能这样做呢？
It’s apparent that the real challenge for Twitter is not actually so much as what it does, but it’s how it’s able to do what it does.
显然，Twitter的真正挑战实际上并不 在于其所要做的 ，而在于它如何做自己的事 。
Twitter has the unique challenge of serving requests from approximately 500 million users every single day.
Twitter面临着一个独特的挑战，即每天要满足大约5亿用户的请求。
The hard problem that Twitter solves is actually a performance problem.
Twitter解决的难题实际上是性能问题 。
When the challenge is performance, whether or not we use a strictly typed language is much less important.
当挑战是性能时，是否使用严格类型的语言就不那么重要了。
2.嵌入式系统问题 (2. The Embedded System Problem)
An embedded system is a combination of computer hardware and software, with the purpose of enabling control over the mechanical or electrical aspects of a system.
嵌入式系统是计算机硬件和软件的组合，其目的是能够控制系统的机械或电气方面。
Most systems we use today are built on a very complex layer of code that, if not initially written in, compiles down to C or C++ usually.
我们今天使用的大多数系统都是建立在非常复杂的代码层上的，即使最初没有编写，通常也可以编译为C或C ++。
Coding in these languages is not for the faint of heart.
使用这些语言进行编码并不适合胆小者。
In C, there is no such thing as objects; and we as humans like objects because we can easily understand them. C is procedural and this makes the code that we have to write in this language more challenging to keep clean. These problems also require knowledge of the lower-level details.
在C语言中，没有对象。 我们作为人类喜欢物体，因为我们可以轻松地理解它们。 C是程序性的，这使我们必须用这种语言编写的代码更具挑战性，以保持简洁。 这些问题还需要了解底层细节。
C++ does make life a whole lot better because it has object orientation, but the challenge is still fundamentally interacting with lower-level hardware details.
C ++确实具有面向对象的特性，确实使生活变得更加美好，但是挑战仍然是从根本上与底层硬件细节进行交互。
Because we don’t really have that much of a choice on the languages we use for these problems, so it’s irrelevant to consider TypeScript here.
因为我们在用于这些问题的语言上确实没有太多选择，所以在这里考虑TypeScript无关紧要。
3.复杂领域问题 (3. The Complex Domain Problem)
For some problems, that challenge is less about scaling in terms of handling more requests, but scaling in terms of the codebase’s size.
对于某些问题，这个挑战不是在处理更多请求方面进行扩展，而是在代码库的大小方面进行扩展。
Enterprise companies have complex real-life problems to be solved. In these companies, the biggest engineering challenges are usually:
企业公司需要解决复杂的现实生活中的问题 。 在这些公司中，最大的工程挑战通常是：
Being able to logically (domains) separate parts of that monolith into smaller apps. And then, physically (microservices for bounded contexts) splitting them up so that teams can be assigned to maintain them
能够在逻辑上 (领域)将整体的各个部分分成较小的应用程序。 然后，在物理上 (用于有限上下文的微服务)将它们拆分，以便可以分配团队来维护它们
- Handling integration and synchronization between these apps 处理这些应用之间的集成和同步
- Modeling the domain concepts and actually solving the problems of the domain 建模领域概念并实际解决领域问题
Creating a ubiquitous (all-encompassing) language to be shared by developers and domain experts
创建一种无所不在 (无所不包)的语言，以供开发人员和领域专家共享
- Not getting lost in the mass amounts of code written and slowing down to the point where it becomes impossible to add new features without breaking existing ones 不会丢失大量已编写的代码，并且速度变慢到无法在不破坏现有功能的情况下添加新功能的地步
I’ve essentially described the types of problems that Domain-Driven Design solves. For these types of projects, you wouldn’t even think about not using a strictly-typed language like TypeScript.
我已经基本上描述了域驱动设计解决的问题类型。 对于这些类型的项目，您甚至都不会考虑不使用像TypeScript这样的严格类型的语言。
面向对象JavaScript (Object-oriented JavaScript)
For Complex Domain problems, if you don’t choose TypeScript and instead, choose JavaScript, it will require some extra effort to be successful. Not only will you have to be extra comfortable with your object modeling abilities in vanilla JavaScript, but you’ll also have to know how to utilize the 4 principles of object-oriented programming (encapsulation, abstraction, inheritance, and polymorphism).
对于复杂域问题，如果您不选择TypeScript，而是选择JavaScript，则需要付出额外的努力才能成功。 您不仅必须特别熟悉香草JavaScript中的对象建模能力，而且还必须知道如何利用面向对象编程的4个原理(封装，抽象，继承和多态性)。
This can be hard to do. JavaScript doesn’t naturally come with concepts of interfaces and abstract classes.
这可能很难做到 。 JavaScript自然不带有接口和抽象类的概念。
“Interface Segregation” from the SOLID design principles isn’t easily achievable with vanilla JavaScript.
使用原始JavaScript很难实现SOLID设计原则中的“接口隔离”。
Using JavaScript alone would also require a certain level of discipline as a developer in order to keep the code clean, and this is vital once the codebase is sufficiently large. You’re also left to ensure that your team shares the same discipline, experience and knowledge level on how to implement common design patterns in JavaScript. If not, you’ll need to guide them.
为了保持代码干净，单独使用JavaScript还需要一定程度的开发人员纪律，这在代码库足够大时至关重要。 您还需要确保您的团队就如何在JavaScript中实现常见的设计模式具有相同的学科，经验和知识水平。 如果没有，您将需要指导他们。
In Domain-Driven projects like this, the strong benefit from using a strictly typed language is less about expressing what can be done, but more about using encapsulation and information hiding to reduce the surface area of bugs by limiting what domain objects are actually allowed to do.
在像这样的域驱动项目中，使用严格类型的语言的最大好处不是表达可完成的事情 ，而是更多地使用封装和信息隐藏来通过限制实际上允许使用哪些域对象来减少错误的产生。做 。
We can live without this on the front-end, but it’s a hard language requirement for the backend in my books. It’s also the reason why I moved my Node.js backend services to TypeScript.
我们可以在前端没有这个，但是这是我书中后端对语言的一种硬性要求 。 这也是我将Node.js后端服务移至TypeScript的原因。
There’s a reason why TypeScript is called “JavaScript that scales”.
将TypeScript称为“ 可缩放JavaScript ”是有原因的。
Out of all three categories of hard software problems, only the Complex Domain Problem is the one where TypeScript is an absolute necessity.
在所有三类硬软件问题中，只有复杂域问题是TypeScript是绝对必要的问题。
Besides this, there are other factors that might determine when it’s best to use TypeScript for your JavaScript project.
除此之外，还有其他因素可能会决定何时最好在您JavaScript项目中使用TypeScript。
代码大小 (Code size)
Code size usually ties back to the Complex Domain Problem, where a large codebase means a complex domain, but that’s not always the case.
代码大小通常与复杂域问题有关 ，在复杂域问题中 ，大型代码库意味着复杂域，但并非总是如此。
When the amount of code a project has gets to a certain size, it becomes harder to keep track of everything that exists and becomes easier to end up re-implementing something already coded.
当项目的代码量达到一定大小时，就很难跟踪存在的所有内容，并且更容易最终重新实现已经编码的内容。
Duplication is the enemy to well-designed and stable software.
复制是精心设计且稳定的软件的敌人。
This is especially heightened when new developers start coding on an already large codebase.
当新开发人员开始在已经很大的代码库上进行编码时，这一点尤其突出。
Visual Studio Code’s autocompletion and Intellisense helps to navigate through huge projects. It works really well with TypeScript, but it’s somewhat limited with JavaScript.
Visual Studio Code的自动补全和Intellisense有助于导航大型项目。 它在TypeScript上确实可以很好地工作，但是在JavaScript上却受到一定的限制。
For projects that I know will stay simple and small, or if I know that it will be thrown away eventually, I would be less pressed to recommend TypeScript as a necessity.
对于我所知道的项目来说，它将保持简单而又小巧，或者如果我知道它最终将被丢弃，那么我就不那么推荐使用TypeScript了。
生产软件与宠物项目 (Production software vs. pet projects)
Production software is code that you care about or code that you’ll get in trouble for if it doesn’t work. This is also code that you’ve written tests for. The general rule of thumb is that “if you care about the code, you need to have unit tests for it”.
生产软件是您关心的代码，如果不起作用，则可能会遇到麻烦。 这也是您为其编写测试的代码。 一般的经验法则是“如果您关心代码，则需要对其进行单元测试”。
If you don’t care, don’t have tests.
如果您不在乎，请不要进行测试。
Pet projects are self-explanatory. Do whatever you like. You have no professional commitment to uphold any standards of craftsmanship whatsoever.
宠物项目是不言自明的。 做任何你喜欢的事。 您没有任何专业承诺来坚持任何Craft.io标准。
Go on and make things! Make small things, make big things.
继续做东西！ 做小事，做大事。
Maybe someday you’ll experience the pain when your pet project turns into your main project which turns into production software, which is buggy because it didn’t have tests or types ? not like I’ve been there or anything…
也许有一天，当您的宠物项目变成您的主项目而又变成生产软件时，您会感到痛苦，因为没有测试或类型，所以它变成了错误的玩具吗？ 不像我去过那里...
缺乏单元测试 (Lack of Unit Tests)
It’s not always possible to have tests for everything, because, well — life.
并非总是可以对所有事物都进行测试，因为生活就是如此 。
In that case, I’d say that if you don’t have Unit Tests, the next best thing you could have is compile-time checking with TypeScript. After that, if you’re using React, the next best is thing is to use runtime checking with Prop types.
在这种情况下，我想说的是，如果您没有单元测试，那么您可能拥有的下一个最佳选择就是使用TypeScript进行编译时检查。 之后，如果您使用的是React，那么下一个最好的选择就是对Prop类型使用运行时检查。
However, compile-time checking is not a substitute for having unit tests. The good thing is that unit tests can be written in any language — so the argument for TypeScript here is irrelevant. What’s important is that tests are written and we are confident about our code.
但是，编译时检查不能代替进行单元测试。 好的是，单元测试可以用任何语言编写-因此这里TypeScript的参数无关紧要。 重要的是要编写测试，并且我们对代码有信心。
初创企业 (Startups)
Definitely use whatever helps you be most productive.
绝对使用任何可以帮助您提高生产力的方法。
At this time, the language you choose matters a lot less.
目前，您选择的语言已不再重要。
The most important thing for you to do is to validate your product.
您要做的最重要的事情就是验证您的产品 。
Choosing a language (Java, for example) or a tool (like Kubernetes) that you heard would help you scale in the future (while being totally unfamiliar with it) may or may not be the best option in the case of a startup.
选择一种您所听到的语言(例如Java)或一种工具(例如Kubernetes)可以帮助您在将来扩展(完全不熟悉它)，对于初创企业而言，它可能不是最佳选择。
Depending on how early you are, the most important thing for you to do is to be productive.
根据您的年龄，您要做的最重要的事情就是提高工作效率。
In Paul Graham’s famous article, The Python Paradox, his main point is that startup engineers should just use the technology that maximizes their productivity.
在保罗·格雷厄姆(Paul Graham)的著名文章《 Python悖论》中 ，他的主要观点是，初创工程师应该只使用能够最大化其生产力的技术。
Overall, in this case, use whatever you’re most comfortable with: types or no types. You can always refactor towards a better design once you know you’ve built something people actually want.
总体而言，在这种情况下，请使用最适合的类型：类型或不使用类型。 一旦知道自己已经构建了人们真正想要的东西，就可以始终将其重构为更好的设计。
团队合作 (Working on Teams)
Depending on the size of your team and the frameworks you’re using, using TypeScript might be a make or break kind-of-thing.
根据团队的规模和所使用的框架的不同，使用TypeScript可能会成败。
大团队 (Large teams)
When teams are sufficiently large (because the problems are sufficiently large), it’s a good reason to use an opinionated framework, like Angular for the front-end, and TypeScript for the backend.
当团队规模足够大时(因为问题足够大)，这是一个使用自以为是的框架的充分理由，例如Angular用作前端，TypeScript用作后端。
The reason why using an opinionated framework is beneficial is because you limit the number of possible ways for people to accomplish something. In Angular, there’s pretty much one main way to add a Route Guard, use Dependency Injection, hook up Routing, Lazy-Loading, and Reactive Forms.
使用有思想的框架之所以有益的原因是，因为您限制了人们完成某件事的可能方式的数量。 在Angular中，几乎有一种主要的方法来添加Route Guard，使用依赖注入，连接路由，延迟加载和响应式表单。
The huge benefit here is that the API is well specified.
这里的巨大好处是API的指定正确。
With TypeScript, we also save massive amounts of time and make communication efficient.
使用TypeScript，我们还可以节省大量时间并提高通信效率。
The ability to quickly determine the required arguments and its return type for any method, or the ability to explicitly describe program intent through public, private, and protected variables alone is incredibly useful.
快速确定任何方法所需的参数及其返回类型的能力，或者仅通过公共，私有和受保护的变量显式描述程序意图的能力就非常有用。
Yes, some of this is possible with JavaScript, but it’s hacky.
是的，使用JavaScript可以实现其中的某些功能，但是它很hacky。
交流模式并实施设计原则 (Communicating patterns & implementing design principles)
Not only that, but design patterns, the solutions to commonly occurring problems in software, are more easily communicated through explicit strictly-typed languages.
不仅如此， 设计模式 (软件中常见问题的解决方案)还可以通过明确的严格类型化的语言轻松传达。
Here’s a JavaScript example of a common pattern. See if you can identify what it is.
这是常见模式JavaScript示例。 看看是否可以识别它是什么。
class AudioDevice {
constructor () {
this.isPlaying = false;
this.currentTrack = null;
}
play (track) {
this.currentTrack = track;
this.isPlaying = true;
this.handlePlayCurrentAudioTrack();
}
handlePlayCurrentAudioTrack () {
throw new Error(`Subclasss responsibility error`)
}
}
class Boombox extends AudioDevice {
constructor () {
super()
}
handlePlayCurrentAudioTrack () {
// Play through the boombox speakers
}
}
class IPod extends AudioDevice {
constructor () {
super()
}
handlePlayCurrentAudioTrack () {
// Ensure headphones are plugged in
// Play through the ipod
}
}
const AudioDeviceType = {
Boombox: 'Boombox',
IPod: 'Ipod'
}
const AudioDeviceFactory = {
create: (deviceType) => {
switch (deviceType) {
case AudioDeviceType.Boombox:
return new Boombox();
case AudioDeviceType.IPod:
return new IPod();
default:
return null;
}
}
}
const boombox = AudioDeviceFactory
.create(AudioDeviceType.Boombox);
const ipod = AudioDeviceFactory
.create(AudioDeviceType.IPod);If you guessed Factory Pattern, you’re right. Depending on your familiarity with the pattern, it might not have been that obvious to you.
如果您猜到Factory Pattern ，那么您是对的。 根据您对模式的熟悉程度，对您来说可能并不那么明显。
Let’s look at it in TypeScript now. Look at how much more intent we can signify about AudioDevice in TypeScript.
现在让我们在TypeScript中查看它。 看看我们可以在TypeScript中表示更多关于AudioDevice的意图。
abstract class AudioDevice {
protected isPlaying: boolean = false;
protected currentTrack: ITrack = null;
constructor () {
}
play (track: ITrack) : void {
this.currentTrack = track;
this.isPlaying = true;
this.handlePlayCurrentAudioTrack();
}
abstract handlePlayCurrentAudioTrack () : void;
}Immediate improvements
立即改善
We know the class is abstract right away. We needed to sniff around in the JavaScript example.
我们知道这堂课马上是抽象的。 我们需要在JavaScript示例中四处寻找。
AudioDevice can be instantiated in the JavaScript example. This is bad, we intended AudioDevice to be an abstract class. And abstract classes shouldn’t be able to be instantiated, they’re only meant to be subclassed and implemented by concrete classes. This limitation is set in place correctly in the TypeScript example.
可以在JavaScript示例中实例化AudioDevice 。 这很糟糕，我们希望AudioDevice成为抽象类。 而且抽象类不应被实例化，它们只能由具体类进行子类化和实现。 在TypeScript示例中正确设置了此限制。
- We’ve signaled the scope of the variables. 我们已经指出了变量的范围。
In this example, currentTrack refers to an interface. As per the Dependency Inversion design principle, we should always depend on abstractions, not concretions. This isn’t possible in the JavaScript implementation.
在此示例中， currentTrack引用一个接口。 根据依赖倒置 设计原则，我们应该始终依赖抽象，而不是混凝土。 这在JavaScript实现中是不可能的。
We’ve also signaled that any subclasses of AudioDevice will need to implement the handlePlayCurrentAudioTrack themselves. In the JavaScript example, we exposed the possibility for someone to introduce runtime errors trying to execute the method from either the illegal abstract class or the non-complete concrete class implementation.
我们还发出信号， AudioDevice的任何子类都需要自己实现handlePlayCurrentAudioTrack 。 在JavaScript示例中，我们暴露了有人引入运行时错误，试图从非法抽象类或非完整具体类实现中执行该方法的可能性。
Takeaway: If you work on a large team and you need to minimize the potential ways someone could misuse your code, TypeScript is a good way to help fix that.
要点：如果您在一个大型团队中工作，并且需要最小化某人可能滥用您的代码的潜在方式，那么TypeScript是帮助解决此问题的好方法。
较小的团队和编码风格 (Smaller teams & coding styles)
Smaller teams are a lot easier to manage coding styles and communication. Paired with linting tools, frequent discussions about how things will get done and pre-commit hooks, I think small teams can be really successful without TypeScript.
较小的团队更容易管理编码样式和沟通。 结合使用整理工具，经常讨论如何完成工作和预先提交钩子，我认为没有TypeScript的小型团队确实可以成功。
I think that success is an equation involving the size of the codebase and the size of the team.
我认为成功是一个涉及代码库规模和团队规模的方程式。
As the codebase grows, the team might find that they need to rely on some help from the language itself to remember where things are and how they should be.
随着代码库的增长 ，团队可能会发现他们需要依靠语言本身的帮助来记住事物的位置和方式。
As the team grows, they might find they need more rules and restrictions to keep the style consistent and prevent duplicate code.
随着团队的成长 ，他们可能会发现他们需要更多的规则和限制来保持样式一致并防止重复代码。
构架 (Frameworks)
React和角度 (React & Angular)
Much of what draws me and other developers to React is the ability to write code however you want and in an elegant/clever way.
使我和其他开发人员着迷于React的大部分原因是能够以自己想要的方式并且以优雅/巧妙的方式编写代码。
It’s true that React makes you a better JavaScript developer because it forces you to approach problems differently, it forces you to be aware of how this binding in JavaScript works and enables you to compose large components out of small ones.
的确，React使您成为了更好JavaScript开发人员，因为它迫使您以不同的方式处理问题，它使您意识到JavaScript中的这种绑定是如何工作的，并使您能够从小组件中组合出大组件。
React also allows you to have a bit of your own style. And because of the number of ways I can implement any given task, I will most often write vanilla React.js apps when:
React还可以让您拥有自己的风格。 而且由于可以执行任何给定任务的方式多种多样，因此在以下情况下，我通常会编写原始的React.js应用程序：
- the codebase is small 代码库很小
- it’s just me coding it 只是我编码而已
And I will compile it with TypeScript when:
在以下情况下，我将使用TypeScript进行编译：
- more than 3 people are coding it, or 超过3个人正在编码，或者
- the codebase is expected to be very large 代码库预计会很大
I will also optionally use Angular for the same reason I will compile React with TypeScript.
我也将选择使用Angular，其原因与我将使用TypeScript编译React的原因相同。
结论 (Conclusion)
In conclusion, these are my personal opinions on when TypeScript is absolutely necessary and I welcome you to disagree with any of it.
总之，这些是我对何时绝对必要使用TypeScript的个人看法，我欢迎您不同意其中的任何一种。
This is what has worked for me in the past when deciding whether or not to use TypeScript. However, today, since I’ve seen the light, it’s not much more effort for me to use TypeScript over vanilla JavaScript as I’m equally comfortable with both and would prefer the type safety.
过去，这在决定是否使用TypeScript时对我有用。 但是，今天，由于看到了光线，使用TypeScript而不是使用普通JavaScript不需要花费太多精力，因为我对两者都感到满意，并且更喜欢类型安全性。
My final points here are:
我的最后一点是：
您可以随时逐步开始使用TypeScript (You can always gradually start using TypeScript)
Start gradually by adding TypeScript and ts-node to your package.json and utilizing the allowjs: true, option in your tsconfig file.
首先将TypeScript和ts-node添加到package.json并利用tsconfig文件中的allowjs：true选项开始。
This is how I migrated all of my Node.js apps over time to TypeScript.
这就是我随着时间的推移将所有Node.js应用程序迁移到TypeScript的方式。
编译时错误比运行时错误更好 (Compile time errors are better than runtime ones)
You can’t argue with that. If catching bugs in production code is especially important to you, TypeScript will help you minimize a lot of these.
你不能与此争论。 如果捕获生产代码中的错误对您尤为重要，TypeScript将帮助您最大程度地减少这些错误。
如果您有能力学习它，请学习它。 它为您的软件设计技能带来了奇迹 (If you are in a position to learn it, learn it. It does wonders for your software design skills)
Depending on where you are in your life and your career, you might not have the time to learn it. If you do have the time, I’d recommend you start learning it and start learning about SOLID design principles and software design patterns. This is the fastest way to level up as a Junior Developer in my honest opinion.
根据您的生活和职业状况，您可能没有时间去学习它。 如果您有时间，建议您开始学习，并开始学习SOLID设计原则和软件设计模式 。 在我看来，这是升级为初级开发人员的最快方法 。
I hope this article was useful to you! Are you considering using TypeScript on your next project? Let me know if you agree/disagree in the comments.
希望本文对您有所帮助！ 您是否正在考虑在下一个项目中使用TypeScript？ 让我知道您是否同意评论。
了解企业TypeScript和JavaScript (Learn Enterprise TypeScript & JavaScript)
Essential software development patterns, principles, and tutorials with modern JavaScript and TypeScript.
使用现代JavaScript和TypeScript的基本软件开发模式，原理和教程。
Originally published April 6th @ khalilstemmler.com.
最初发表于4月6日 @ khalilstemmler.com 。
typescript ?:
305
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
