Anders Hejlsberg and Lars Bak: TypeScript, JavaScript, and Dart

Anders Hejlsberg与Lars Bak论道：TypeScript、JavaScript与Dart 在微软公开宣布TypeScript的次日录制，语言架构师Anders Hejlsberg与Lars Bak就解决现代Web开发可扩展性及工具链挑战对比了各自竞争的设计理念。Hejlsberg将TypeScript定位为JavaScript的人体工学与实用超集，仅在编译阶段引入可选静态类型并对齐ECMAScript 6，而不改变运行时语义或破坏生态兼容性。Bak则主张Dart的全新设计，认为遗留的JavaScript语义、缓慢的标准化进程以及动态执行陷阱，决定了必须采用固定对象布局、原生整数语义、全程序摇树优化（tree shaking）以及专用的高性能虚拟机，方能跟上专有移动平台的步伐。尽管在Web究竟需要激进的运行时变革还是透明的工具链层面上存在分歧，两位创造者均认同可选类型对于大型工程团队至关重要，并倡导Web平台上的开源多样性。 微软推出了开源的TypeScript，作为JavaScript的真正超集，具备可选的静态类型，可编译为简洁的JavaScript并与ECMAScript 6草案保持一致。 (0:00) Google的Dart采用全新设计的语言模型，具有固定对象形态、原生整数以及可选的专用虚拟机，旨在绕过JavaScript固有的启动和运行时瓶颈。 (2:00) Anders Hejlsberg和Lars Bak认为，企业级Web的可扩展性、代码可维护性以及工具链的不足，是促成TypeScript与Dart共同诞生的诱因。 (4:58) 两者的根本设计分歧在于运行时语义：TypeScript纯粹作为设计期的静态分析运行，完全没有运行时开销；而Dart则强制推行结构化语义，从而支持激进的全程序摇树优化与运行时校验。 (20:51)

Anders Hejlsberg and Lars Bak outline contrasting architectural visions for scaling web applications: Microsoft's TypeScript serves as a purely static, erasable superset designed to embrace JavaScript's existing ecosystem, while Google's Dart provides a clean-slate language and runtime to bypass fundamental engine bottlenecks. Superset Tooling Versus Clean-Slate Runtime Architecture (2:00) Hejlsberg explains that TypeScript begins and ends with JavaScript, acting as a strict superset that adds optional static typing, modules, and classes aligned with evolving ECMAScript 6 drafts. By erasing types during compilation and avoiding any runtime virtual machine overhead, TypeScript lets developers migrate existing codebases incrementally while leveraging third-party libraries like jQuery and Node.js without semantic friction. Hejlsberg argues that messiness is an unavoidable characteristic of widely adopted technologies, making ecosystem compatibility paramount. In contrast, Bak contends that compiling to standard JavaScript inherits the platform's core runtime flaws, such as top-level initialization penalties and slow startup times caused by a lack of static declarative structures. Dart was engineered from scratch with Smalltalk-inspired semantics, fixed object layouts, and native integer operations, avoiding the dynamic property mutation and floating-point emulation that cause engine de-optimizations in V8 and Chakra. While Dart can cross-compile to JavaScript, Bak stresses that a dedicated virtual machine is necessary to achieve predictable speed and lower memory usage. Runtime Type Verification and Component Boundary Failures (26:20) The two architects diverge significantly on whether type safety should persist at runtime. Bak emphasizes that Dart reifies type information, enabling checked mode during development to validate interface contracts when data crosses module boundaries between teams. Under this model, missing properties or incorrect method calls trigger immediate exceptions, rejecting JavaScript’s traditional practice of silently evaluating missing properties to undefined and continuing execution. Hejlsberg counters that injecting dynamic runtime checks into JavaScript output is prohibitively expensive, as validating arbitrary objects requires traversing nested properties and checking signature shapes at runtime. Because JavaScript is memory-safe and cannot crash underlying machine memory when called with mismatched arguments, Hejlsberg argues that static compile-time checking captures 80 to 90 percent of necessary developer guardrails without degrading browser execution performance. Whole-Program Analysis and Dead-Code Elimination (34:34) Bak identifies startup download size as an urgent performance crisis for web applications, pointing out that modern websites routinely download thousands of functions during load but execute only a small fraction of them. Because Dart enforces language-level structural discipline across the entire program, its compiler can trace call graphs downward from known entry points—such as main functions or DOM event hooks—and safely discard unreferenced methods through whole-program tree shaking. Hejlsberg observes that while TypeScript integrates into broader toolchains alongside minifiers and bundlers, safe whole-program pruning remains virtually impossible once unconstrained third-party JavaScript libraries are introduced. Because standard JavaScript allows arbitrary dynamic bracket access like computing property names at runtime, optimizers cannot soundly prove whether an unreferenced method might be invoked indirectly, creating semantic risks that Dart's controlled environment avoids. Standards Committee Evolution Versus Mobile Platform Threats (16:21) The debate reflects conflicting views on the web's governance timeline. Hejlsberg defends evolutionary standards alignment, arguing that TypeScript intentionally tracks TC39 decisions—such as adopting the committee's class syntax over Microsoft's earlier designs—and suggests future browser runtimes could introduce engine hints via pragmas like strict mode to optimize performance without breaking the web. Bak argues that waiting for standards committees is an unacceptable risk, recounting how ECMAScript 4 collapsed and left the industry trapped on ECMAScript 3 for years. He warns that unless web runtimes innovate rapidly with dedicated virtual machines and clean semantics, proprietary native mobile platforms will capture developer mindshare and surpass the browser, characterizing complete deference to backward compatibility as an engineering Stockholm syndrome. While TypeScript and Dart pursue divergent paths—one acting as a pragmatic static overlay for JavaScript and the other rethinking runtime architecture through a structured virtual machine—both creators commit to open-source distribution and agree that the web platform must support a diverse ecosystem of languages to manage large-scale enterprise development.

在TypeScript发布之际，其首席架构师Anders Hejlsberg与V8及Dart联合创建者Lars Bak就如何解决大规模Web开发痛点展开对谈：Hejlsberg主张以完全兼容JavaScript的超集与静态类型工具层来渐进演进；Bak则认为必须通过全新的语言语义、确定性运行时以及专属虚拟机来彻底克服JavaScript的架构缺陷。 超集工具层与全新语言运行时的分歧 (0:00) Hejlsberg将TypeScript定义为JavaScript的严格超集，其设计宗旨是与ECMAScript 6草案标准紧密对齐，引入可选静态类型、类、模块、箭头函数和剩余参数等特性。为了保护现有生态，TypeScript直接以JavaScript为起点，代码经过类型检查后重新转译为纯JavaScript，所有类型在运行时完全擦除，不引入额外的运行时开销或私有虚拟机。这使开发者能无缝复用DOM、Node.js及jQuery等庞大现有生态，获得自动补全、符号重命名和静态导航等IDE支持。 Bak则将TypeScript视作带有可选类型的安全渐进方案，但他认为这并未触及JavaScript的底层执行瓶颈。Dart选择从零构建全新的干净语义，配有专属的虚拟机，同时支持交叉编译至JavaScript。Bak指出，标准JavaScript缺乏静态声明结构，大型应用必须在启动时执行整个顶层脚本以完成初始化；而TypeScript由于编译目标仍是JavaScript引擎，无法从根本上消除这种冷启动损耗与执行机制固有的架构约束。 动态对象修补与确定性对象模型的抗衡 Bak从计算机科学工程视角对JavaScript环境的高动态性提出质疑，批评其允许在运行时任意“猴子补丁”（monkey patch）修改库，以及用IEEE 754双精度浮点数模拟整数运算的做法。他指出V8等现代引擎为了优化性能，必须借助隐藏类推断与启发式编译，一旦动态代码在侧向修改对象属性，热路径就会立即发生去优化（de-optimize），引发引擎元数据膨胀与性能断崖。因此，Dart借鉴Smalltalk的对象模型，强制要求对象实例化后具备固定布局（fixed shapes），并提供原生整数语义，以换取极高的执行确定性与内存控制力。 Hejlsberg对此承认JavaScript存在诸多历史缺陷，但强调庞大生态与用户基础的现实价值。他认为任何历经委员会长期演化的广泛技术都会伴随混乱，关键在于JavaScript是否真的“坏到必须被替换”的程度。随着V8与IE的Chakra等现代引擎技术取得突破，浏览器已能可靠承载数十万行代码的大型应用，因此TypeScript致力于提供静态类型系统来模拟JavaScript的动态语义，而不是强行推翻底层运行环境。 类型系统落地：设计期抹除对比运行时契约验证 两套体系均将可选类型视为可以在动态与静态间调节的“刻度盘”，但两者在边界验证上存在根本分歧。Dart在开发模式（checked mode）下保留具体化的运行时类型信息，当未类型化的动态代码向类型化接口传递非法对象时，系统会在模块边界立即抛出异常；同时Dart打破了JavaScript对拼写错误属性返回undefined并继续静默执行的惯例。Bak认为，严格的边界类型校验能让多团队协作开发时迅速定位接口破坏者，免除调试他人代码的负担。 Hejlsberg指出，TypeScript覆盖了类型刻度盘上80%至90%的高价值场景，重点解决多团队协同中跨库调用的契约缺失问题，建立通用的接口定义体系。但他直言，在原生JavaScript之上进行完整的运行时类型验证代价极其高昂，不仅需要递归检查对象属性结构，还要在运行时校验函数签名与参数数量。鉴于JavaScript本身具备内存安全性，参数数量不符不会像早期C语言那样引发内存损坏或崩溃，因此TypeScript坚持在编译后完全抹除类型，避免为应用强加性能惩罚。 代码裁剪与依赖分析的技术瓶颈 (32:54) 面对现代Web应用在启动时下载大量冗余函数却仅执行极小比例的体积膨胀问题，Bak强调全程序死码消除（tree shaking）是优化分发的关键。Dart通过自顶向下的完整程序结构，能从main入口或DOM事件钩子展开全程序类型推断，安全移除未被引用的标识符与方法，产出极为精简的JavaScript代码或虚拟机快照。Bak认为，一旦应用引入随意使用字符串动态属性访问（如obj[computedString]()）的标准JavaScript库，静态分析就无法健全证明可达性，使得彻底的树摇优化在混用生态中几乎不可能安全实施。 Hejlsberg回应称，TypeScript代码本身在理论上同样具备被分析与树摇的可能，并能自然嵌入由AMD/RequireJS、打包器和压缩器构成的现代工具链中。不过他也坦承，像jQuery这类包含复杂动态模式的第三方库确实难以被完全看透。TypeScript选择接受这一边界，将自身定位于提升开发期开发体验、静态验证与模块契约描述的工具层，而非全盘接管打包与部署运行时的封闭平台。 Web演进路线：渐进妥协与突破创新的路径竞争 (16:21) 对于Web技术的演进速度，Bak表达了强烈的紧迫感。他回顾了ECMAScript 4标准的夭折，指出尽管已有ECMAScript 5，大量生产代码多年间仍受困于ECMAScript 3；如果Web技术停滞在缓慢的委员会标准流程中，封闭的专有原生移动平台将会抢占开发者生态。Bak批评过度依恋既有环境相当于一种“斯德哥尔摩综合征”，重申当年开发V8时外界同样质疑过高性能引擎的必要性，唯有勇于从底层打造新系统与新语言，应用开发者才能获得真正的创新基础。 Hejlsberg则认为，JavaScript跨越各家竞争厂商的无与伦比的分发能力决定了渐进路线的必要性，并指出ECMAScript 5严格模式的普及证明了渐进优化的可行性，未来甚至可探索向引擎提供对象布局提示的更严格模式。尽管方法各异，双方均认同Web生态应走向多元化竞争，且两套方案均拥抱开源模式——Dart开放了专属虚拟机源码以供各平台自由采纳，TypeScript则在发布初期便脱离Visual Studio单一环境，向Vim和Emacs等开源社区编辑器提供跨平台支持。 本场对话揭示了Web平台扩展过程中的核心抉择：是以TypeScript为代表，承认JavaScript的既有生态与动态现实，通过编译期静态类型抹除与模块契约化来提升工程生产力；还是以Dart为代表，彻底重构语义与运行时虚拟机，用确定的对象模型消除启动延迟与动态损耗。两种路线反映了务实兼容与彻底技术革新在Web演进中的长久张力。

## Background 该视频由 YouTube 频道 DartlangTV 于 2013 年 1 月 10 日发布。视频记录了在丹麦奥胡斯举行的 GOTO 2012 大会期间，Channel 9 促成的 Lars Bak 与 Anders Hejlsberg 关于 Dart、TypeScript 和 JavaScript 的深度对谈。 ## TL;DR 在微软刚刚公开宣布 TypeScript 的背景下，TypeScript 架构师 Anders Hejlsberg 与 Dart 共同创始人 Lars Bak 展开了正面思想碰撞。双方探讨了应对大规模 JavaScript 开发困境的根本哲学分歧：TypeScript 选择作为 JavaScript 的严格超集，专注于可选静态类型与纯工具链赋能以兼容现有生态；Dart 则主张从零构建具备清晰语义的新语言并搭配专用 VM，追求极限运行时性能与可预测性。此外，两人深入对比了类型系统设计、运行时类型检查、摇树优化（Tree Shaking）以及标准演进速度，最终一致呼吁拥抱开源与多元共存，将技术选择权交还给开发者。 ## Atmosphere & style 对谈氛围兼具顶级架构师之间的学术严谨与老友重逢般的轻松幽默。两人既能在隐藏类去优化、猴子补丁以及类型擦除等底层细节上展开针锋相对的犀利交锋，又始终保持着对彼此工程造诣的高度敬重与惺惺相惜。整场讨论充满了快节奏的思想博弈与真知灼见，最终在对开源开放精神的共识和相视举杯的欢笑声中落幕，展现出科技大师对话特有的理性魅力。 ## Bulletin - [00:00](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=0s) TypeScript 架构师 Anders Hejlsberg 与 Dart 联合创始人 Lars Bak 在 GOTO 2012 大会上就 Web 语言的未来展开交锋，分别阐释了基于既有生态的兼容超集路线与打破历史包袱的自研 VM 变革路线。 - [01:14](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=74s) TypeScript 定位为 JavaScript 的严格超集，其核心语法（类、模块等）完全对齐当时的 ECMAScript 6 标准提案，并采用类型擦除机制以甘当现有前端工具链中的一环。 - [03:29](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=209s) Dart 从零构建全新语言语义与专用运行时，通过固定对象布局、支持整数类型以及全程序摇树优化（Tree Shaking），力求在启动速度和执行性能上实现可预测的突破。 - [40:53](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=2453s) 两位技术领袖一致认为开发者不应被束缚在单一语言中，Web 生态的多元化已是必然趋势，同时双方项目均坚持全栈开源以推动 Web 技术的自由发展。 ## Key takeaways - [00:00](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=0s) Lars Bak 初见 TypeScript 时将其比喻为带有可选类型的 CoffeeScript，认为其最终编译为 JavaScript 的做法是一笔非常稳妥的赌注。 - [01:14](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=74s) TypeScript 采取严格超集哲学，原生 JavaScript 代码可直接兼容，团队甚至推翻早期类设计以全面向 ES6 的 Max-Min 提案看齐。 - [03:29](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=209s) Dart 选择从零构建全新语义，摆脱 JavaScript 历史包袱，旨在通过专属 Dart VM 彻底突破执行瓶颈与冷启动开销。 - [04:49](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=289s) 在缺乏静态类型的大型复杂项目中，IDE 代码补全、重构与引用跳转极易沦为不可靠的猜测，推动了类型化工具链的诞生。 - [04:49](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=289s) TypeScript 通过外部类型声明文件（.d.ts）无缝兼容 jQuery、Node.js 等现有庞大生态，无须修改第三方库源码即可获得强类型支持。 - [11:16](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=676s) JavaScript 允许动态猴子补丁（monkey patch）且数值全为双精度浮点数，破坏了底层代码的不可变性与循环语义的严谨性。 - [14:13](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=853s) JavaScript 引擎依赖隐藏类推断结构，动态修改对象会导致昂贵的去优化（de-opt）和 VM 内存膨胀，而 Dart 的固定结构保证了性能的高度确定性。 - [16:25](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=985s) ECMA 标准制定极为缓慢，而移动端封闭生态正在侵蚀 Web，Lars Bak 认为单靠空等标准演进可能错失对抗原生孤岛的时机。 - [24:23](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=1463s) 类型系统如同一个可以自由调节的旋钮，TypeScript 与 Dart 均允许在纯动态与全类型之间根据开发阶段灵活拨动严格程度。 - [26:20](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=1580s) Dart 支持运行时类型检查（Check Mode），能阻止 JavaScript 常有的属性拼写错误并返回 undefined 的“静默失败”陷阱。 - [30:54](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=1854s) TypeScript 在运行时完全擦除类型，旨在静态镜像 JavaScript 动态系统，避免了在运行时逐属性抓取验证所带来的极高开销。 - [34:10](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=2050s) Dart 基于清晰的整体语言结构，能够执行彻底的全程序分析与摇树优化（Tree Shaking），剔除未使用的死代码以大幅缩减交付体积。 - [36:53](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=2213s) Lars Bak 批评固守 JavaScript 历史妥协是一种“技术斯德哥尔摩综合征”，主张唯有勇于从底层颠覆才能打破性能与工程瓶颈。 - [40:53](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=2453s) Web 作为承载一切的底层运行时，多元编程语言是工具箱中应对不同场景的工具，最终的技术裁决权始终由开发者掌握。 - [41:34](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=2494s) Dart 开源 VM 与转译器，TypeScript 跨平台支持 Vim、Emacs 等非微软编辑器，双方均以完全开放的态度拥抱开源社区。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=0s) 初见 TypeScript：Lars Bak 的第一印象与类比 在丹麦奥胡斯（Aarhus）举办的 GOTO 2012 大会上，Channel 9 促成了 Anders Hejlsberg（TypeScript 架构师）与 Lars Bak（Dart 共同创始人、V8 引擎核心设计者）的面对面对谈。由于微软刚刚在前一天正式发布了 TypeScript，主持人开门见山询问 Lars 对这门全新语言的第一感受。 Lars 坦承自己前一天便已仔细浏览过 TypeScript，尽管尚未实际动手编写代码，但他将其定性为一个稳妥的抉择。在 Lars 眼中，TypeScript 看起来像是一个“带有可选类型系统的 CoffeeScript”（CoffeeScript with optional typing）：它提供了类（classes）语法，引入了可选类型（optional typing），同时还配备了一定程度的类型推断（type inferencing）。Lars 指出，这种可选类型的思路与他们在 Dart 中的设计并不遥远，而 TypeScript 最终同样是编译为标准的 JavaScript。 与此同时，Lars 对微软推出该语言的长远意图提出了疑问：这究竟只是一个单纯的工具层语言，还是希望以此影响 ECMA 标准委员会的制定走向？毕竟标准委员会早在 ECMAScript 4 提案时期就曾激烈讨论过类与类型的引入方案。 - 对话地点：丹麦奥胡斯（Aarhus）GOTO 2012 大会 - 对话背景：微软于对话前一天正式公开宣布 TypeScript - Lars Bak 核心观点：TypeScript 是一个安全的选择（safe bet），机制形似具备可选类型的 CoffeeScript，最终皆编译为 JavaScript --- ### [01:14](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=74s) 超集哲学与标准对齐：TypeScript 的设计原点 Anders 针对 Lars 的“CoffeeScript 类比”作出了深入回应。他赞同编译目标同为 JavaScript 的看法，但他强调了两者以及与 Dart 之间最为关键的本质区别：TypeScript 并非从一门全新的独立语法起步，而是直接从 JavaScript 原生语法出发，是 JavaScript 的严格超集（superset）。开发者无需跨越陡峭的学习曲线，只需直接将现有的 JavaScript 代码复制粘贴进 TypeScript 项目，系统便能完全兼容，开发者只需额外学习少数增量概念即可上手。 Anders 详细阐述了 TypeScript 核心特性的构成：除了可选静态类型系统（optional static typing）之外，TypeScript 包含的四大核心语法——类（classes）、模块（modules）、箭头函数（arrow functions）以及剩余参数（rest parameters）——均极其紧密地贴合当时正在规划中的 ECMAScript 6（ES6）标准提案。针对 Lars 提出的“是否试图左右标准”的疑问，Anders 明确否认了微软试图操纵委员会的猜测，表示团队的真正目标是紧跟委员会的步伐。 Anders 透露了一个鲜为人知的开发细节：TypeScript 最初对类的设计与 ES6 并不同轨，但当标准委员会最终敲定采用“Max-Min 提案”作为类规范时，TypeScript 团队果断推翻了原先的架构，重新与委员会规范对齐。为此，内部早期试用团队的代码全部被破坏（broken），但 Anders 坚信这是必须承担的代价：“It wouldn’t make a lot of sense for us to have a different model of classes from what ultimately ends up in ECMAScript 6.” 当 Lars 追问若未来委员会中途再度转向该如何应对时，Anders 表态团队将继续跟进委员会的规范进行调整，绝不会固守自研的一套语法标准与未来的 Web 基础标准脱节。 ```mermaid flowchart TD accTitle: TypeScript 与 ECMAScript 6 语法规范关系图 accDescr: 展示 TypeScript 作为 JavaScript 超集，其类、模块等核心特性完全向 ES6 Max-Min 提案对齐。 subgraph TS["TypeScript 语言设计"] A["原生 JavaScript 代码\n(直接兼容 / 复制粘贴)"] --> B["TypeScript 超集层"] C["可选静态类型系统\n(Optional Static Typing)"] --> B end subgraph Alignment["ES6 标准对齐机制"] D["类 (Classes)"] E["模块 (Modules)"] F["箭头函数 (Arrow Functions)"] G["剩余参数 (Rest Parameters)"] end B --- Alignment Alignment -->|"主动贴合与重构\n(如采纳 Max-Min 提案)"| H["ECMAScript 6 官方草案"] B -->|"编译生成"| I["纯 JavaScript 运行时代码"] ``` - TypeScript 特性组成：可选静态类型、类、模块、箭头函数、剩余参数 - 标准委员会提案对接：为匹配 ES6 采纳的 Max-Min 提案，TypeScript 重构了早期类的内部设计，不惜破坏微软内部团队的已有代码 --- ### [03:29](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=209s) 全新起点 vs. 兼容修补：Dart 与 TypeScript 的路径分歧 Lars 对微团队投入 Web 语言创新表示欢迎，但随即清晰界定了 Dart 与 TypeScript 截然不同的设计哲学。Lars 指出，Dart 绝非 JavaScript 的超集，而是从零开始构建的一门全新编程语言（built from scratch），其首要任务是在底层建立彻底干净的语言语义（cleaner semantics），规避 JavaScript 原生存在的缺陷与奇怪行为。 除了追求语义的清晰与静态类型，Dart 更肩负着性能与运行时突破的野心。Lars 强调，Dart 的关键目标是彻底重写运行时以获取大幅超越 JavaScript 的执行性能，并在短期内拉开可观的性能差距倍数。 此外，Lars 重点指出了现有 JavaScript（以及编译到 JavaScript 的 TypeScript）在大规模应用中不可调和的底层瓶颈——启动性能（startup performance）：在 JavaScript 架构中，构建整个程序的上下文与依赖必须在启动阶段实际运行脚本代码（“JavaScript in order to set up a JavaScript program you have to run the script there's no way around it”），缺乏顶层的声明式结构（declared structure）。而 Dart 通过全生命周期的全新虚拟机与语言设计，旨在从根本上消除这种运行前冷启动的结构性缺陷。 - Dart 的核心诉求： 1. 干净的底层语言语义（从零开始构建，摆脱 JavaScript 历史包袱） 2. 极高的运行时吞吐性能（专属 VM 优化，性能计划大幅度超越 JavaScript） 3. 大规模应用快速启动（避免因执行脚本建立上下文所导致的冷启动开销） --- ### [04:49](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=289s) 规模化代码之困：JavaScript 开发者究竟需要什么？ 主持人将话题引向核心议题：在真实 Web 世界中，大量习惯了 jQuery 和 JavaScript 特异玩法的原生开发者并不觉得当前环境有什么不好，他们真的需要类、接口和类型结构吗？这两门语言是否只是外部面向对象开发者将自身偏好强加于 Web 的实验？ Lars 回应道，这绝非凭空臆测，而是源自真实工业实践中的普遍痛苦。在缺乏结构的情况下，大型 JavaScript 应用几乎无可避免地滑向难以维护的“意大利面条式代码”（spaghetti code）。在 Google 内部，工程团队为了对抗这种混乱，不得不制定极其繁琐的代码规范，甚至强行在注释中（如 JSDoc）书写参数类型与契约。这种用注释描述类型的做法，正是在没有语言级支持的窘境下对结构的渴望。Dart 的创立正是为了解决大型代码库的生产力瓶颈，通过显式类型让工具（Tooling）能够真正介入代码的管理与重构。 Anders 对此表达了高度共鸣，指出 TypeScript 的设计完全是由内外部大型开发团队的痛苦反馈所推动。他认为，面向对象编程与模块化开发已经在工业界被证明是组织复杂逻辑的有效武器。更关键的推力来自现代 IDE 工具链： > “The last decade of IDE advancements, you know with refactorings and code completion and finding references and navigating big code bases, a lot of that is driven by static type information and if you don't have the static type information you just really can only go so far before the guesswork starts.” Anders 深刻指出，在万行级乃至数十万行的大型工程中，单凭开发者个人的脑力无法掌控全局。如果语言缺乏静态类型，IDE 提供的代码补全、交叉引用和安全重构就只能沦落为“猜测”（guesswork），而一旦开始猜测就会出错。 此外，Anders 再次凸显了 TypeScript 采用超集策略的战略考量：任何成熟普及的技术在经过长时间迭代和委员会协调后都不会是完美的，JavaScript 固然满身疮痍，但它拥有一座无可比拟的宝藏——极其庞大的活跃生态、开发者群体与海量现成代码库。TypeScript 选择与现实共存，不破坏既有生态，允许开发者直接使用 jQuery、Node.js core、Backbone 等流行库。通过微软提供的外部静态类型声明文件（如早期针对 DOM、JavaScript 标准运行时、Node 及 jQuery 编写的声明），开发者无需修改第三方库的一行源码，即可平滑享受强类型带来的代码感知与安全保障。 - 大型 JavaScript 应用的核心困境：代码演变为难以追踪的混乱状态（spaghetti code），维护成本极高 - 缺乏静态类型对 IDE 工具链的制约：符号跳转、重构与补全退化为不精准的猜测 - TypeScript 的生态共存策略：不推翻重来，通过类型定义文件为原生生态库（DOM、Node.js、jQuery、Backbone）渐进式赋能工具链支持 ### [09:53](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=593s) JavaScript 的扩展能力与大规模代码库的极限 采访者向 Anders Hejlsberg 和 Lars Bak 抛出了一个核心疑问：TypeScript 这类技术虽然显著帮助了大型代码库，但代码库究竟何时会变得“过于庞大”？像 Gmail、Hotmail 这样庞大复杂的现代 Web 应用，代码量动辄数十万行，底层基础设施在某个时刻是否会不堪重负？JavaScript 本身究竟能承载多大尺度的工程？ Anders Hejlsberg 坦言，现阶段可能确实存在极限，但他自己也说不清极限具体在哪里。面对当今 Web 应用程序的体量，他依然感到惊叹：如此巨大的应用不仅能够正常加载和运行，而且代码规模还能达到几十万行之多。Anders 称赞了整个行业在引擎优化上取得的飞跃，特别是 Lars Bak 主导的 V8 引擎以及微软在 Internet Explorer 中研发的 Chakra 引擎，正是这些底层的技术突破让庞大复杂的 Web 应用落地成为可能。 Lars Bak 同样肯定了引擎性能的进步，指出很久以前 V8 就大幅加快了 JavaScript 的执行速度，如今各大浏览器都变得极为迅捷，这对终端用户无疑是巨大的利好。 ```mermaid flowchart TD accTitle: JavaScript 引擎性能与代码规模演进 accDescr: 展示 JavaScript 引擎优化如何支撑大规模 Web 应用 subgraph Engine["引擎突破"] V8["Google V8 引擎"] Chakra["Microsoft Chakra 引擎"] end subgraph App["工程规模拓展"] Apps["大型 Web 应用 (如 Gmail、Hotmail)"] LOC["数十万行代码规模"] end Engine --> Apps Apps --> LOC ``` ### [11:16](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=676s) 稳妥路线与颠覆尝试：猴子补丁、对象模型与整数类型 在对比 TypeScript 和 Dart 这两条演进路径时，Lars Bak 指出，TypeScript 是一笔“非常稳妥的赌注”，而 Dart 则试图从根本上解决 JavaScript 的核心缺陷。从计算机科学的视角出发，Lars 认为 JavaScript 允许开发者在运行时肆意对基础库进行“猴子补丁”（monkey patch）的设计令人深感不安。在他看来，即便是编译到 JavaScript 的语言，如果底层仍能直接写原生 JavaScript，就意味着无法彻底规避猴子补丁导致的混乱局面，开发者依然可能陷入泥潭。 因此，Lars 宁愿冒更大风险去打造一门全新的语言。他介绍说，Dart 的对象模型受到了 Smalltalk 的启发，结构要清晰简洁得多：对象一旦被创建，其布局就是固定的；如果需要动态属性，开发者必须明确使用 Map 或 List。此外，针对 JavaScript 所有数字底层皆为浮点数（double）的机制，Dart 明确引入了整数类型（integers）。Lars 强调，为了在底层把浮点数硬模拟成整数，运行时不得不耗费大量力气做各种底层处理，这在语义上根本无法接受。Lars Bak 直言：“I really like integers when I code for loops; I don't want them to behave semantically like doubles.” Anders Hejlsberg 完全赞同 Lars 指出的所有缺陷，但他认为核心争议并不在于 JavaScript 是否存在问题，而在于其严重程度是否足以让业界彻底将其抛弃并用新事物替代。Anders Hejlsberg 总结道：“The question is not whether JavaScript is broken, you know, in places; the question is whether it is broken enough to merit being replaced by something else, right?” - **TypeScript 的定位**：基于现有 JavaScript 生态，提供静态类型检查，属于低风险、强兼容的稳妥方案。 - **Dart 的定位**：从语言和运行时底层进行革新，打破既有约束以获取更高的严谨性与性能。 - **动态修改基础库的隐患**：动态猴子补丁破坏了程序的不可变假设，为超大规模代码的协同维护埋下隐患。 - **基础数值类型的分歧**：JavaScript 将所有数字统一为双精度浮点数，Dart 则坚持将整数与浮点数分开，确保循环和计算语义可预测。 ### [14:13](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=853s) 隐藏类、VM 膨胀与可预测的运行时性能 Lars Bak 深入剖析了 JavaScript 高性能编译器的技术瓶颈。为了让动态语言跑得更快，现代 JavaScript 引擎（如 V8）必须在编译器中采用大量复杂的启发式规则，依赖对象的隐藏类（hidden classes/shapes）来推断结构并执行优化。然而，一旦有代码从侧面动态修改了处于执行热点（hotspot）上的对象结构，引擎就不得不发生去优化（de-optimization），导致运行时性能断崖式下跌。 更严重的问题在于虚拟机内部的内存膨胀。在高度动态的 JavaScript 代码中，隐藏类的分支和数量呈爆炸式增长，虚拟机为了在后台拼命识别并追踪这些结构，不可避免地产生了大量内存开销。Lars 指出，如果直接在浏览器中使用内置了 Dart VM 的环境运行 Dart，这一切结构追踪与内存开销都能在底层被彻底避免。性能不仅更高，而且具备高度的确定性（predictability）——无论对象被如何调用，性能都不会无缘无故退化。 Lars Bak 阐述了语言与系统架构的绑定关系：“We cannot sell that as just on the language part; we also have to make sure that system properties are demonstrating it's better in some respects, like performance, and predictability in performance and size, right?” 虽然 Dart 同样提供了编译成 JavaScript 的工具链，但在 Lars 眼中，独立 VM 带来的极致性能保证才是解决大规模系统的关键所在。 ```mermaid flowchart LR accTitle: JavaScript 隐藏类机制与 Dart 预测性模型对比 accDescr: 对比 JS 引擎中的去优化膨胀与 Dart 确定性对象模型 subgraph JSPath["JavaScript 动态机制"] JSObj["动态对象修改"] --> Heuristics["启发式推断与隐藏类"] Heuristics --> Deopt["去优化与 VM 内存膨胀"] end subgraph DartPath["Dart 原生虚拟机"] DartObj["固定对象布局"] --> StableVM["结构预知与可预测执行"] StableVM --> DartPerf["稳定无衰退的高性能"] end ``` ### [16:25](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=985s) 渐进演进还是另起炉灶？标准化的速度与移动端危机 采访者提出了一个广泛存在的疑问：为什么 JavaScript 不能走“从 C 到 C++”的平滑演进路线？既然 JavaScript 已经随处可见——甚至在 Windows 8 中都能编写原生的 HTML5/JS 应用程序——为什么不能通过直接增加类、接口和面向对象特性的新标准（例如“JavaScript++”），在现有语言内部彻底解决问题，而非重新发明一门语言和虚拟机？ Lars Bak 对此给出了相当辛辣的回答：“Oh, it is a reasonable... if you have infinite amount of time.” 他幽默地自嘲自己已经快到退休年龄了，实在没有时间去空等委员会的标准化推进。他回忆道，V8 项目始于 2006 年，当时大家都在热切期盼 ECMAScript 4，但该标准最终完全崩塌流产。尽管后来推出了 ECMAScript 5，但现实中绝大多数生产代码依然停留在 1999 年制定的 ECMAScript 3（ECMA-262 第三版）。标准的推进和落地实在太过缓慢，而外部的危机已经迫在眉睫：封闭专有的移动平台正在迅速侵蚀市场，如果 Web 技术无法快速在移动端实现卓越体验，开放的 Web 生态就会面临被移动孤岛取代的危险。 Anders Hejlsberg 对这一困境表示理解。他指出，JavaScript 的真正力量恰恰在于它能在数不胜数的设备、平台和环境中运行，而这正是由无数拥有不同诉求的厂商共同维护的；要让所有人达成一致极其艰难。不过 Anders 也强调，ECMAScript 5 确实推动了历史进程，严格模式（strict mode）已被各大主流浏览器广泛支持。未来完全可以设想引入更严格的模式（stricter mode），甚至是对象内存布局的提示（hints），以在不抛弃 JavaScript 既有生态的前提下，促成更高效的执行。 ### [20:51](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=1251s) 语言性能优化与大型项目开发困境 主持人抛出疑问：是否可以通过提供底层执行“提示（hints）”来让 JavaScript 运行得更快？例如引入一种类似字符串字面量的机制——就像严格模式指令 `"use strict"` 一样，引擎如果能理解这些提示信息就加以利用，不能理解就直接忽略，类似于 C 语言中的编译器指示（pragmas）。主持人表示他们后续可以深入探讨性能细节，甚至请微软的 Steve Lucco 来详细聊聊 Chakra 引擎与 V8 的内部实现。然而，问题的关键不仅在于性能——如果有无尽的资源投入（如微软常被调侃的“再派一千个程序员砸几十亿美元”），JavaScript 固然能变得更快，但如果语言本身没有演化和改良，这是否本质上是一种时间上的浪费？ 现实中，越来越多的开发者被迫在 JavaScript 上构建大型甚至巨型应用程序，但正如 Brendan Eich 自己坦承的那样，JavaScript 最初被设计出来时根本没有人预料到它会承载今天这样的规模。面对这种局面，行业内出现了两种截然不同的演进路线：一种是 Dart 采取的彻底变革路线，创造一种融合了现代化理念（例如基于 Isolate 的并发并发模型和精巧的语言结构）的全新语言与虚拟机体系，但这就像试图将庞大的 C++ 开发者群体迁移到 D 语言一样，需要面对既有代码库和既有生态的巨大惯性；另一种则是从工具层面切入，在不颠覆现有 JavaScript 运行时语义的前提下提升大规模协作的生产力。 ```mermaid flowchart TD accTitle: 应对 JavaScript 规模化困境的两种技术路径 accDescr: 对比 TypeScript 的纯工具链方案与 Dart 的全新语言加虚拟机方案 Problem["JavaScript 原生设计不适应大型应用<br/>规模化项目面临类型与维护瓶颈"] subgraph TS_Path["TypeScript 演化路径"] TS_Tool["纯工具链增强 Tooling"] TS_Erase["运行时类型完全擦除 Erasure"] TS_JS["完全保留 JavaScript 原生语义与生态"] TS_Tool --> TS_Erase --> TS_JS end subgraph Dart_Path["Dart 变革路径"] Dart_VM["独立虚拟机体系 Dart VM"] Dart_Lang["全新现代化语言特性 + Isolate 隔离并发"] Dart_Check["运行时类型校验与语义一致性"] Dart_VM --> Dart_Lang --> Dart_Check end Problem -->|"路线 A：渐进兼容"| TS_Path Problem -->|"路线 B：全新方案"| Dart_Path ``` - 主持人指出：“Brandon's the first person to tell you I have no idea would ever turn into this this is crazy so it has and now you have to deal with it.”（布兰登会第一个告诉你，他完全没想到它会变成这样，这太不可思议了，但现实已然如此，你必须去面对。） - TypeScript 选择不改变 JavaScript 底层的核心语义，运行时类型完全擦除，专注于纯工具链体验（Tooling）。 - Dart 不仅能编译到 JavaScript，更内建了完整的虚拟机与结构化模型，力图在语言语义级别提供更高的严谨性。 --- ### [24:23](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=1463s) 可选类型系统的不同设计哲学 Lars Bak 阐释了 Dart 中“可选静态类型（Optional Static Typing）”的核心设计初衷：在浏览器端进行快速原型设计与实验时，开发者绝不应该受到繁琐类型的绑架。在早期调试阶段，开发者可以直接在调试器中将代码当作纯动态语言来求值；随着项目逐步成熟、接口逐步固定，再将静态类型像“调味料（sprinkle）”一样逐步标注到代码关键位置，从而提高可读性并方便多团队协作。Lars Bak 尖锐地批评了传统面向对象语言（如 Java 和 C#），认为它们完全错过了 Web 开发中至关重要的“增量式执行（incremental execution）”与“即时反馈（instant gratification）”。 Anders Hejlsberg 对此深表赞同，并指出 Dart 和 TypeScript 不约而同地捕捉到了静态类型与动态类型之间的中间地带： > “it is interesting both with Dart and with TypeScript that that um that there's this space in between statically typed and dynamically typed where where these languages allow you to dial it to to where where you want to be” —— Anders Hejlsberg 在 TypeScript 中，如果完全不写类型注解，代码实质上就是纯粹的动态 JavaScript；一旦加上注解，编译器便会进行静态分析与类型推导，驱动代码自动补全、即时错误提示（Red Squigglies）等编辑器功能全面点亮。 - 可选类型允许开发者根据项目所处阶段自由调节严格程度。 - 传统编译型语言（Java、C#）由于缺乏增量执行机制，无法满足现代 Web 开发对即时交互与快速反馈的需求。 - TypeScript 的类型推导能力能够在开发者仅声明局部类型的情况下，沿调用链向下推导并保证工具提示与静态检查的有效性。 --- ### [26:20](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=1580s) 运行时的类型验证与成本代价 Lars Bak 进一步指出了 Dart 与 TypeScript 在底层实现上的关键分歧：在 Dart 中，对象在运行时携带类型信息（RTTI）。如果在启动 Dart 时开启了特定调试标志（Check Mode），运行时会在执行赋值与跨模块传参时严格验证对象是否符合类型契约。这意味着，即使一部分代码是无类型的动态代码，另一部分是强类型代码，当动态数据流经类型化接口时，虚拟机能立即在边界捕获类型不匹配。 Anders Hejlsberg 承认，如果仅靠纯前端编译工具链在 JavaScript 环境中实现这种动态类型校验，代价将高昂到难以承受。微软团队曾探讨过在 Debug 模式下通过注入检测代码来进行运行时类型验证，但其实践阻力极大： 1. 校验一个函数对象在运行时是否具备预期的三个参数，实现起来非常复杂。 2. 验证一个对象是否符合特定结构性接口（Structural Interface），意味着必须在运行时遍历抓取（gravel through）该对象的所有属性，逐一校验属性名及其类型。 Anders 坦言这种操作在 Dart 的专用虚拟机内成本很低，但在动态的 JavaScript 引擎中不仅极为昂贵，而且受限于语言特异性，“你永远无法做到完全校验（you can never do all of it）”。但他紧接着反问：这种深度的运行时检查在现实中是否真的那么至关重要？在传统的非安全语言（如 ANSI C 之前的 C 语言）中，如果去除函数原型，参数传递错误会导致调用栈损坏（Stack Corruption），甚至使机器完全发疯去把屏幕显存当作代码执行；但在 JavaScript 中，一切调用行为都有明确定义的执行语义（Well-defined Behavior），传入过多或过少的参数绝不会导致底层崩溃。 - Lars Bak 指出 Dart 支持运行时类型检查模式：“in Dart objects carry runtime type information so you can actually do verification of the type as you run if you use a special flag you'll basically check that the assignments obey the types at runtime.”（在 Dart 中，对象携带运行时类型信息，因此如果启用特殊标志，你实际上可以在运行时验证类型，检查赋值操作是否在运行时遵循了类型约束。） - Anders Hejlsberg 承认在 Dart 内部做校验更便宜：“checking that something implements an interface you know means you got to go gravel through all the properties and see that the right ones are there... that's cheaper in Dart.”（检查某物是否实现了一个接口，意味着你必须遍历所有属性并确认正确的属性是否存在……这在 Dart 内部显然开销要低得多。） - JavaScript 属于内存安全执行环境，哪怕调用参数不匹配，也具有明确的容错行为，不会造成栈指针越界或硬件级崩溃。 --- ### [28:43](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=1723s) 接口边界契约与静默失败的陷阱 针对 Anders 的“安全环境”论点，Lars Bak 提出了来自大型工程团队视角的抗辩。当两个团队协同开发时，团队 A 维护带有静态类型注解的公共库，团队 B 编写业务代码调用该库。如果在接口边界处拥有运行时类型校验，错误就能在跨界瞬间被拦截在接口层，调用方就不必硬着头皮去单步调试对方库内部深处的复杂代码。 更糟糕的是 JavaScript 著名的“保持冷静并继续运行（Keep Calm and Carry On）”设计哲学。在 JavaScript 中，拼写错误往往不会抛出任何异常，而是默默评估为 `undefined` 并继续顺水推舟地执行下去。Lars Bak 举例指出：在事件处理中经常需要检查 `readyState`，一旦开发者不小心全写成小写（`readystate`），JavaScript 不仅毫无警告，相关的 `if` 逻辑块更会永远静默跳过，导致程序行为完全脱轨，开发者极难定位根源。 为了彻底解决这种隐蔽的故障模式，Dart 在底层运行规则上做出了明确的约束性设计： > “in Dart what we tried to do as part of the foundation of that is that if you try to access a property and it's not in the object you will get an exception at that point so that you during development can actually see something is wrong and that will certainly catch it earlier than if you just keep on trucking” —— Lars Bak | 场景 / 维度 | 传统 JavaScript 表现 | Dart 运行时策略 | |:--- |:--- |:--- | | **属性拼写错误**（如 `readyState` 误拼） | 隐式返回 `undefined`，静默继续向下执行 | 访问不存在的属性时立即抛出运行时异常 | | **混合模式调用**（未标注代码调用类型化代码） | 无法在边界捕获错误，异常在调用链路深处爆发 | 在开发/检查模式下，对象传入接口边界即验证契约 | | **调试成本** | 开发者被迫跨团队单步调试第三方依赖实现细节 | 错误精准定格在公共接口边界，责任划分明确 | Anders Hejlsberg 倾听后总结道，两者的差异再次印证了核心观点：静态类型本身并不是一个非黑即白的开关，而是一个可以灵活调整的“调节旋钮（dial）”，不同的技术方案选择将这个旋钮旋停在了不同的刻度上。 ### [30:54](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=1854s) TypeScript 对 JavaScript 动态系统的静态镜像与库推理 讨论围绕在 JavaScript 之上加入类型系统的成本展开。Anders Hejlsberg 指出，旋钮拨到不同档位，程序员所承担的负担以及运行时的开销都各不相同；一旦越过某个阈值，在 JavaScript 里做验证就会因过于昂贵而失去意义。但 Anders 认为 TypeScript 抓住了这个调节旋钮上 80% 到 90% 最有意义的区间。主持人询问 TypeScript 是否能解决“双团队问题”——即一个团队用接口和类编写库，另一个团队拿到 `.d.ts` 或 TypeScript 文件去实现接口。Anders 回应称，在大型 JavaScript 开发中，最缺失的是一种公认的、能够用来对库进行逻辑推理（reason about libraries）的统一方式。 在没有静态类型定义之前，开发者如果同时引入 jQuery 和 Node.js，就必须分别去不同的官网翻找文档，面对彼此脱节的技术术语、经常被遗漏的边缘情况以及未定义行为。静态类型定义让开发者可以在同一个语言体系内声明“这个库到底是什么”，并通过工具来自动校验代码是否契合描述，从而让程序员“晚上能睡个好觉”。Anders 特别强调了 TypeScript 的设计哲学：它所做的一切，就是构建一个静态类型系统去精准镜像 JavaScript 原生的动态类型系统，绝不凭空生造新的运行时概念。在设计时它是类型严谨的，但到了运行时，它依然是纯粹的 JavaScript。 - “I will say I think with TypeScript we're capturing a good, you know, 80-90% of the meaningful settings on that dial.” —— Anders Hejlsberg - “The thing that I think has been lacking for large JavaScript development is an agreed-upon way to reason about libraries.” —— Anders Hejlsberg - “What we have done in TypeScript is basically formalize a static type system that mirrors the dynamic type system of JavaScript, and we have really worked very hard to stay true to that.” —— Anders Hejlsberg --- ### [34:10](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=2050s) 代码剔除（Tree Shaking）与全程序分析的较量 Lars Bak 承认 TypeScript 因为与 JavaScript 深度整合，在与既有库互操作时要容易得多；但他抛出了前端部署中极其现实的痛点：许多网站在启动阶段下载了海量的函数，实际执行的却只有其中几个百分点，严重拖慢了首屏下载和加载时间。Dart 从一开始就具备更严谨的程序结构，使得编译器能够对完整程序执行全局分析并做“摇树优化”（Tree Shaking），剔除所有能被证明绝不会执行的方法，进而让编译出的 JavaScript 代码或 Dart 虚拟机快照（snapshot）体积降到最小。 Lars 强调，如果像 JavaScript 那样允许随意通过动态拼接的字符串进行键值索引访问（keyed access），静态分析器就很难断定某个属性或函数是否被调用，因此在 JavaScript 混用既有库的环境下做深度优化极其困难。面对 Anders 关于“存在动态类型时如何判定是否调用”的质疑，Lars 解释说，最简单的摇树哪怕只做名字分析（例如发现整个程序中压根没人使用标识符 `foo`），效果就已经惊人；进阶的做法则是从 `main` 方法或 DOM 入口出发，配合类型推断一路推导整个依赖链路。在 Google 内部，Closure Compiler 也是靠在 JavaScript 注释里写伪类型（pseudo-types）来勉强实现类似分析的，但这必须强求所有代码都遵循极为严苛的书写规范。 ```mermaid flowchart TD accTitle: Dart 与 TypeScript/JavaScript 代码打包机制对比 accDescr: 对比 Dart 基于整体语言结构的全程序摇树分析，与 TypeScript 融入 JavaScript 外部工具链的标准流程。 subgraph DartPath["Dart 全程序分析路线"] D1["Dart 源码 (强结构 / 单一语言)"] --> D2["入口分析 (main / DOM)"] D2 --> D3["全局类型推断 & 标识符遍历"] D3 --> D4["Tree Shaking (剔除未引用函数)"] D4 --> D5["极简交付包 (JS 代码 / VM 快照)"] end subgraph TSPath["TypeScript 现有工具链路线"] T1["TypeScript 源码"] --> T2["tsc 编译 (类型擦除)"] T2 --> T3["标准 JavaScript 代码"] T3 --> T4["混合第三方库 (如 jQuery)"] T4 --> T5["外部工具处理 (Minifiers / RequireJS / AMD)"] end ``` - “Because it's more structured, right, also compared to TypeScript, we can actually do analysis on the complete program and do tree shaking and throw out methods we can prove that are not being executed.” —— Lars Bak - “It reduces a lot of the code being deployed, and that's what big companies want when they deploy a web app — they don't want all the stuff that's not being executed.” —— Lars Bak --- ### [36:53](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=2213s) 工具链组合 vs. 彻底革新：摆脱“斯德哥尔摩综合征” Anders 针对摇树优化表态：TypeScript 自身目前确实没有内建 Tree Shaker，如果开发者要针对纯 TypeScript 代码做摇树是完全可行的，难点在于那些动态特质强烈的既有第三方 JavaScript 库（如 jQuery）。但 Anders 强调，TypeScript 的定位从来不是包揽一切，而是甘当工具链中的一环——在开发期提供类型检查与自动补全体验，随后输出干净的 JavaScript，由下游的压缩器（minifier）、打包工具（如 RequireJS/AMD 工具）去完成后续优化。他直言，无论是 Dart 还是 TypeScript，都不可能靠一己之力满足整条流水线的所有诉求。 Lars 则回应，一旦把代码与动态的 JavaScript 库混在一起，要想既保留语义又不误删代码是极其危险的，而 Dart 从头构建结构化语言的优势就在于拥有这种彻底分析的底气，他甚至自信地提出“可以比试一下谁的 Tree Shaking 更厉害”。随后主持人总结道，TypeScript 是在现有 JavaScript 工具链上加了一层薄壳，而 Dart 则是从底层推倒重来。面对“JavaScript 无处不在且无需安装 VM”的现实，Lars 直言这是一种技术的“斯德哥尔摩综合征”：如果永远只向后看而不去创新，开发者就永远无法突破。当年研发 V8 时也有人质疑“现有程序跑得好好的，为什么需要那么高的性能”，在他看来那是愚蠢的论调。不过 Lars 也重申，他非常乐见 TypeScript 的出现，Web 领域的创新多元共存，这绝非一场非此即彼的零和博弈。 - “I think, you know, at the end of the day I don't think neither Dart nor TypeScript will ever do everything that anyone will want in that tool chain.” —— Anders Hejlsberg - “I'll still guarantee that we can do a small competition who can do better tree shaking, but I can guarantee you I'm holding the better hand.” —— Lars Bak - “That's a Stockholm syndrome, right? If you always look backwards, you don't innovate.” —— Lars Bak - “I think anything that tries to innovate in the web space is great, and it's not something that if you do that we cannot do the other — I think there's room for several solutions.” —— Lars Bak ### [40:53](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=2453s) 多语言并存的 Web 生态与开发者的选择权 在探讨 Web 开发语言的前景时，对话双方达成了一个核心共识：Web 平台正迎来前所未有的多元化，已经有大量语言能够被编译或转译为 JavaScript。谈及这种百花齐放的态势，Lars Bak 直言开发者本就应该拥有广泛的选项，正如 Lars Bak 所说：“The more the merrier because at the end of the day it'll be the programmers out there that will make the decision what kind of language you can use and if you look back 20 years it was exactly the same.” 他回顾二十年前的软件开发历史，指出当时开发者同样面临着丰富的语言抉择，因此行业绝不应走回头路，更不该去强行限制开发者的自由。Lars Bak 诚恳地呼吁：“Please do not shoehorn developers into only using one language.” 主持人对此表示强烈赞同，并形象地将各种编程语言比喻为工具箱中用途各异的工具。在当下的技术格局中，Web 本身构成了统一的底层运行时环境（Runtime），而开发者需要做的是深刻理解技术演进的浪潮，并在工具箱中挑选出最趁手的利器来最大化其价值。无论是 Anders Hejlsberg 打造的 TypeScript，还是 Lars Bak 推动的 Dart，都在以不同的哲学方向积极拓展现代 Web 开发的边界。 - 语言是工具箱中的工具（Tools in a toolbox），Web 则是承载一切的基础运行时环境。 - 历史具有周期性：20 年前开发者就拥有多元的语言生态，如今 Web 领域重现了这种自由度。 - 不应将开发者强行塞入单一语言的狭隘框架中，最终的技术裁决权始终掌握在广大程序员手中。 --- ### [41:34](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=2494s) 全面拥抱开源：摆脱专有技术与跨平台生态布局 随后，两位技术领袖重点阐述了各自项目的开源策略与开放理念。Lars Bak 强调，Dart 与 TypeScript 一样秉持着完全开放的原则；Dart 不仅具备将代码转译为 JavaScript 的能力，还将整套虚拟机（VM）完全开源。Lars Bak 解释道，开源虚拟机的初衷就是向整个行业展示 Dart 程序运行时的卓越特性，并希望所有人只要喜欢就能直接采用。Lars Bak 明确表明团队没有谋求技术垄断的意图：“We are certainly not trying to come up with a proprietary technology here, we're trying to sort of free the web basically.” ```mermaid flowchart TD accTitle: Dart 与 TypeScript 开源与生态策略 accDescr: 对比 Dart 与 TypeScript 在开源架构、执行路径及跨平台工具链支持上的开放生态。 subgraph DartEco["Dart 开放生态 (Google)"] D1["Dart 语言与生态"] --> D2["Dart 虚拟机 (开源 VM)"] D1 --> D3["Dart2JS 转译器"] D2 & D3 --> DE["目标：推动 Web 自由与高性能"] end subgraph TSEco["TypeScript 开放生态 (Microsoft)"] T1["TypeScript 语言"] --> T2["开源编译器与代码仓"] T2 --> T3["跨平台编辑器支持<br>(Visual Studio / Vim / Emacs 等)"] T3 --> TE["目标：开放跨平台并激发社区创新"] end ``` 针对这一立场，Anders Hejlsberg 也从 TypeScript 的角度做出了呼应。他指出，TypeScript 同样是彻底开源且能够在任意环境下运行的技术，它的定位绝非局限于微软的封闭体系。为了打破外界对微软工具绑定的刻板印象，Anders Hejlsberg 特别提到就在发布前夕，官方已经推出了针对多种非 Visual Studio 环境的编辑器支持，涵盖了 Vim、Emacs 等跨平台文本工具，展示了跨越 Windows 平台、融入通用开发者社区的开放决心。看到这种虽然路径迥异但精神相通的创新，双方都深感振奋。 Anders Hejlsberg 兴奋地分享了刚看到的社区动态，就在他们坐下来录制访谈前不久，他特意查看了托管在 GitHub 上的 TypeScript 代码仓库，发现已经涌现出了多达 9 个 Fork。开源社区对这门新语言迸发出的极大热情，让两位巨匠对未来的演进充满期待。访谈最后在轻松幽默的氛围中收尾：主持人期待明年在 Web 技术的舞台上再次相聚，Anders Hejlsberg 则打趣道：“We hope we are both in the business in a year.” 所有人笑着举杯，在对彼此卓越成果的相互致敬中结束了这场思想碰撞。 - Dart 坚持全栈开源路线，既提供 Dart2JS 转译工具，又将高性能 VM 完整开源，旨在“解放 Web”。 - TypeScript 彻底打破专有绑定的传统偏见，从首发阶段便支持 Vim、Emacs 等多编辑器生态，具备跨平台运行能力。 - 在访谈开始前，刚上线的 TypeScript 仓库在极短时间内就已产生了 9 个社区 Fork，展现出社区的极高关注度。 ## Notable quotes > [11:16](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=676s) The question is not whether JavaScript is broken, you know, in places; the question is whether it is broken enough to merit being replaced by something else, right? — Anders Hejlsberg > [40:53](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=2453s) Please do not shoehorn developers into only using one language. — Lars Bak > [01:14](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=74s) It wouldn’t make a lot of sense for us to have a different model of classes from what ultimately ends up in ECMAScript 6. — Anders Hejlsberg > [11:16](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=676s) I really like integers when I code for loops; I don't want them to behave semantically like doubles. — Lars Bak > [30:54](https://www.youtube.com/watch?v=5AqbCQuK0gM&t=1854s) What we have done in TypeScript is basically formalize a static type system that mirrors the dynamic type system of JavaScript, and we have really worked very hard to stay true to that. — Anders Hejlsberg ## Mentioned Anders Hejlsberg, Lars Bak, TypeScript, JavaScript, Dart, CoffeeScript, ECMAScript, ECMA 标准委员会, V8 引擎, Chakra 引擎, Smalltalk, Closure Compiler, RequireJS, jQuery, Node.js, Backbone.js, Visual Studio, Vim, Emacs, GitHub, Google, Microsoft, Channel 9, GOTO 2012 ## Video description Lars Bak and Anders Hejlsberg talk about Dart, TypeScript and JavaScript with Channel 9 while attending GOTO2012 in Aarhus. [Source](https://www.youtube.com/watch?v=5AqbCQuK0gM)

[11:16] Anders Hejlsberg: The question is not whether JavaScript is broken, you know, in places; the question is whether it is broken enough to merit being replaced by something else, right? [40:53] Lars Bak: Please do not shoehorn developers into only using one language. [1:14] Anders Hejlsberg: It wouldn’t make a lot of sense for us to have a different model of classes from what ultimately ends up in ECMAScript 6. [11:16] Lars Bak: I really like integers when I code for loops; I don't want them to behave semantically like doubles. [30:54] Anders Hejlsberg: What we have done in TypeScript is basically formalize a static type system that mirrors the dynamic type system of JavaScript, and we have really worked very hard to stay true to that.

[28:43] Anders Hejlsberg: Static typing is a dial, you know, and you can put the dial in different places. [4:58] Lars Bak: I think we all experience when you do big JavaScript applications they turn into spaghetti code and they're very hard to maintain. [2:00] Anders Hejlsberg: It wouldn't make a lot of sense for us to have a different model of classes from what ultimately ends up in ECMAScript 6. [39:23] Lars Bak: If you always look backwards, you don't innovate.

[0:00] all right we're in arus with Andre hburg [0:03] and Lars Bach and we're here to talk [0:05] about typescript and JavaScript and dart [0:08] and let's start right off I me so we [0:10] announced yesterday typescript so right [0:13] on um I wanted to quickly get ls's take [0:16] on it so what do you think of typ scrap [0:19] uh you haven't had a lot of time to [0:20] digest it but that is not true um I [0:23] actually looked at it yesterday but I [0:25] have not coded in it of course uh it [0:28] seems like um safe bet right it's a to [0:32] me it looks like a [0:34] um uh coffee script with optional typing [0:38] right you get classes and you have this [0:40] optional typing which is great uh the [0:42] optional typing is not that far away [0:45] from what we have in that uh that's a [0:47] little bit of type inferencing going on [0:50] um other than that at the end of the day [0:52] it still compiles down to javascrip mhm [0:56] so [0:57] um I don't know what the intent is uh [0:59] with with it if it's uh to influence the [1:02] the co the standards committee to to [1:04] adapt that kind of stuff but the I know [1:06] that they have discussed the classes and [1:08] uh and types as well as part of the [1:10] ecoscope 4 right proposal maybe you can [1:13] comment on that yeah well I let let me [1:15] add uh you know your coffee script [1:17] analogy is is it's you're right that [1:21] there's it it compiles to JavaScript I I [1:23] I will say though that unlike coffee [1:25] script and unlike Dart it also starts [1:27] with JavaScript so it's a superet of [1:28] JavaScript so so you can just copy and [1:31] paste your code in and then you know [1:32] there are only a few extra Concepts you [1:34] have you have to learn that that was [1:35] sort of part of the the reasoning about [1:37] you know not creating a new language but [1:39] just starting copy from JavaScript to to [1:42] typescript typescript not the other way [1:44] around well the com well the compiled [1:46] output you can that is Javascript so you [1:48] know it sort of starts and ends with uh [1:51] with uh with JavaScript yeah and that's [1:52] something I've seen because online of [1:54] course there's a lot of comments a lot [1:55] of good Buzz a lot of questions and so I [1:58] mean typescript [2:00] is Javascript it's a JavaScript is that [2:02] one way to think about it it's a superet [2:05] of JavaScript I mean technically correct [2:08] right I mean that that that's what it is [2:10] um now the the the features that are in [2:13] there uh optional static typing uh [2:15] classes modules Arrow functions rest [2:18] parameters um the latter four are are [2:22] all you know aligned as closely as we [2:25] can with what's currently proposed for [2:27] ecmascript 6 so we're so we're not [2:30] trying to sway the committee in one One [2:32] Direction or the other rather we're [2:33] we're trying to follow where the [2:34] committee is we actually had a different [2:37] design for classes originally and and [2:39] once the committee decided on the on the [2:41] maxmin proposal which is which is the [2:43] current one we went back and and [2:45] realigned uh I still like parts of old [2:48] the I'm better but so I going ask you [2:50] this question since it's not determined [2:51] in the committee which way to go mhm [2:54] what if they take a different route well [2:56] then you adopt uh yes this is I mean [3:00] that that is our intent now it all [3:02] depend I mean I can't say because I [3:03] don't know what what's what's going to [3:04] happen right but but uh but that's the [3:07] intent and that's why we already I mean [3:09] we had internal teams using it and we [3:11] and we changed the model of classes and [3:13] broke everybody and uh you know and and [3:16] so for this reason it's a preview right [3:18] and and so you know there it wouldn't [3:21] make a lot of sense for us to have a [3:22] different model classes from what [3:24] ultimately ends up in OS script 6 I mean [3:26] that would just be you know just to make [3:29] one thing clear from my side I think [3:31] it's great that people are innovating in [3:32] the web space so thank you for doing [3:36] another language for the web um uh just [3:39] to make sure that we contrast a little [3:41] bit to thatt right thatt is a very [3:43] different kind of programming language [3:45] where we from scratch uh are trying to [3:46] make cleaner semantics yeah I know you [3:48] have [3:49] some um some opinions about the basic [3:52] semantics of Jos script but we actually [3:53] Tred to clean that up in in Dart and [3:55] you're trying to solve other stuff than [3:56] just having uh op static types and clean [3:59] semantics right we also want to have [4:01] better uh performance and we think [4:04] actually we can uh make the runtime go [4:07] much faster well we already know it's [4:08] running faster because it's doing that [4:09] today but uh in a short while we'll we [4:12] will uh have a a fairly good Factor [4:15] compared to jscript and and startup uh [4:18] is important to us for big application [4:20] and I think that's a problem with [4:21] jscript even for typescript where you [4:25] generated JavaScript and use the [4:26] JavaScript in as a startup performance [4:28] and and the the reason why I'm [4:30] mentioning is a problem is that [4:31] JavaScript in order to set up a [4:34] JavaScript program you have to run the [4:35] script there's no way around it um [4:38] there's no sort of declared structure uh [4:40] in JavaScript uh when when you set up [4:42] the program so uh that's just some of [4:45] the differences between the um [4:47] typescript and Dot well I mean that's [4:49] actually a great segue because you're [4:51] you're not really necessarily solving [4:53] the exact same problem in one sense I [4:56] mean but let's can we talk about the [4:58] elephant in the room which of of course [4:59] is Javascript and what I mean by that is [5:03] I mean in some sense we see a lot of [5:05] this out in the real world where people [5:07] are trying to make jav like they're [5:09] trying to do these contortions to make [5:11] JavaScript more of a structured language [5:14] or simpler to use or more familiar to [5:17] you know objectoriented developers and [5:18] stuff but one of the questions I'd like [5:20] to ask right off the bat is from an [5:21] angle of the JavaScript developers who [5:24] are perfectly content with this very [5:27] kind of strange world that they're in [5:29] uhhuh and [5:30] in some sense this might be a test bed [5:31] to see whether or not they really want [5:33] classes and interfaces and that kind of [5:35] stuff and and D is true maybe I mean so [5:38] that's my question like from from the [5:40] JavaScript developers perspective the [5:42] ones that deal with this the ones who [5:43] write jQuery and and deal with it every [5:45] day with the really kind of strange [5:47] attacks um this is going to see whether [5:50] or not this actually makes sense in [5:52] their world maybe they don't want [5:53] structure have you ever thought about [5:54] that I mean both of you yes sure of [5:56] course we have of course so and so so [6:01] there's reasoning behind the madness I [6:03] think in both cases we at least trying [6:05] to have a few common goals uh with these [6:08] two languages one is that the I think we [6:11] all experien when you do big josp [6:13] application they turn into spaghetti [6:14] code and they're very hard to [6:16] maintain uh at Google uh we often try to [6:20] put more structure on jscript by having [6:22] uh guidelines for jscript and put in [6:25] comments uh that will sort of describe [6:27] the types that have been passed in for [6:28] the parameter and so on this is all an [6:31] attempt to get structure in JavaScript [6:34] to make it more uh maintainable the code [6:37] uh so that's part of the reasons why we [6:40] started the at least the dot project is [6:42] to make sure that we can improve uh [6:45] program productivity uh and also allow [6:49] tooling to help uh manage the code [6:51] afterwards that's one of the big [6:53] advantages of having types and I guess [6:55] anos you can just yeah either agree or [6:58] disagree yeah no I I I think what what [7:01] certainly the the the design of [7:02] typescript was very much driven by by [7:05] feedback [7:06] from from customers be they external or [7:10] internal using our our tools or or the [7:12] tools that they wish we had you know to [7:14] write to write JavaScript code and going [7:16] this is too hard and you know I you [7:20] don't necessarily have to have classes [7:22] and you don't necessarily have to have [7:24] modules but boy they do help you [7:25] structure your code and I think the the [7:27] world sort of has proven that object [7:30] Orient programming is useful for for you [7:33] know at at at at large and that modular [7:35] programming does have certain advantages [7:38] it doesn't mean that you have to use it [7:40] uh but it's but it's there I I also [7:42] think you know that that static typing [7:45] uh you know the last decade of IDE [7:47] advancements you know with refactorings [7:49] and code completion and finding [7:50] references and navigating big code bases [7:53] a lot of that is driven by Static type [7:56] information and and if you don't have [7:58] the static type information you just [8:00] really can only go so far before the [8:03] guess work starts and then sometimes [8:05] you're going to guess wrong or you're [8:06] not going to have a guess at all and so [8:09] you're not going to be able to provide [8:10] the the help and that's fine for small [8:12] code bases or single developer code [8:15] bases where you can keep everything in [8:16] your head or see everything on the [8:17] screen you know but but as code bases [8:20] get into the thousands or tens of [8:22] thousands of lines of code you know you [8:24] need you need help in reasoning about [8:27] them you know and and and and that's [8:29] really what this is about it's it's very [8:31] much about doing what we need to do to [8:34] bring the tooling up to the level of of [8:37] Excellence that we want to that we want [8:38] to be at um I I would add too you know [8:42] that that one of the interesting things [8:43] about starting with uh with with [8:46] JavaScript is that that uh with [8:49] typescript we allow you to use all of [8:51] the existing Frameworks that are out [8:52] there and you know yes JavaScript has [8:55] all sorts of problems uh as as any as [8:58] any established adoped technology does [9:01] you know they're never pretty they're [9:03] never pristine because lots of people [9:05] have worked on them over lots of time [9:06] and committies and what have you uh but [9:09] on the other hand what they do have is [9:11] they have an enormous uh community of [9:15] users and enormous community of code [9:17] bases out there that that you can [9:19] leverage right and we're we're being [9:21] very conscious about you know not [9:24] messing with that and and allowing [9:25] people to use jQuery nodecore backbone [9:29] and actually sort of dip their toes by [9:32] you know gradually providing static type [9:34] information we've written the static [9:36] type information for the Dom uh for the [9:38] JavaScript runtime for node or for the [9:40] beginnings of one for node and and for [9:43] jQuery um and and but the good news is [9:46] that even without them you know we can [9:48] still deliver value but with them we can [9:49] deliver more value and you still don't [9:51] have to go modify any of these libraries [9:53] you can use them as they are um yeah so [9:57] the I guess one question I mean clearly [9:59] that this is most helpful for large code [10:02] bases as you mentioned but when does it [10:05] get too large like if you think about [10:07] you know uh real not I won't say real [10:10] applications but canonical applications [10:12] uh can be in much larger than Gmail and [10:17] Hotmail and stuff like that you know the [10:18] big web applications at some point [10:21] doesn't it just get too big in general [10:22] for the infrastructure I'm wondering how [10:25] much how how far can JavaScript scale [10:28] yeah I mean [10:29] there are there are limits today [10:31] probably I don't know where the limits [10:32] are I I I I I'm continually Amazed by [10:36] the fact that these large applications [10:38] actually do load and do work and and are [10:42] still you know some of the r hundreds of [10:44] thousands of lines of code right and uh [10:47] the the strides that we made you know [10:49] like thanks to your work and and and uh [10:51] and and the work on chakra in in IE is [10:54] is amazing you know um so so you know I [10:58] I must say I you know I have been [10:59] surprised at uh what you can [11:02] do yeah so it's certainly true that V8 [11:05] sped up and u a long time ago uh the [11:09] execution of josp that's good so [11:11] browsers are faster today and U this is [11:13] all good for the users mhm um I think if [11:16] you contrast the these two lengths we [11:18] talked about right the uh the typescript [11:21] is still a a very safe bet uh whereas D [11:26] is is actually trying to to to change [11:29] some of the the fundamental issues [11:31] that's with JavaScript and uh I still [11:35] from a computer science background I [11:37] still have problems with that you can uh [11:40] you can design application with [11:42] libraries where you can you can monkey [11:44] patch the libraries uh when you get up [11:46] running I just find that very very [11:49] disturbing when you're trying to big big [11:51] write big application so even though [11:53] it's admirable to do a um a language [11:57] that translates to JavaScript but but [11:59] still if you can write normal jospt it [12:01] means that you can monkey patch the [12:02] basic libraries and you'll end up in the [12:03] same mess as if you use jospt to start [12:05] out with I think that if you do the [12:07] right kind of if you type check [12:08] everything that will probably be [12:10] prevented uh but it's still a risk when [12:13] uh when you use the the basic execution [12:15] in then JavaScript so at least when you [12:17] mix JavaScript and and this new language [12:20] U very [12:22] tightly um so I think it's it's about [12:25] risk and and um I'm willing to to to try [12:29] the extra bed and and and go for [12:30] something new uh I think that's a um [12:35] um I guess you haven't looked at thatt [12:37] oh no no I've looked at it yeah yeah [12:39] yeah it's been a while but uh but you [12:41] know when it first came out yeah took a [12:42] look so uh but I think it's the the [12:46] object model it's much simpler MH um uh [12:49] it's pretty much inspired by the small [12:51] talk object model where objects uh uh [12:54] they have a fixed format when you have [12:56] created it and if you want to do a [12:58] dynamic object uh you basically have to [13:01] create a map or or or a list and use [13:03] that and uh and then we put in stuff [13:07] that um I think is important in a [13:09] language uh like um instead of only [13:12] having floating Point numbers which is [13:13] the basis for computation in JavaScript [13:16] we actually have integers I like [13:18] integers because you can actually reason [13:20] about them they have their uses I I oh [13:22] you do you think that yeah so uh having [13:25] a language that's based on on on um on [13:28] on numbers or doubles and you behind the [13:31] scenes work really hard to make it act [13:35] like integers yeah is um I think a [13:38] fundamental problem in my mind so uh um [13:42] I really like inte when I code for Loops [13:44] I don't want them to behave semantically [13:47] like doppes no I I you know everything [13:51] you say and more I will I will readily [13:53] agree but the the question is is is not [13:56] whether JavaScript is broken you know in [13:58] places the question is whether it is [14:00] broken enough to Merit being replaced by [14:02] something else right and then that's and [14:05] I don't know the answer to that question [14:06] and and and I don't know who who if [14:08] anyone knows you know we'll we we'll [14:10] have to see but yeah so one thing I I [14:13] thought about and U I also have [14:15] mentioned before is that um in order to [14:19] make geoscope fast uh you have to apply [14:22] a lot of theistic uh to the compiler um [14:26] and it has to do with this if the shape [14:27] of the object has a [14:29] has a well-known form then you can [14:30] optimize otherwise not and that means [14:32] that in certain situations where if you [14:34] from the side are manipulating an object [14:36] that's hot in the josc engine suddenly [14:38] the performance uh degrades and um I [14:42] know people are trying very hard to make [14:44] that not happen but it's still the case [14:45] for all uh fast Jos com engion and [14:48] that's something I'm also very um keen [14:51] on is have a language like that where [14:54] you can predict that the performance [14:56] will not degrade no matter how you use [14:58] it from the side um and I [15:01] think [15:03] um we cannot sell that as just on the [15:06] language part we also have to make sure [15:08] that system properties are uh [15:10] demonstrating its better in some [15:12] respects like performance and uh and uh [15:16] prct predictability in performance and [15:18] size right so um I had my play in in in [15:22] V8 and um uh we all do these hidden [15:27] class or shapes of objects behind the [15:29] scenes and uh depending on how Dynamic a [15:32] program is right uh the the bounce of uh [15:36] or the limits of these hidden classes is [15:38] the is huge right so you you get sort of [15:41] you get blo in in the VM and there's no [15:43] way around it no matter how you do it um [15:46] so in jcope program uh where you invoke [15:50] it on optimizing jcope engine you have [15:53] some bloat associated with trying to [15:54] recognize structure behind the scenes uh [15:57] stuff like that we can avoid comple when [15:58] running dots so I think there's many [16:00] issues you can discuss it if it's just [16:02] the language why if it makes sense to [16:03] make new language uh but I also would [16:05] like to see it as if you actually build [16:07] an application in this new language [16:08] called Dart then you would also uh get [16:11] some guarantees that uh it's faster if [16:14] you have the VM installed in your [16:16] browser of course understood so I we [16:19] also translate to JavaScript by the way [16:21] yes you do this is true um but besides [16:25] the dart versus um typ SCP because [16:29] there's such very different yeah [16:31] solutions to a similar problem obviously [16:33] but one has to ask that JavaScript why [16:37] can't it be like C to C++ in the sense [16:40] that you have JavaScript JavaScript is [16:42] not going to go away now it may go away [16:45] but I don't know that it's really ever [16:47] going to happen it seems to just [16:48] continually grow in terms of use we even [16:51] in Windows now Windows A8 you can build [16:53] native HTML 5 applications you're [16:55] programming in JavaScript uh or [16:57] typescript and why does it have to go [17:00] away I don't but this is what I'm trying [17:01] to this is where I'm trying to get to [17:03] you mentioned these fundamental problems [17:05] if the language evolves to a level where [17:08] those problems [17:10] disappear then there won't be a need to [17:12] invent a new language with a new virtual [17:15] machine you can just have JavaScript the [17:18] modern version so JavaScript Plus+ which [17:21] has classes and interfaces and object [17:23] orientation fixed problems you see what [17:26] is that not a reasonable oh it is a [17:27] reasonable uh if you have infin infinite [17:30] amount of time so I'm getting I'm [17:32] getting close to pension age and uh uh [17:37] all respect for the uh the committee uh [17:39] doing jeros script but if you have seen [17:41] the adoption of of new standards in [17:43] jscript uh I I don't have time okay so [17:47] it's um we started with um with we8 uh [17:52] in [17:53] 2006 and um the the big hot thing there [17:56] was to do osc 4 which for for reasons I [18:00] do not really understand folded [18:02] completely I guess you can elaborate on [18:05] that actually I was not involved in [18:06] hript 4 either but uh so yeah no but as [18:11] a representative for the company oh I [18:13] anyways the uh um uh the point is that [18:17] it's pretty much the same language as uh [18:19] we started with in 2006 right uh there's [18:22] been a few editions there's ecmascript 5 [18:24] but most in reality most programs out [18:26] there are still ecmascript 2 262 [18:28] revision 3 um so um so it doesn't change [18:33] that fast so when you say well why not [18:35] make it incrementally [18:37] better I hope it can happen that way but [18:40] right now it doesn't seem to go very [18:42] fast uh it might be that change after uh [18:45] airing this but uh uh but I think the [18:50] the The Innovation right in the web [18:53] space is crucial right I think what what [18:56] the big problem is right now is that if [18:58] you don't don't innovate uh with new [18:59] languages new systems in the the [19:02] browsers uh the [19:04] proprietary uh mobile platforms are [19:07] taking over and I don't like that right [19:09] so we need to make sure that we push [19:11] this technology as fast as we can to [19:13] make sure that web technology is also [19:15] brilliant when it comes to mobile phones [19:18] and uh we're doing our part uh I like [19:21] both of us I guess in in doing better [19:23] languages and and systems for for the [19:26] web interesting yeah [19:28] yeah it's a it's bit of a conundrum you [19:30] know uh [19:33] because the real power of JavaScript is [19:35] the fact that it runs in so many [19:37] different places on so many different [19:39] devices and on so many different [19:41] platforms built by so many different [19:42] people with so many different agendas [19:44] right and it's really hard to get them [19:47] all to agree on stuff right but there [19:50] are some things that have been agreed on [19:51] you know like an ecmascript 5 did move [19:53] the ball forward and it is getting to a [19:55] point where most of the browsers Now [19:57] Sports strict mode and and you know a [19:59] bunch of the stuff that's in in 5 um and [20:03] you could certainly Envision like [20:05] stricter mode you know with like even [20:08] with hints for object layouts or or [20:10] whatever I mean there are certainly [20:12] things that could be done you know uh to [20:15] JavaScript to to make it run [20:18] faster as it exists right or you know I [20:23] don't know that's that's a great Point [20:25] that's sort of I was getting on getting [20:26] trying to get to you in terms of you [20:27] mentioned that I mean you're saying that [20:30] V8 and the work that you guys do the [20:32] great work that's been done and the [20:34] great work that we do in shockra and [20:35] stuff which are use some of different [20:37] techniques and I'd love to have that [20:39] conversation in a different interview [20:40] here um the the question that I have is [20:44] as you mentioned you could make [20:45] JavaScript execute faster if you changed [20:48] the [20:49] language if you added constructs to the [20:51] language as you were just saying I mean [20:54] yeah I think I was well I was trying to [20:55] say something subtler I think you could [20:57] you could you could make it run [21:00] faster if you provided hints about how [21:03] it might run faster you might for [21:05] example have a hinting system that you [21:07] know just like a string literal that [21:09] says nothing you know like you strict [21:11] and it you or or whatever you know you [21:14] could have some information in there [21:15] that everyone would ignore except for [21:18] those who look at it you know and [21:20] understand it you know what I'm saying [21:21] and and pick up the hints that are in [21:22] there for example I mean I'm not you [21:25] know I'm I'm just throwing out ideas [21:27] here you know so so it's like tras in [21:29] see that's they're great yeah well I I [21:32] you know I'm not it's not it's not [21:36] it's on well I mean the performance we [21:39] can geek out on the performance stuff [21:41] soon uh we'll bring over Steve LC we'll [21:43] dig into what what they have done with [21:45] chakra and because it's really they're [21:46] both really excellent solutions to a [21:48] very hard problem and the questions will [21:50] be come are we sure we can't get any [21:52] faster But continuing on of course we [21:54] can make it faster that's a we can [21:57] always make St the faster it's just a m [21:59] of matter of throwing resources at it U [22:02] so I don't think it's that's a u that's [22:05] a sure answer on that one but if you can [22:07] make so so if you can make JavaScript [22:09] faster let's say you have infinite [22:11] number of resources right people always [22:13] say that about Microsoft sure just throw [22:15] another thousand developers on it you [22:16] guys have all billions of dollars in the [22:18] bank but you know in reality so let's [22:21] but you know in some sense if you can [22:23] get [22:24] faster um and the language doesn't have [22:27] to get better [22:29] to me that's seems like a waste of [22:31] that's a waste of time is what you're [22:32] really saying I mean why doesn't the [22:34] language just grow up to meet its needs [22:36] right everyone's writing these giant [22:38] applications in JavaScript a language [22:40] that wasn't designed for that I mean it [22:42] wasn't no Brandon's the first person to [22:44] tell you I have no idea would ever turn [22:46] into this this is crazy so it has and [22:50] now you have to deal with it one way to [22:51] deal with that is to develop a beautiful [22:55] alternative you know a brand new [22:56] language with really modern or some old [22:59] things of course you threw some small uh [23:01] you have that really interesting isolate [23:02] model and the me it's interesting it's [23:04] very interesting model that's one way [23:07] but it's completely new yeah you have [23:08] these thousands and thousands of [23:10] developers that are already writing in a [23:12] very different context so it's going to [23:14] be like bringing people to D from C++ [23:17] it's going to take time even though D is [23:18] a beautiful language but we'll see if [23:21] that actually happens the code base for [23:23] C++ is just insurmountably large now um [23:27] in this case this is why I'm asking you [23:28] have these two very different approaches [23:30] at the end of the day the goal is to [23:32] make developers more productive right [23:34] and in big projects and that's what we [23:36] mentioned from the on that's one of the [23:37] goals that's one of the goals [23:40] um because you know the on the [23:43] typescript side it doesn't actually [23:45] change the semantics of the actual [23:47] language or doesn't make it safer or [23:49] more robust right type typescript is [23:52] purely a tooling thing you know and and [23:54] and and it all goes away at runtime [23:56] right where where where Dart is well [23:59] well large described but there's a VM [24:01] there yes and it's it's a different it's [24:03] a it's a different design point right AB [24:05] so yeah well we can also we also [24:08] preserve the same semantics of DT when [24:11] you translate to uh to Deco but it's [24:13] more strict in terms of that it's [24:15] certainly closer than Java or C and yeah [24:18] you know like like GWT and script shop [24:21] for example yeah you know so but I think [24:23] one thing the [24:25] um um it's still important to talk about [24:28] the optional typing uh at least for for [24:30] for for for thatt I haven't looked or I [24:33] haven't tried the the uh the typescript [24:35] that much uh but in that right one of [24:37] the design points for the optional [24:39] typing was to make sure that when you do [24:42] experimentation inside the [24:44] browser uh you could do that without [24:46] being bothered by types which is great [24:48] because then you can in the debug you [24:50] can just evaluate expressions uh as if [24:52] it was on type yeah and as U as you [24:55] develop the application in the in a [24:57] prototype state stage we can just ignore [24:59] the types and as you as you get more [25:00] structure on your program and your [25:02] interfaces you you you sprinkle in the [25:04] types where it makes the code more [25:06] readable uh and makes it sort of usable [25:08] by other teams so uh that's also uh one [25:11] of the reasons why the optional static [25:13] types are put in that and I think the if [25:16] you contrast the these web programming [25:18] languages to more uh traditional [25:20] programming languages like uh C and Java [25:24] they completely missed the boat when it [25:25] comes to incremental execution and I [25:27] think [25:28] uh we just need to face that this is an [25:30] important part of uh of web development [25:33] that you get instant gratification when [25:35] you do web apps yeah no it it it it is [25:38] interesting both with art and with [25:40] typescript that that um that there's [25:43] this space in between statically typed [25:45] and dynamically typed where where these [25:47] languages allow you to dial it to to [25:49] where where you want to be if you don't [25:51] put any type annotations then you're [25:53] just running in the dynamic world and [25:55] then you know certainly in typescript [25:57] it's basically JavaScript at that point [25:59] but if you start adding type annotations [26:01] then we will statically check those and [26:03] and make inferences based on those such [26:05] that we can infer further types and and [26:07] carry those forward um and and thereby [26:11] you know the tooling lights up and we [26:13] get you code completion and whatever we [26:15] get you error checking red squigglies [26:17] blah blah blah um one of the difference [26:20] I believe is that the in dot uh objects [26:23] carry one type type information so you [26:25] can actually do verification of the type [26:27] as you run if you use a special flag [26:29] you'll basically check that the [26:32] assignments obey the types at run time M [26:36] uh so if you have a piece of code that's [26:38] mixed mode like part of the code is [26:40] untied and part of the code is typed we [26:43] make sure that when you pass objects [26:45] from the on type code into the type part [26:47] add run typ will actually obey the the [26:50] uh the types okay um I think that uh [26:54] that gets harder when it's only a tool [26:56] unless you generat special sure now and [26:58] we we have considered having a a debug [27:01] mode where we inject more checks based [27:04] on the static type annotations which [27:06] currently is not there um and that will [27:09] add cost no no doubt about it I mean [27:12] like trying to verify that a function [27:14] object actually has these three [27:16] parameters that you think it has is [27:19] non-trivial uh checking that something [27:21] implements an interface you know means [27:23] you got to go gravel through all the [27:24] properties and see that the right ones [27:25] are there and and then turn if their [27:28] functions you need to see you know [27:30] that's that's cheaper in D Absol I I I [27:34] have no doubt it's cheaper in D yeah [27:36] yeah cuz it sure ain't cheap in in in [27:39] JavaScript but Bas you cannot do it [27:40] right because the you can never you can [27:42] never do all of it no but the question [27:44] is whether whether it matters enough you [27:47] know I mean that that that's at the I [27:48] mean because everything has me it's not [27:51] see the difference here is like like in [27:54] a in [27:56] an let's say you took away types in a [27:59] language like C for example you took [28:01] away function prototypes like go back to [28:03] before and CC right okay um you if you [28:07] called the function with the wrong [28:08] arguments your stack would get out of [28:10] alignment and your machine would go [28:12] haywire and start executing the [28:13] characters on the screen or or whatever [28:15] weird weird stuff would happen right [28:17] that doesn't happen in in the JavaScript [28:20] world there's a welldefined behavior for [28:24] everything there's a well- defined [28:25] behavior for calling a function with too [28:27] few AR ments or with too many you know [28:29] now you may not like what the well well- [28:31] defined behavior is but it's not going [28:33] to go do bad things in the same sense [28:36] you know we [28:37] agree it's a a safe execution [28:40] environment is what you're saying we [28:41] should understand the I think one point [28:43] is here that let's assume you have two [28:45] teams one team is doing a library where [28:48] they sprinkle types uh static Types on [28:50] the interface and you have another team [28:53] trying to use that Library [28:56] uh the the fact that you can validate [28:59] the types when you cross uh into that [29:02] Library means that uh you don't have to [29:05] debug the other person's code if it's [29:07] correct right you can see it at the [29:08] interface level if it breaks down so [29:11] certainly it has value that you do that [29:13] I understand the safe execution [29:14] environment but it'll basically amount [29:17] to um that deep down in the other [29:20] Library that's type you get a an error [29:22] or by the way in JavaScript I didn't [29:25] know if people are following that uh [29:28] um often you don't get errors so if you [29:30] get if you have a spilling error right [29:32] you try to access a field or is not [29:35] there right it just keeps on trucking [29:38] mhm uh yes and this is Javascript thing [29:42] yeah well so I'm just saying that uh [29:44] Keep Calm and Carry On which is fine I [29:47] don't have a that was the intent of the [29:49] design I assume uh uh but again if you [29:53] run untyped in uh uh in Jos script where [29:57] you have these peculiarities that are as [29:59] a developer hard to cope with because [30:01] you don't if you don't uh check there as [30:04] a spelling error right the program will [30:05] never execute the if statement trying to [30:07] check that property like a common one is [30:10] like the ready State uh for for an event [30:13] handler if if you have that all [30:15] lowercase right it just plows through [30:17] and nothing happens uh in that what we [30:20] tried to do as part of the foundation of [30:23] that is that if you try to access um a [30:27] property or invoke a function or a [30:30] function is probably wrong but access a [30:32] property and it's not in the object you [30:34] will get an exception that point uh so [30:38] that you during development can actually [30:40] see something is wrong and that will [30:42] certainly catch it earlier than if you [30:44] just keep on trucking I I think you know [30:46] it it all comes down to [30:48] um static typing is a dial you know and [30:52] you can put the dial in different places [30:54] and there's different cost Associated [30:56] you know both for pain for the [30:57] programmer and cost at runtime and so [31:00] forth with the with the different [31:01] settings and there are there's there's a [31:03] certain threshold Beyond which it will [31:05] not make sense anymore for JavaScript [31:07] because it just gets too expensive you [31:09] know to try to to verify um but I I do [31:12] think that that I I will say I I think [31:14] with typescript we're capturing a a a [31:17] good you know 80 90% of of of of the [31:19] meaningful settings on on that dial you [31:22] know um so so I do think there's a lot [31:24] of value there uh but it's not going to [31:26] solve every problem [31:27] known to mankind in JavaScript TPT would [31:31] solve the the two team problem in the [31:33] sense that if you had one team building [31:35] libraries with interfaces and classes [31:37] and then you have another team that has [31:38] to implement the interfaces you do that [31:40] in typescript that hand over a [31:42] typescript file that you then would [31:44] program well I I think what it right the [31:47] the thing well the thing that I I think [31:49] has has been lacking for for large [31:52] JavaScript development is a an agreed [31:55] upon way to reason about libraries how [31:58] do I know what's in this library and how [32:01] do I know what's in this other library [32:03] and how can I in the same language [32:06] reason about this versus that and are [32:09] they compatible are they not how do I [32:11] document them and and you know today [32:14] it's it's very at hoc right if I'm using [32:16] jQuery I got to go to their website and [32:18] sort of gravel through one kind of [32:20] documentation then I if I'm mixing it [32:22] with Note then there's some other kind [32:24] of documentation that uses a different [32:26] vernacular and and or and and plus [32:29] there's really nothing there that you [32:31] know programmers forget to document a [32:33] few things or there's this undefined [32:35] Behavior or it's very at hoc right and [32:38] and and I think the thing that's useful [32:40] about you know having the ability to [32:42] write down these static type definitions [32:44] and and annotate them with documentation [32:47] is that it gives you a place [32:49] to say what it is and have something [32:52] validate that what you what you made [32:54] actually is what you said it is it ows [32:57] you to sleep better at night then have [32:59] greater confidence that uh that your app [33:01] will work uh you know when when you [33:02] actually like deploy it so and the [33:05] interesting story there is what you say [33:07] it is isn't really actually what it is [33:10] when you define is at runtime which I [33:13] think it's which is but but it solves [33:15] the core problem of being able to at [33:17] design time understand what it is yes [33:20] whereas that runtime it's still just [33:22] JavaScript right and I think that's the [33:25] one of the really cool well I I think [33:27] you know what what we've tried to do not [33:29] what we tried what we have done in in in [33:31] in typescript is basically formalize a [33:33] static type system that that mirrors the [33:36] dynamic type system of JavaScript and we [33:38] and we have really worked very hard to [33:41] stay true to that you know that it it [33:42] really is javascript's type system and [33:45] there are no new Concepts per per per se [33:48] you know absolutely yeah a little get [33:50] through my head after a while this is [33:51] the third time we we've communicated but [33:53] I think a lot of people are still going [33:55] to have that sort of cognitive to [33:57] disconnect between the fact that it is [33:59] just JavaScript and you've added this [34:01] type system on top of it a thin one well [34:03] it is when it runs yeah exactly but at [34:05] the end that's what really matters at [34:06] runtime that's what I so rock and roll I [34:10] mean uh but we also didn't know a [34:11] JavaScript and run P jscript so so that [34:14] can be translated too so the only differ [34:17] so so the big difference is I would say [34:19] h about that it's certainly much easier [34:21] in typescript because of the tight [34:23] integration with jscript to to enter uh [34:27] to to interoperate with other libraries [34:30] I'm fully aware of that but as we as we [34:32] also heard during this conference that [34:34] some websites they download a a a [34:37] boatload of functions when they start up [34:39] and they only run a few percent of the [34:42] the functions right with uh is a pain [34:44] for download time and so on so one thing [34:47] I want to uh just talk about uh uh about [34:50] with that is also that because it's more [34:53] structured right uh also compared to uh [34:55] to typescript we can actually do [34:57] analysis on the complete program and do [34:59] tree shaking and throw out methods we [35:02] can prove that are not being executed so [35:04] that the deployment of either the [35:07] generated josp code or the snapshot we [35:10] have on the VM will be minimal right [35:14] that's much harder to do in jospt [35:15] because when you glue it in with [35:16] existing jospt libraries you cannot do [35:19] that analysis because uh you do keyed [35:22] access on an object and it's basically [35:24] uh the key you use can be [35:27] a a composed string and what have you so [35:29] it's very hard to do that analysis uh [35:31] because of the lack of structure in [35:33] JavaScript regardless whether you put [35:35] typescript on top no I'm curious [35:37] actually about the tree shaking so [35:39] so but that only works if everything is [35:42] statically typed then right I mean if [35:43] you have anything that's dynamically [35:45] typed then how how do you know whether [35:47] you're going to be calling a particular [35:48] method or not well for instance uh if [35:51] you know that the identify fu is not [35:54] being used it's anywhere anywhere I see [35:57] yes and uh that's certainly the the [35:59] simplest form of tre Shing and it works [36:01] amazingly well right so but what you do [36:04] is you do uh you certainly do type [36:06] inferencing while you do uh tree shaking [36:08] where you start with the either the main [36:10] method or uh the way you hook it up to [36:12] the DOR and then you just plow through [36:15] no I know do that and it actually works [36:17] it reduces a lot of the code being [36:20] deployed and that's what big companies [36:22] want when they deploy a web app they [36:23] don't want all the stuff that's not [36:24] being executed of course sure mhm so [36:27] that's a way of doing that and we [36:28] actually do this the same on top of [36:30] jospt at Google uh by specifying sort of [36:33] pseudotypes and comment so we can we [36:36] figure out how how stuff is uh uh is [36:39] connected but that's only if you use a [36:41] JavaScript in a certain way so all the [36:43] code has to be written in a clean way so [36:45] you know exactly how uh the [36:47] interdependencies of the program are [36:50] yeah interesting and could could you do [36:53] something like that in typescript I mean [36:55] since you have that [36:59] we could do lots of different things if [37:02] we yeah absolutely I I don't see why we [37:05] I I don't think there's any fundamental [37:07] difference there we have not built a a [37:09] tree Shaker and certainly tree [37:11] shaking there there are certain things [37:13] we would not be able to to tree Shake [37:15] right we'd be able to tree Shake [37:16] typescript code we probably wouldn't be [37:18] able to Tre Shake JavaScript code so [37:20] something like jQuery or whatever it's [37:22] it's not clear that that one could tree [37:25] Shake That um you know but but I I will [37:30] say that that uh the thing that we find [37:33] that people do with with typescript is [37:35] that um they use it at development time [37:38] to provide a better development [37:40] experience and then they they then they [37:42] get this data verification you know all [37:43] of the the code completion etc etc then [37:46] they compile to JavaScript and then they [37:48] use other JavaScript tools like [37:51] minifiers uh packagers Etc you know if [37:54] if you're using required JS they're [37:56] tools to package AMD modules together [37:58] and so so it just is part of a of a tool [38:02] chain right and in that tool chain there [38:04] are certain tools that will that will [38:06] try to shake your your JavaScript code [38:08] too um and you know some can do some [38:10] things and others can do other things so [38:12] so I think you know at the end of the [38:14] day I don't think either neither Dart [38:16] nor typescript will ever do everything [38:19] that anyone will want in that tool chain [38:21] right so you're general statement but uh [38:24] of course not yeah yeah [38:27] but what the I still want to get back to [38:29] that if you integrate if you take a [38:31] library that's written for JavaScript [38:34] and mix that with uh typescript I this [38:38] claim that tree shaking is very very [38:40] hard because you cannot compute what's [38:42] being [38:43] called um you can try but uh it turns [38:46] out if you deploy something and suddenly [38:48] uh taking out too much right you're in [38:50] trouble because then you don't preserve [38:51] the semantics that's one of the benefits [38:53] by having a [38:55] uh uh a more structured language for the [38:58] whole thing then you can do tree shaking [39:01] and uh I'll still guarantee that uh that [39:04] we can we can do a small competition who [39:06] can do better tree shaking but I can [39:08] guarantee you I'm [39:10] ohed better hand yeah yeah for sure but [39:14] then but of course you have a completely [39:17] distinct language yes and your own [39:19] virtual machine on purpose so it's not [39:21] by accident we have that no no no I [39:23] understand but I think that this is an [39:24] interesting topic because it's you know [39:26] there really isn't a this or that here [39:30] right you got I mean it's not Dart or [39:32] typescript typescript is uh it's as [39:35] Andrew was saying it's a a small shell [39:37] on top of an already existing tool chain [39:40] called JavaScript and all everything [39:41] that comes along with that whereas yours [39:43] is more of a let's rethink how we do [39:46] this from the ground up so that's a it's [39:48] a very different thing the core problem [39:50] is that both of everybody has to face is [39:53] Javascript is what people use and when [39:56] when you use JavaScript you're [39:57] guaranteed it can run everywhere without [40:00] having to install a virtual machine yes [40:02] so but but that takes but that's a [40:03] Stockholm syndrome right if you always [40:05] look backwards you don't innovate so in [40:08] in my mind so the argument about oh we [40:10] don't so when we did V8 right it was [40:12] like why do we need fast performance all [40:13] the programs are running fine I just [40:15] that's stupidity right so it all boils [40:18] down to that if you don't innovate try [40:20] something new right the application [40:21] developers cannot innovate and this is [40:24] what we're trying right understood yeah [40:26] nobody's saying that what you're trying [40:27] is not a good idea that's what I'm [40:29] trying to get at the typescript is not [40:32] something versus Dart versus dart at all [40:34] they're very different things I'm very [40:36] happy about typescript I think anything [40:39] that tries to innovate in the webs space [40:41] is great and uh it's not something that [40:44] if you do that we cannot do the other I [40:46] think there's room for uh for several [40:49] Solutions and there's already now it's [40:51] not like this is the the only two new [40:53] languages for the web right there's tons [40:55] of them already [40:57] translated to jospt so the more the [40:59] merrier because at the end of the day [41:01] it'll be the programmers out there that [41:03] will make the decision what kind of [41:05] language you can use and if you look [41:07] back 20 years it was exactly the same [41:09] there'll be a a lot of language to [41:12] choose from and uh please do not [41:15] shoehorn develops into only using one [41:17] language yes and that that's not I think [41:20] what anyone does and I mean languages [41:22] are tools they're Tools in a toolbox the [41:25] web is the runtime so we people need to [41:27] figure out how to take best advantage of [41:29] of what's really happening around us and [41:31] both of you are doing fantastic work so [41:34] yeah so I just want to say that right so [41:37] uh that U like typescript the DAT is [41:40] completely open yes we have a virtual [41:41] machine we can transl jope right one of [41:44] the reasons why we uh we open source [41:46] that also the word machine is of course [41:49] that when we show this nice property of [41:52] running do pro program we want everybody [41:54] to take it if they like it right so we [41:57] are certainly not trying to uh to come [41:59] up with a proprietary of Technology here [42:01] we're trying to sort of uh free the web [42:04] basically understood and you know just [42:07] to to do the counterbalance typescript [42:09] is also open source and runs everywhere [42:12] and it's not about only us it in Visual [42:13] Studio in fact yesterday they shipped [42:16] three uh you can run it in the v in VI [42:19] you can run it in uh emac you can run it [42:22] in uh web I can't remember the name of [42:24] the other one but they went out with [42:26] just more than just visual studio and [42:27] running on windows so I think everybody [42:30] is into that same mindset and it's it's [42:32] cool to see these innovative solutions [42:34] very different though they are no I'm [42:37] I'm I'm I'm certainly excited about the [42:38] the uh the open source stuff I was just [42:40] like like right before we sat down I was [42:42] looking there were like nine Forks [42:43] created out of out of the typescript [42:46] depot already so uh so yeah yeah can't [42:48] wait to see what ensues cool and I can't [42:50] wait to have this conversation again [42:52] maybe next year and to see where we are [42:54] in this in this web world that be great [42:56] we hope we are we are both in the [42:58] business in a year totally will be great [43:02] work you guys thanks [43:03] for it's important it's great [43:08] [Music] [43:12] cheers