之前有人说这次开发者大会华为可能会发布很多人期待已久的仓颉编程语言，很遗憾的是，华为很显然并没有公开，倒是发布了这个大家既熟悉又可能陌生的ArkTS编程语言——用于鸿蒙OS应用开发的编程语言。

       虽然仓颉语言预热了几年，不过还是只存在于我们大多数人的想象中，而这款编程语言则不然，不声不响，不知不觉润物细无声就成了鸿蒙OS应用开发语言。可能有人会觉得奇怪，这是什么编程语言呢？

     如果你知道eTS语言可能就知道它了。如果不知道eTS语言，那么如果你知道TS（也就是TypeScript）基本也知道它了。

     eTS是扩展的TS语言，而ArkTS同样是在TS语言基础上，配合ArkUI框架，扩展了声明式UI、状态管理等相应的能力，让开发者以更简洁、更自然的方式开发跨端应用。这样，我们也就清楚了华为eTS和ArKTS之间的区别关系，ArKTS就是eTS的升级版！

     在以前版本的鸿蒙OS应用开发中，eTS已经被广泛应用，相信很多应用开发者用的就是eTS语言开发的鸿蒙应用，而此次，只不过是升级更新，所以严谨一点，ArkTS并非首次公布，而是以一种全新的姿态被公布。

兼容JS/TS语言生态，加上现代化的声明式语法和设计新趋势，一次开发，多端部署，让ArkTS语言开发鸿蒙OS应用行云流水。看ArkTS语言一马当先高歌猛进的势态，大众的鸿蒙OS的应用开发语言大抵不会易主了，就是不知道以后的仓颉语言，会以一种什么样的姿态和定位公开和发展呢？自公布华为在打造自己的开发语言以来，直至今日，仓颉语言依然没有呱呱坠地。话又说回来了，用于打通鸿蒙系统和欧拉系统的仓颉语言，可能是一种更通用也更能应对各种场景的新型语言吧。

    为什么华为会选择ArKTS作为自己的主要开发语言呢？我们从harmonyOS应用开发官网的一篇文章就能得到解答《浅析ArkTS的起源和演进》。以下是相关内容的摘要，可以知道华为自身对鸿蒙操作系统开发语言的选择的一些考虑。

     Mozilla创造了JS，Microsoft创建了TS，Huawei进一步推出了ArkTS。

JS语言由Mozilla创造，最初主要是为了解决页面中的逻辑交互问题，它和HTML（负责页面内容）、CSS（负责页面布局和样式）共同组成了Web页面/应用开发的基础。随着Web和浏览器的普及，以及Node.js进一步将JS扩展到了浏览器以外的环境，JS语言得到了飞速的发展。在2015年相关的标准组织ECMA发布了一个主要的版本ECMAScript 6（简称ES6），这个版本具备了较为完整的语言能力，包括类（Class）、模块（Module）、相关的语言基础API增强（Map/Set等）、箭头函数（Arrow Function）等。从2015年开始，ECMA每年都会发布一个标准版本，比如ES2016/ES2017/ES2018等，JS语言越来越成熟。

随着JS生态的发展，如何更有效地支撑大型的应用工程开发变成了一个重要的课题。大型的应用工程一般会涉及较复杂的代码以及较多的团队协作，对语言的规范性，模块的复用性、扩展性以及相关的开发工具都提出了更高的要求。为此，Microsoft在JS的基础上，创建了TS语言，并在2014年正式发布了1.0版本。在工具层面，TS也有相应的编辑器、编译器、IDE（Integrated Development Environment）插件等相关的工具，来进一步提升开发效率。

TS在兼容JS生态方面也做了较好的平衡，TS应用通过相应编译器可以编译出纯JS应用，可以在标准的JS引擎上运行。同时，TS定位为JS的超集，即JS应用也是合法的TS应用。此外，在标准层面上，TS兼容ECMA的相应标准，并维护那些还未成为ECMA标准的新特性。

基于JS的前端框架以及TS的引入，进一步提升了应用开发效率，但依然存在一些不足。

从开发者维度来看：

写一个应用需要了解三种语言（JS/TS、HTML和CSS）。这对Web开发者相对友好，但对非Web开发者来说，负担较重。

从运行时维度来看：

在语言运行时方面，尽管TS有了类型的加持，但也只是用于编译时检查，然后通过TS Compiler转成JS，运行时引擎还是无法利用到基于类型系统的优化。

在渲染方面，主流Web引擎由于本身复杂度以及历史原因，性能、资源占用方面与常见OS原生框架都有一定的差距，尤其在移动平台上。React Native通过渲染架构的改进一定程度上提升了性能体验，但在平台渲染效果和能力的一致性，以及JS语言性能等方面还是存在一定的不足。

Google在2018年底推出的Flutter则走了另外一条路，结合新的语言Dart，引入新的声明式开发范式，基于Skia的自绘制引擎构建可跨平台的独立的渲染能力。这是一种较为创新的方案，不过也有几点不足：

Dart语言生态。尽管Dart语言2011年就已推出，传闻其目标是取代JS，但整个生态还是非常弱小，Dart语言发布7年后随着Flutter的推出才有所改善。整体而言，Dart和主流语言生态相比还是有非常大的差距。

开发范式。Flutter暴露了很多细粒度的Widget接口，整体开发的简洁度，开发门槛，尤其是和Apple推出的SwiftUI相比，存在一定的差距。

   有意思的是，Google在2021年又推出了新的开发框架Jetpack Compose，结合了Kotlin的语言生态，设计了新的声明式UI开发范式。

    2019年，我们在思考如何构建新的应用开发框架的时候，从以下几个维度进行了重点考虑：

语言生态

开发效率

性能体验

跨设备/跨平台能力

    由于JS/TS有比较完善的开发者生态，语言也比较中立友好，有相应的标准组织可以逐步演进，JS/TS语言成了比较自然的选择。以JS/TS为基础，在开发框架的维度，我们做了如下的架构演进设计：

   通过基于JS扩展的类Web开发范式，来支持主流的前端开发方式。同步的，在运行时方面，通过渲染引擎的增强（平台无关的自绘制机制、声明式UI后端设计、动态布局/多态UI组件等），语言编译器和运行时的优化增强（代码预编译、高效FFI-Foreign Function Interface、引擎极小化等），进一步提升相关的性能体验，并可部署到不同设备上（包括百KB级内存的轻量设备）。另外，通过平台适配层的设计，构建了跨OS平台的基础设施。

   总体而言，ArkUI开发框架通过扩展成熟语言、结合语法糖或者语言原生的元编程能力、以及UI组件、状态管理等方面设计了统一的UI开发范式，结合原生语言能力共同完成应用开发。这些构成了当前ArkTS基于TS的主要扩展。

   接下来，除UI框架需求之外，ArkTS也会结合应用开发及运行的其他方面需求持续演进：

1. 更完善的类型系统

    我们已经设计并实现了专门运行时，利用ArkTS的类型输入，在程序执行一开始就获得较高的运行性能（不像其它传统JS引擎需要预热才能获取高性能）。但是目前的类型系统在运行时的设计上仍然考虑了兼容模式，即在运行时，当对象类型发生变化时会走Bailout机制，以使程序在类型不匹配时仍能正常运行。一种更极致的方式是：引入一种特定模式来支持确定类型的表达，当开发者可以明确类型时，提供相应的信息，这样运行时可以通过针对性设计，进一步提升性能体验。另外，ArkTS将来也会在类型系统中拓展一些新的类型，在与运行时结合的优化中会提供更好的性能体验。

   当然，ArkTS以及ArkUI开发框架还很年轻，还有很多其它方面也会持续演进，比如UI自定义能力的进一步完善，语言运行时以及跨语言交互的进一步优化，跨OS平台能力的扩展，分布式开发范式等等。

 作为应用生态的底座，应用开发框架的创新永无止境。我们希望和广大的开发者一起，持续围绕着开发效率、运行体验、跨设备/跨平台等相关方面一起合作，一起创新，共建繁荣的应用生态。