In 1995 I installed CorelDRAW 5 from a CD-ROM on my family’s 486. I was full of anticipation for the entire hour that it took to upgrade from CorelDRAW 4. Colours were gaining an alpha channel!
Slow upgrades like this one set the pace for the 1990s software industry. If the released code was buggy, users were stuck with buggy software indefinitely! The permanence of bugs motivated an exhaustive Quality Assurance (QA) process. And that QA process in turn required development teams to split their work into release and development branches.
Today, web applications can achieve significantly higher shipping velocity:
Continuous deployment says that instead of treating releases as labour-intensive ceremonies, they should be fully automated and performed frequently, even on every code change. Every user should always experience the latest version of the software.
Branch by abstraction says that instead of developing new features on branches in version control, the new features belong in the customer-facing release branch. We should instead use feature flags to hide works in progress. There is always a unique current version of the software.
Always-current client code accelerates iteration cycles on server code too. Instead of maintaining last year’s APIs for last year’s clients, backend developers can aggressively tear down old APIs because old clients don’t exist. You can work more incrementally when change is fast!
But most of today’s desktop and mobile apps are stuck in the 1990s: the release process is expensive and users can get stuck on old versions.
We want the web platform’s velocity for our other client platforms! So we’ve been exploring ways to make that happen.
Zipline is a new open-source library that supports always-current code in Kotlin programs. It lets you write features and business logic in Kotlin and ship them to users without a conventional app update. It can hot-reload code without restarting the application.
It integrates several technologies:
Kotlin Multiplatform is Zipline’s foundation. It serves as our conventionally-deployed host platform (either Kotlin/JVM or Kotlin/Native), and our always-current guest platform (Kotlin/JS).
Kotlin Serialization is used by Zipline to bridge interfaces and objects between the host and guest code. Instead of using an external interface definition language, just put shared types.
QuickJS is our execution engine. It’s fast, stable, and has extensibility hooks that support several powerful features in Zipline.
Today I’m excited to announce Zipline 1.0! We’ve stabilized our application packaging format, our API bridging protocol, and our public APIs. See the project homepage for documentation and code samples.
Note that JavaScript is strictly an implementation detail of Zipline. Users of Zipline only see Kotlin! We plan to switch to WebAssembly as our dynamic code platform once Kotlin support is stable and we’ve found a suitable engine. We’re already calling that project ‘Zipline 2.0’.
No comments:
Post a Comment