Why I Killed My DSL Parser for Raw DEX Compilation

When I first built JetStart, the goal was simple: make Android UI development fast. I started with a DSL (Domain Specific Language) approach. I parsed Kotlin-like syntax, mapped it to Compose UI elements, and sent a JSON payload to the app to render. It worked, and it was fast—but it wasn't real.

Developers hit a wall the moment they needed to use their own custom state, complex animations, or third-party Compose libraries. The DSL approach was too brittle, too restrictive, and ultimately, a dead end for a serious developer tool.

So, I made a hard pivot.

The Pivot to DEX

Instead of faking it with a DSL, I decided to compile the actual Kotlin code. Here is how the new architecture works:

1. KotlinCompiler: JetStart uses kotlinc with the Compose compiler plugin to compile your .kt files into Java .class files.
2. DexGenerator: It passes those .class files through Android's d8 tool to create raw classes.dex bytecode.
3. WebSocket Push: This base64 DEX payload is streamed to the connected Android device over our custom WebSocket protocol.
4. Live Injection: A custom ClassLoader on the device loads the new classes instantly. The UI recomposes with the new logic—no full app rebuild, no re-installation.

The Result: Real Compose, Sub-100ms

By dropping the DSL and embracing true Kotlin Compilation + DEX generation, JetStart now supports any valid @Composable function. You aren't writing "JetStart Code" anymore; you're writing pure Android code, but experiencing a Web-like hot reload speed.

It’s instantly injected. It’s real Compose. It’s the Android development experience I’ve always wanted. Have you tried it yet? Let me know what you think on Discord or X!