Doodle is a Kotlin UI framework that compiles to the web and to the desktop

One language for the interface, on the web and on the desktop

Doodle helps you create modern applications entirely in Kotlin, and the tagline is that you start creating your app for Web and Desktop by defining your View hierarchy and your business logic.

The framing in the README is about a render model that is intuitive yet powerful, making it easy to achieve complex user interfaces with pixel level precision and layouts. The point is that the layout model, the input handling and the animation are all part of the framework rather than assembled from separate pieces, and that the same code can target a browser or a desktop window.

The targets are visible in the badges. Kotlin 2.1.10 is the language version, and the platforms are listed as JS, Wasm and JVM, with the topic list spelling out the multiplatform variants, kotlin-js, kotlin-jvm and kotlin-wasm.

The repository topics also name object-oriented, ui-kit and framework, and the description says pure Kotlin UI framework for the Web and Desktop. There is no JavaScript in the application code, and there is no HTML in the application code either, which is the substance of the claim.

The project is MIT licensed, and it has an API documentation site at nacular.github.io/doodle. The last push to the repository was on 2026-10-09, and the last tagged release is 0.11.5 from 2025-11-26, after 0.11.4 in August 2025 and 0.11.3 the day before that.

The Hello World shows a view, a render block and a display

The example in the README is the whole API in one screen, and it is worth reading line by line because the vocabulary of a Doodle application is different from a component tree in a typical framework.

import io.nacular.doodle.application.Application
import io.nacular.doodle.application.application
import io.nacular.doodle.core.Display
import io.nacular.doodle.core.plusAssign
import io.nacular.doodle.core.view
import io.nacular.doodle.drawing.Color.Companion.Black
import io.nacular.doodle.drawing.text
import org.kodein.di.instance

class HelloWorld(display: Display): Application {
    init {
        display += view {
            size   = display.size
            render = {
                text("Hello, world!", color = Black)
            }
        }
    }

    override fun shutdown() {}
}

fun main() {
    application {
        HelloWorld(display = instance())
    }
}

The structure is an Application subclass that receives a Display, adds a view to it with the plusAssign operator, and sets two properties on that view, the size and the render block. The render block is a lambda that draws, and inside it the text function draws a string with a colour.

Two details stand out. The view is sized to the display rather than laid out by a parent, which is what pixel level precision means here, and the application is launched through an application function that takes a lambda, with the Display injected through Kodein, a dependency injection container, since the import is org.kodein.di.instance. The result is that a Doodle application is a class, an Application subclass, rather than a set of annotated functions.

For a Kotlin developer the whole shape is idiomatic. For a web developer used to a virtual DOM and components, the render block is the part that takes a moment, because the drawing is explicit rather than derived from a tree.

The repository is a set of modules, not a single artifact

The top level of the tree is organised by concern rather than by package, and the directory names describe the pieces of the framework.

Core/ is the framework itself, with the application and view machinery. Controls/ holds the interactive parts, the things a user can click or type into. Themes/ is the styling layer, Animation/ is the animation support, and there are separate Browser/ and Desktop/ modules, which is what makes the same code run in a browser tab and in a desktop window.

The build is Gradle, with a settings.gradle.kts, a build.gradle.kts, a gradle.properties, a buildSrc/ directory, the gradlew wrapper and a gradle/ directory, plus a .kotlin-js-store/ directory for the JavaScript side of the multiplatform build.

That module split is a good sign for a framework at this stage, because it means the rendering back ends are separable from the core. A change to how a view is drawn does not have to touch the controls, and the web and desktop shells are separate from both.

The docs/ directory holds the documentation source, and the logo-icon.svg and logo-icon assets at the root are the only other non build files. The licence is the MIT licence, and the README links the licence badge at the repository under the pusolito organisation, which is a leftover from before the move.

The links still point at pusolito, which tells you the move is recent

There is a small detail in the README that is worth a paragraph of its own, because it is the kind of thing that wastes an afternoon when you are about to file an issue.

The repository itself is nacular/doodle, and the API documentation lives at nacular.github.io/doodle, and the tutorials live at nacular.github.io/doodle-tutorials. But the licence badge points at github.com/pusolito/doodle, and the issues link points at github.com/pusolito/doodle/issues, and the README asks you to report issues there.

So the project has moved from the pusolito organisation to nacular, and the README has been partly updated. The issue tracker, the documentation site and the code are in three different places, and the one you are most likely to need, the issue tracker, is still the old one.

That is a small thing and it is normal for a project that has just changed its home, but it is exactly the kind of detail a reader should know before they spend time reproducing a bug against a repository that may not be the current one.

The community channels are current, though. There is a #doodle channel on the Kotlin Slack, with instructions for getting an invitation, and the documentation site has the tutorials that the README points to as the place to start.

Under active development, and the README says so

The README does not oversell the project, and the sentence that matters is short. Doodle is still under active development, so there are going to be gaps and bugs, and the project asks you to report issues and submit feature requests.

For a framework that replaces your entire user interface layer, that caveat is more consequential than it is for a library that does one thing. A gap in a framework is not a missing function, it is a shape you did not expect, and the difference in cost between a small gap and a large one is a day.

The release history supports reading the project as pre 1.0. The version numbers are 0.11.3, 0.11.4 and 0.11.5, with two of those three in August 2025 and the third in November 2025, and the last push in October 2026. A 0.x version is a signal that the API can still change.

The documentation is where the project puts its effort, with an API site and a separate tutorials site, and the README makes both the starting point for a new user. The tutorials are the more useful of the two for judging the framework, because they show complete applications rather than isolated functions.

Where Doodle is the wrong choice

Three situations rule it out.

The first is a project that only has one target. The value of a multiplatform framework is amortised over the platforms you ship. If your application is web only, or desktop only, and you are happy with the standard toolkit for that platform, then Doodle replaces a well documented set of components with a 0.x framework whose README warns about gaps and bugs. You are paying for a second target you do not have.

The second is a team that needs a broad component library today. A framework with Core, Controls, Themes, Animation, Browser and Desktop modules is a foundation, and a foundation is what you build a library on top of. If you need a data grid, a date picker, a tree view and a file browser, you are assembling those yourself or you are waiting, and the README does not claim otherwise.

The third is a mobile project. The documented targets are the web and the desktop, and the topic list names the JVM, JS and Wasm targets, with no mention of a mobile platform. A Kotlin Multiplatform framework that also targeted mobile would be a different and much larger undertaking, and nothing in the repository suggests that is where this is going.

For a Kotlin team that genuinely has both a desktop and a web product, or that wants the whole application, including the front end, in one language, the framework's proposition is strong and the documentation is better than most projects at version 0.11.

Editorial conclusion

Doodle fits a Kotlin team that wants one codebase for a desktop tool and its web counterpart without writing the interface twice, or that wants to keep the whole application in Kotlin including the front end. It is the wrong choice if you need a mature component library today, since the README says outright that the project is still under active development with gaps and bugs, and it is the wrong choice if your target platform is a mobile operating system, since the documented targets are the web and the desktop. Before adopting it, read the API documentation and the tutorials at nacular.github.io, and check which platform you actually need, because the framework's value depends on the second target existing.

Frequently asked questions

Official sources

1. License: MIT
2. nacular/doodle on GitHub
3. Project website
4. README
5. Releases