Incentive

On this page good to know when using CSS-in-JS solutions of TypedCSSX.

Ease of introduction

The TypedCSSX mechanism scans and compiles cssx method define using an AST (Abstract Syntax Tree). This allows it to operate in a Node.js environment where TypeScript can be executed. This means it's not dependent on any specific framework.

Concise API

The learning curve is very gentle. It works with zero configuration in Next.js and Vite by default.
All you need to do is install the optimization plugin and just compile with npx typedcssx --compile.

Simple methods

To be able to use the existing className API, the main methods create and set only return strings. The rest are just the root method for writing variables at the root, and the global method for writing globals. The last one is the union method for merging class names.

These are very concise and easy to handle, so you can start writing without much reference to the documentation.

Static style

TypedCSSX does not support dynamic variable embedding. There are several reasons for this.

Avoiding complexity

Implementing complex features significantly reduces the library's performance and user experience. In other words, doing difficult things itself is not favorable for both the library and the developer experience.

And dynamic styles can be easily achieved. Since the same thing can be done by using the existing inline style API to inject dynamic variables, there was actually no need for the library to do it.

By reducing the cost of developing unnecessary APIs, we've naturally been able to keep the library size to a minimum.

Completely definite and static

In TypedCSSX, styles are completely statically determined. This means that CSS is completely absolutely definite at compile time, providing a fully static CSS solution. You can create maintainable, scalable, definite, and easy-to-manage CSS.

This means it's compatible with static site generators and server-side caching strategies.

Pre compilation

TypedCSS's compilation logic is not coupled with the framework's build. The fully independent compilation process does not interfere with the framework's build process, allowing CSS to be safely and deterministically included in the build process.

Ease of debugging

Since all styles are resolved at compile time, runtime uncertainties are completely eliminated. Statically determined CSS allows developers to identify all style issues at compile time.

Performance

By excluding runtime styles, we naturally keep the cost occurrence to "zero runtime". There's no need to calculate or resolve styles at runtime, optimizing performance.

Optimization

Style objects passed across component boundaries are all Tree shaking at build time. This means that even as a result of natural writing, the style object bundle doesn't increase, and only lightweight CSS remains.

Scope range

Scoping is done on a per-method basis. Class names are given a unique id using the method's object. Even if exactly the same method is created between methods, the compiled CSS is always just one.

Collision lottery range

The design of using TypedCSSX objects as hashes for IDs results in collision lottery at the method level, which dramatically reduces the number of lots. For example, if you're converting strings to IDs at the class name level, collisions can occur even within methods. This means that the number of lots increases each time a class name is created.

Class Name readability

The create method takes the key as the class name and gives a 6-character hash of the object at the end. The same object hash and the same key are used in both development and production environments, so you can find them quickly without getting lost when using developer tools.

Universally

Class names are changed by objects, but when objects are determined, class names become universal. Therefore, when methods are determined, class names can be used as CSS arguments (has and not).