Why Front‑End Developers Find HarmonyOS (arkTS) Development Uncomfortable

When the author first started with HarmonyOS development, arkTS was at API 8; a year later it has progressed to API 12, the beta of HarmonyOS Next, bringing many new, more mature language features.

1. Heavier use of class to define data

In typical front‑end TypeScript, developers often create objects with literal syntax {} and optionally define an interface for typing. arkTS forbids deleting object properties at runtime, so using plain object literals can cause type‑safety errors. The author shows a simple interface Point example and then demonstrates the arkTS‑preferred pattern using a generic class:

interface Point {
  x: number,
  y: number
}

const p: Point = { x: 1, y: 2 }

Because of the strict runtime type checks, the author rewrites the definition as:

class Point<T = number> {
  x: T;
  y: T;
  constructor(x: T, y: T) {
    this.x = x;
    this.y = y;
  }
}

const p = new Point(10, 20);

This approach eliminates the need to separate type and value definitions, but it also means developers must instantiate a class for nested data, as shown in a state‑monitoring example with @State and @Observed decorators.

2. any and unknown are not supported

arkTS enforces strict type safety by disallowing the flexible any and unknown types. Every variable must be given a concrete type, raising the entry barrier for developers accustomed to relying on any in TypeScript.

3. Common JavaScript conveniences are restricted

The language does not support several familiar features:

Spread operator on objects:

const p0: PointPM = { x: 1, y: 2 };
const p = new Point(...p0); // not allowed

Destructuring assignment: const { x } = p0; // not allowed Mapped types:

type OptionsFlags<Type> = {
  [Property in keyof Type]: boolean
}; // not allowed

The author notes that while these omissions feel painful for developers used to them, they are rarely needed in a strictly object‑oriented design.

4. arkTS’s design philosophy – limiting TypeScript’s flexibility

arkTS runs on its own compiler and does not need to preserve JavaScript’s historical quirks. Consequently, it removes many flexible constructs to achieve predictable, type‑safe execution. For example, using this inside ordinary functions is unsupported because the dynamic binding of this conflicts with arkTS’s goal of eliminating runtime uncertainty.

This reduction in flexibility prevents complex type gymnastics and simplifies the type system, albeit at the cost of developer convenience.

5. Summary

Although arkTS builds on TypeScript, its divergent goals make the transition for front‑end developers non‑trivial. Strong typing means every syntax error blocks compilation, unlike TypeScript where code can still run despite type errors. This strictness can lead to more robust code but also raises the learning curve and development effort, especially when handling complex data structures.

6. Takeaways for front‑end teams

Teams can adopt arkTS’s strong‑type mindset in their own TypeScript guidelines, deliberately sacrificing some of TypeScript’s permissive features to lower overall usage difficulty and improve code reliability.