Kuikly's self-developed DSL initial experience: making UI development simpler and more elegant
Hello, fellow Taoists! In the previous article, we engaged in a "cross platform framework battle" and ultimately chose Kuikly as the destination for our "Lonely Frog" app. So, starting from this article, we officially enter the practical development of the "Lone Frog"!
Before we officially begin, let's talk about Kuikly's UI development approach. If you have previously learned Compose, Flutter, or SwiftUI, then you are definitely not unfamiliar with DSL (Domain Specific Languages). Kuikly also adopts a similar declarative UI development approach, but what's special is that Kuikly supports two DSLs simultaneously:
You may ask, 'Since we already have Kuikly DSL, why support Compose DSL?'? ”
According to Kuikly's official introduction, the Kuikly framework was initially built on a self-developed DSL. This DSL is deeply bound to the framework, providing the ultimate performance and development experience that best fits the framework's characteristics. Introducing Compose DSL is more like embracing a broader developer ecosystem. After all, the declarative UI writing style of Compose has deeply penetrated people's hearts, and providing DSL support for Compose can help developers familiar with Compose get started faster. Especially in the current Vibe Coding era, due to the fact that Compose DSL has more training materials, theoretically the error rate is lower for AI to write. However, in the spirit of learning and exploration, what we will experience first today is the authentic Kuikly DSL.
It should be noted that as of September 2, 2025, Kuikly's open-source Compose DSL is in beta status. =>Kuikly Official Document Description
So, is it really useful to let AI write Kuikly's DSL? What is the difference compared to Compose DSL? Let's take a look together.
My first impression of Kuikly's DSL syntax is that it is concise and intuitive. Let's first take a look at a Hello World written in Kuikly DSL:
internal class HelloWorldPage : Pager() {
override fun body(): ViewBuilder {
return {
attr {
allCenter()
}
Text {
attr {
text("Hello Kuikly")
fontSize(14f)
}
}
}
}
}
How about it? Is it approaching the ideal state of code as documentation, where you can easily understand what this page is for at a glance.
Overall, Kuikly DSL largely borrows syntax from Compose DSL, so if you have experience developing Compose, getting started with Kuikly is almost zero cost. But in some details, Kuikly still made some optimizations and trade-offs of his own. For example, in terms of attribute writing, Kuikly's approach is more concise compared to Composer's Modifier. In terms of layout, Kuikly adopts a layout method that is more in line with web development habits - Flexbox layout, which can directly write the syntax "flex (1f)", which is more familiar to front-end developers or students familiar with RN development.
Just talking without practicing fake moves! Let's go back to the 'Lone Frog' project and see how Kuikly DSL performs in actual projects. Firstly, following the instructions in the official website documentation, let's create a Kuikly template project:
Please note that when selecting DSL, choose "Kuikly" instead of "Compose":
Next, the plugin has generated a simple Kuikly Hello World project for us, which includes directories corresponding to 5 platforms:
ok， The next key point is still to let AI help us achieve the homepage of "lonely frog".
Let's first give AI a detailed prompt, noting that we repeatedly emphasize that Compose DSL cannot be used, otherwise it will always forget ..
In terms of development experience, Kuikly's IDE support is quite good. From project creation to code writing and final capital punishment, the entire process is very smooth and can be completed directly in Android Studio. At the same time, code prompts, syntax highlighting, auto completion, and other functions are all readily available. Of course, what impressed me the most was its cross platform capability. The same set of code can run directly on Android, iOS, H5, HarmonyOS, and mini programs without any modifications.
Of course, no framework is perfect, and Kuikly is no exception. For example, at the beginning, I was a bit uncomfortable with Kuikly's layout style, especially some of its unique layout properties, which required some time to learn and understand. In addition, as Kuikly is still a relatively new framework and the community ecology is not yet fully developed, some questions cannot be found with ready-made answers online and need to be explored by oneself. However, Kuikly's official documents are fairly detailed, and the official technical support is also very awesome.
So, under what circumstances is it recommended to use Kuikly?
New Project: If you want to start a new project from scratch and want it to span multiple platforms, Kuikly is definitely a good choice.
Android Developer: If you are an Android developer and familiar with Kotlin and Compose, getting started with Kuikly is almost seamless.
Pursuing ultimate performance: If you have high requirements for the performance of your application and hope it can rival native applications, then Kuikly's native capital punishment+native rendering solution will satisfy you.
Of course, if your project is already mature, or if your team mainly consists of front-end developers, you may need to evaluate the migration costs and learning curve.
Overall, Kuikly's self-developed DSL has left a very good impression on me. It retains the simplicity and elegance of Compose DSL while optimizing some details, providing a simpler and more intuitive development experience. Of course, as a new framework, Kuikly still has many areas that need improvement, such as relatively weak ecological aspects. Of course, we need more patience in the face of the new framework. I believe that with Kuikly's continuous iteration and the growing community, it should become an undeniable force in cross domain development in the future.