DEV Community

Cover image for Why Build Systems Matter: Ditching Gradle for WebSockets
Elimihele God's favour
Elimihele God's favour

Posted on

Why Build Systems Matter: Ditching Gradle for WebSockets

Gradle is an incredible piece of engineering. It manages complex dependency trees, supports endless plugins, and orchestrates build tasks in a way that scales well for enterprise applications.

But for the inner development loop—the seconds between writing code and seeing the result—Gradle is an obstacle. If you simply want to change a padding value on a Compose UI screen, running a full Gradle evaluation is overkill. The overhead of task execution graphs, even with caching enabled, causes noticeable delays.

The JetStart Solution: Sidestepping Gradle

We realized that to get instant, state-preserving hot reloads on physical Android devices, we couldn't rely on Gradle. We had to build our own compiler pipeline specifically designed for the edit-refresh cycle.

When you run jetstart dev, Gradle is nowhere to be found. Instead, we run a custom Node.js server that binds a file system watcher to your .kt files. When an edit occurs, we run a raw kotlinc command on that singular file. We bypass the build system entirely.

Once kotlinc outputs a Java class, we run d8 to generate DEX bytecode. And because ADB (Android Debug Bridge) is too slow for our needs, we built a WebSocket connection between our dev server and the physical device. The device listens on port 8766 for raw byte arrays and loads them into a custom ClassLoader instantly.

The Best of Both Worlds

We didn't completely kill Gradle—we just put it in its place. When you run jetstart build, we hand the process back to Gradle to compile an APK, manage dependencies, and digitally sign your app.

JetStart gives you the blinding speed of WebSockets for UI work, and the reliable build process of Gradle for production releases. This hybrid approach represents the future of Android development.

Top comments (0)