ArkTS 的目标是成为一种“高性能的现代应用开发语言”，它在保持 Web 开发体验的同时，正坚定地向“静态类型语言”靠拢，以换取系统级的执行效率。
1. 为什么 ArkTS 不支持某些动态特性？
TypeScript (TS) 本质上是 JavaScript (JS) 的超集，而 JS 是动态类型的极致代表。ArkTS 选择砍掉某些动态特性（如 with 语句、运行时反射、动态改变对象结构等），核心原因只有一个：性能瓶颈。
性能的“原罪”：JIT vs AOT
JS 的动态性意味着编译器在运行前几乎无法确定变量的类型。为了跑得快，JS 引擎（如 V8）必须依赖 JIT (Just-in-Time) 编译，在运行时一边猜类型一边优化。如果猜错了（De-optimization），性能会断崖式下跌。
ArkTS 的策略是推行 AOT (Ahead-of-Time) 编译。
- 确定性： 通过强制静态类型检查，ArkTS 让编译器在程序运行前就精准知道每个对象的内存布局。
- 内存优化： 不需要像 JS 那样为每个对象携带沉重的元数据。
- 启动速度： 省去了 JIT 预热的过程，这对移动端设备的丝滑感至关重要。
砍掉了什么？
- 禁止动态添加属性： 对象在类定义时就固定了，这让 CPU 可以通过固定偏移量直接访问内存，而不是在哈希表里反复查找。
- 强制类型标注： 杜绝了
any滥用（在严格模式下），减少了运行时的类型检查开销。
2. ArkTS 的设计目标：Web 还是系统级？
ArkTS 的定位非常微妙且具有野心：它是用 Web 语言的“皮”，包裹着系统级语言的“骨”。
它不是纯粹的 Web 语言
虽然它长得像 TS，但它不支持 HTML/CSS，且剔除了大量 JS 的历史包袱。它不运行在浏览器里，而是运行在 ArkCompiler 专门为其优化的运行时上。
它具有系统级语言的特征
ArkTS 的设计目标更接近于 Swift 或 Kotlin：
- 极致性能： 目标是让 UI 渲染和逻辑处理达到原生级别，而非简单的 Web 容器套壳。
- 并发模型： 引入了更高效的并发处理机制（如 TaskPool），而不是 JS 那种相对单薄的 Event Loop。
- 类型安全： 通过严格的静态约束，在开发阶段就拦截掉大部分内存和逻辑错误。
总结定位
我们可以称之为 “声明式高性能应用开发语言” 。
- 对开发者（Web 侧）： 降低门槛。如果你会 TS/JS，你可以无缝上手 ArkTS，享受声明式 UI (ArkUI) 的快感。
- 对系统（HarmonyOS 侧）： 提供可预测的执行效率。它解决了 JS 在嵌入式和移动端系统上“慢”和“费电”的顽疾。
归根结底
ArkTS 是为了解决一个矛盾：如何既能拥有前端开发的极高效率，又能拥有系统级语言的流畅性能？
华为的选择是：保留 TS 的语法外壳，拆掉 JS 的动态内核，通过 AOT 编译在 HarmonyOS 上实现“既要又要”。
