It is January 9, 2026, early morning.
I just renamed ZEN to CZON. Implemented the AI-generated permanent link feature and removed the previous SHA-256 hash-based URL scheme.
I also created a 404.html page with logic to redirect to the homepage.
In a previous discussion with Thrimbda, I was debating the implementation approach for custom themes—whether to use traditional templating languages like Handlebars or to implement them directly with JSX components. Handlebars (and similar tools like EJS, Jinja, etc.) fall into the category of traditional templating languages. Their advantages are simplicity and ease of use, but they have limited functionality, poor extensibility, and a low ceiling. On the other hand, using JSX components to implement custom themes allows full leverage of the React ecosystem, offering greater flexibility, extensibility, and a higher ceiling, albeit with a steeper learning curve.
But these days, with AI generating everything directly, what’s the point of learning templating languages? It seems meaningless. You only need to look at the code when debugging.
If we use JSX components to implement themes, where should the folder containing JSX components be placed? It seems the only logical place is under the .czon directory, for example, in .czon/themes. This way, users can create their own theme components directly under .czon/themes/{theme-name}.
I think my technical choices lean toward the modern direction. After all, ZEN/CZON primarily targets individual users and small teams, who tend to prefer using modern technology stacks to build and manage their knowledge bases.
So it’s decided—JSX it is! Once themes are implemented with JSX, we can simply call renderToString directly in the CZON CLI.
The next question arises immediately: how should the data layer be designed? How will themes access the framework’s data? How will themes be managed, published, and installed?
There are still many issues to resolve, but I feel the direction is becoming clearer. We’ll make adjustments as we go.
