typescript重要吗_TypeScript，WTF吗？

typescript重要吗

If you hang around in the JavaScript community, along with left-pad you almost have certainly heard of TypeScript. Having large frameworks, like Angular 2 and EmberJS embrace it have given it a lot of focus. I would like to think too, that Dojo 2 being built on TypeScript adds something to the conversation and I would like to explain in part why you might want to spend time getting to understand TypeScript as well.

如果您在JavaScript社区流连，沿着left-pad你几乎一定听说过打字稿的。 拥有大型框架(例如Angular 2和EmberJS)已经为它提供了很多关注。 我也想考虑一下，基于TypeScript构建的Dojo 2在对话中增加了一些东西，我想部分解释为什么您可能还想花一些时间来理解TypeScript。

微软，布莱尔 (Microsoft, Bleurgh)

I remember hearing the announcement of TypeScript from Microsoft and immediately dismissed it. I generally did that with most things from Microsoft. They were in my eyes, like a lot of large software enterprises, a good place to crush innovation and focus on brand and marketing. At the time, I was a fairly senior IT manager by day, and closet Dojo committer by night. I had an endless stream of software companies who had solutions to my problems, no matter what my problem was and on the surface, I thought TypeScript was another way to tie enterprises into a Microsoft roadmap.

我记得听到Microsoft发布TypeScript的公告，并立即将其取消了。 我通常使用Microsoft的大多数功能来执行此操作。 在我看来，它们就像许多大型软件企业一样，是粉碎创新并专注于品牌和营销的好地方。 当时，我白天是相当资深的IT经理，晚上是壁橱Dojo的提交人。 无论我遇到什么问题，从表面上看，我都有无数的软件公司为我的问题提供解决方案，我认为TypeScript是将企业与Microsoft路线图联系起来的另一种方法。

I was totally wrong.

我完全错了。

粉丝时刻 (Fanboy Moment)

Part of the understanding of why TypeScript is different, in my opinion, I have to self a bit of fanboyness for a moment. Anders Hejlsberg. As I started to look into TypeScript, I realised that name was vaguely familiar. In the late 80s and early 90s, I was using Turbo Pascal and when Delphi came out, I migrated to it. I loved it and often preached the religion of Delphi to whomever might listen. Direct programming started to become less and less relevant to my day job, but Delphi was my safety language whenever I wanted to hack something together myself. I remember the day when I heard that "big ole mean" Microsoft had "stolen" the core of Delphi from Borland to work for Microsoft.

在我看来，部分理解TypeScript为何不同的原因是，我不得不稍作自我幻想。 安德斯·海斯伯格。 当我开始研究TypeScript时，我意识到这个名字有点陌生。 在80年代末和90年代初，我使用了Turbo Pascal，当Delphi出现时，我迁移到了它。 我喜欢它，经常向任何可能听到的人宣讲德尔斐的宗教。 直接编程开始变得与我的日常工作越来越不相关，但是无论何时我想自己动手，Delphi都是我的安全语言。 我记得有一天，我听说微软“大胆地指责”微软从Borland“窃取”了Delphi的核心，为Microsoft工作。

Of course a few years later, I started hearing about C# and I dismissed it as a "Delphi ripoff" at first, but slowly, it seemed to evolve and actually go beyond what Delphi helped bring to the world. Of course, a large part of C# owes its existence to Anders.

当然，几年后，我开始听到有关C＃的信息，一开始我将其视为“ Delphi窃取”，但慢慢地，它似乎在发展，实际上超出了Delphi带来的范围。 当然，C＃的很大一部分归功于Anders。

When I made the connection that Anders vision (and code) were large parts of Turbo Pascal, Delphi, C#, and now TypeScript, that made me excited.

当我建立联系时，Anders的愿景(和代码)是Turbo Pascal，Delphi，C＃和现在的TypeScript的重要组成部分，这让我激动。

它不漂亮，但这就是我们所拥有的 (It Ain’t Pretty, But It’s All We Got)

I don’t really think there are many, if any, JavaScript developers wake up in the morning and say "I am really glad I work with JavaScript, it is such a wonderful language." Brenden Eich often finds himself as chief JavaScript apologist. JavaScript is a perfect example of the Law of Unintended Consequences. It has exploded though, for lots of various reasons. Even with huge detractors and critiques, it is a reality that cannot be denied.

我真的不认为有很多JavaScript开发人员会在早上醒来，并说：“我很高兴我使用JavaScript，这是一种很棒的语言。” 布伦登·艾希(Brenden Eich)经常发现自己是首席JavaScript辩护律师。 JavaScript是意外后果定律的完美示例。 但是，由于多种原因，它爆炸了。 即使存在巨大的批评和批评，这也是不可否认的现实。

Maybe it could be compared to English, it isn’t a perfect language, it has lots of broken parts, a load of dialects of which only a subset of the language could be considered "globally understood" and many many people don’t really use it all that well. The universal language should have been well thought out and far more rational and organised, but I don’t speak Esperanto, do you? We are not going to get rid of English.

也许可以将其与英语进行比较，它不是一种完美的语言，它包含很多残缺的部分，大量的方言，其中只有一部分语言可以被视为“全球范围内的理解”，而许多人并没有真正很好地利用它。 通用语言应该经过深思熟虑，更加理性和井井有条，但是我不会说世界语，对吗？ 我们不会放弃英语。

But what if we could add some markup for English, so we could organise our language a bit better? You could take English and optionally apply some rules to it. Maybe something like markdown even, that allows you put things like headings and hyperlinks and code blocks, all the while not breaking the underlying language? Sounds good, well that is TypeScript.

但是，如果我们可以为英语添加一些标记，以便我们可以更好地组织语言，该怎么办？ 您可以选择英语，并可以选择应用一些规则。 也许甚至是markdown之类的东西，它允许您放置标题 ， 超链接和代码块之类的东西 ，而同时又不会破坏底层语言？ 听起来不错，这就是TypeScript。

我不明白 (I Don’t Understand)

The flexibility and unstructured nature of JavaScript made it "easy" to code, but it never was easy to scale. Scale in large complex maintainable code bases, scale in the ability for people to understand the code, scale in others using your code. The whole way the web works today is through extension and interaction and the biggest roadblock to that is understanding intent.

JavaScript的灵活性和非结构化性质使其“易于”编写代码，但从未如此容易扩展。 扩展大型复杂的可维护代码库，扩展人们理解代码的能力，扩展使用您的代码的其他代码。 当今网络的整个工作方式都是通过扩展和交互，而最大的障碍是理解意图。

The first step was to stop writing JavaScript code inline in our HTML markup and breaking it out into separate files we could maintain, creating functions:

第一步是停止在HTML标记中内联编写JavaScript代码，并将其分解为我们可以维护的单独文件，并创建函数：

function myGreatApi(options) {
  /* Hopefully no one needs to read this */
}

Ok, that is great, but I would still have to write up some documentation, so someone could use my code. So maybe we could agree on something like JSDoc:

好的，那很好，但是我仍然必须编写一些文档，以便有人可以使用我的代码。 因此，也许我们可以就JSDoc之类达成共识：

/**
 * My Great API does something great, just use it
 * @param   {Object} options Some options I need...
 * @returns {Object}         The results of my great API
 */
function myGreatApi(options) {
  /* Hopefully no one needs to read this */
}

Ok, that is better, but what if I wanted options to be optional? What if I wanted to express what properties I expected in options? How do I describe what the return value is a bit better… I could in theory add this all to really complex JSDoc, but that isn’t really maintainable and it isn’t actually enforced (though things like Closure Compiler can give me hints that I might be abusing it). What if there was some way of describing this in a way that could allow someone else just consume this without know a huge amount about it?

好的，那更好，但是如果我希望options是可选的怎么办？ 如果我想表达我希望在options什么特性怎么办？ 我该如何描述返回值会更好一点……从理论上讲，我可以将所有这些都添加到真正复杂的JSDoc中，但这并不是真正可维护的，也没有真正执行(尽管Closure Compiler之类的东西可以给我提示我可能会滥用它)。 如果有某种描述方式，可以让其他人在不了解它的情况下就直接使用它，该怎么办？

interface MyGreatApiOptions {
  /**
   * The URL target for my API
   */
  target: string;

  /**
   * Translate from one language to another
   */
  translate?: boolean;
}

interface MyGreatApiResult {
  /**
   * The headers returned from the request
   */
  headers: { [header: string]: string };

  /**
   * The response
   */
  response: string;
}

/**
 * My Great API does something great, just use it
 * @param options Some options I need, maybe, if you want
 */
function myGreatApi(options?: MyGreatApiOptions): MyGreatApiResult {
  /* now, no one has to read this */
}

Now, not only do I have a completely documented API, it is enforceable at compile time and it many IDEs, code completion is available, so a developer can receive real time insight into how the APIs are consumed.

现在，我不仅拥有完整的文档化API，而且在编译时可以执行，并且具有许多IDE，并且可以完成代码，因此开发人员可以实时了解API的使用方式。

I have found that TypeScript allows me to not only explain my APIs to others, it helps me structure my code and requires me to remember less about the code I have written, focusing on writing productive code and less time reading and re-reading code I had already written.

我发现TypeScript不仅使我能够向其他人解释我的API，还可以帮助我构建代码，并要求我减少有关已编写代码的记忆，专注于编写高效的代码，减少阅读和重新阅读代码的时间已经写过了。

开放性 (Openness)

One of the best things about TypeScript is its openness and transparency. It is a first class Open Source project. The team have not only open sourced the TypeScript compiler, they continue to raise the standard and pressure the rest of Microsoft to find ways to open source the tools that they rely open. For example, the tool that builds the browser library definitions has been open sourced. Also, the intelligence that they used to create the in browser editor was released as part of the open sourcing Visual Studio Code.

关于TypeScript的最好的事情之一就是它的开放性和透明性。 这是一流的开源项目。 该团队不仅开放了TypeScript编译器的源代码，而且还在继续提高标准并向Microsoft的其他部门施加压力，要求他们找到开放其所依赖的工具的源代码。 例如，构建浏览器库定义的工具已开源 。 同样，他们用于创建浏览器中编辑器的智能也作为开源Visual Studio Code的一部分发布。

钩 (Hook)

Developers are a needy bunch and TypeScript being developed in the open means that people can often express those needs.

开发人员是一个有需要的人，而TypeScript的公开开发意味着人们经常可以表达这些需求。

Also, sometimes developers confuse open source with democracy. Open source is about being open, allowing people to see your code and your development process and being transparent about what decisions you make and why. It doesn’t mean because you "really need" something that it will be included. TypeScript has articulated their design goals, which is great reference point for making decisions about the direction of the language.

此外，有时开发人员会将开源与民主相混淆。 开源是开放的，它使人们可以看到您的代码和开发过程，并且可以透明地了解您做出的决定以及原因。 这并不意味着因为您“确实需要”将包含在内的某些东西。 TypeScript阐明了他们的设计目标 ，这是做出有关语言方向决策的重要参考。

TypeScript doesn’t (yet) have the concept of plugin transformations, which differs it from the likes of Babel. I can see how such functionality could very well satiate needy developers, I can almost see it being a foot-gun for a language that is trying its best to help developers not write "bad" code. Already we are seeing in the Babel community poorly written and maintained transforms that cause all sorts of carnage and problems.

TypeScript还没有插件转换的概念，这与Babel的概念有所不同。 我可以看到这样的功能如何很好地满足需要帮助的开发人员的需要，我几乎可以看到它是一种语言的步枪，它正在尽最大努力帮助开发人员避免编写“不好的”代码。 在Babel社区中，我们已经看到书写不当和维护不善的转换会导致各种屠杀和问题。

TypeScript is still relatively "young" and therefore it is growing daily, but in my opinion it has largely grown under really good stewardship and in the right directions. There are some significant changes coming in TypeScript 2.0 that continue to deliver on the promise of making JavaScript scale. This includes a whole rewrite of the way types are analysed in the flow of the code and an opt-in feature that starts to deal with logic errors around the flexibility of things being undefined or null in JavaScript.

TypeScript仍相对“年轻”，因此每天都在增长，但我认为它在很大程度上是在非常好的管理和正确的方向上增长的。 TypeScript 2.0中发生了一些重大更改，这些更改继续兑现了使JavaScript扩展的承诺。 这包括对代码流中的类型分析方式的整体重写，以及一个可选功能，该功能开始处理围绕JavaScript中undefined或为null的事物的灵活性的逻辑错误。

Given the youth though, TypeScript is still mature beyond its years. By being a superset of JavaScript, it isn’t reinventing the wheel, it is building on top of the language that, for good or bad, powers the web. Coupled with those being involved having a depth of experience in language construction and drawing upon the experience of everyone else by being open has really accelerated it to being ready for production now.

尽管年轻，但TypeScript仍然成熟。 通过成为JavaScript的超集，它并没有改变发明的方向，它是建立在为网络提供动力的语言之上的，无论其好坏。 再加上参与其中的人员具有丰富的语言构建经验，并通过开放获取其他所有人的经验，确实将其加速为现在的生产做好了准备。

最后... (Finally...)

So, if you haven’t taken a look at TypeScript, I have hopefully convinced you that it is something to at least worth a bit of your time. I personally believe it is part of a major cultural shift at Microsoft, but even if that isn’t important to your, it can be judged wholly on its own merits. It has some of the best minds focused on making JavaScript scale and the team is going about it in a way that is open and transparent. By embracing the reality of JavaScript and building on top of it, in my opinion TypeScript is transforming the common language of the web, for the better.

因此，如果您没有看过TypeScript，我希望您会说服您，这至少值得您花一些时间。 我个人认为这是Microsoft重大文化转变的一部分，但是即使这对您并不重要，也可以完全根据其优点来判断。 它有一些最好的头脑专注于使JavaScript扩展，并且团队正在以开放和透明的方式进行开发。 在我看来，TypeScript通过拥抱JavaScript的现实并在其之上进行构建，从而使Web的通用语言变得更好。

翻译自: https://davidwalsh.name/typescript

typescript重要吗