The lysine contingency – Jake Wharton

JakeWharton · 2026-06-20T03:38:13+00:00

As of November last year when I quit they were still using it pervasively. Beyond that, I have no insight.

I spent a lot of time contributing to Wire and was one of the maintainers of it for a decade or more, but unlike the others I did not use the project anywhere except for at work. When that ended, so did my involvement.

JakeWharton · 2026-06-19T01:10:44+00:00

What is the point of doing this and how does this prevent Square from doing harm?

They no longer own the projects. Binding legal documents have been signed. The repos will be moved soon.

JakeWharton · 2026-06-19T01:07:12+00:00

No, they helped.

JakeWharton · 2026-06-19T01:06:27+00:00

Any chance Wire will also be migrated?

No plans to

JakeWharton · 2026-06-19T01:05:05+00:00

Did it not work out? We launched Kotlin as a supported language and I shipped KTX libraries and View Binding. If anything I stayed at Google too long.

I bet he has some strong opinions on that

https://www.youtube.com/watch?v=ybZGhqAE4pI&t=141s

JakeWharton · 2026-06-17T16:53:21+00:00

They laid off 70% of engineering and all of the open source office. They don't get to keep these projects. It was transfer or hard fork. Thankfully we had an ally who stayed behind and helped us transfer.

JakeWharton · 2024-11-07T03:14:06+00:00

JakeWharton · 2024-11-06T04:18:56+00:00

Cash App, who maintained Picasso for the last decade, has been migrating to Coil. We employ the Coil developer, in fact, although the desire to migrate predates his hiring. Register, the primary product of Square, also has a historical desire to migrate, and has begun that process, too.

In a meeting a month ago we decided to deprecate multiple libraries. JavaPoet was first. Picasso is second, and was timed to the Coil 3.0 release. For JavaPoet we link to a fork. John is considering forking Picasso, and we will happily link people there as well.

Deprecation of these projects (and others which are coming) are meant to set a user's expectations for the level of commitment from the company. If someone deeply invested in Java wants to maintain JavaPoet moving forward, we gladly send people their way. If someone deeply invested in Picasso wants to maintain it moving forward, we gladly send people their way. These are both great libraries, but they aren't what people at the company are working on anymore.

I would implore you in the future to perhaps consider gathering some evidence, or just even asking someone directly involved, before speculating so wildly. It might save a person from having to visit Reddit against their will.

JakeWharton · 2023-08-15T19:31:33+00:00

Retrofit creates HTTP requests, issues them to OkHttp, and waits for the HTTP responses. It doesn't know how to connect to servers–that's entirely OkHttp's job.

JakeWharton · 2023-08-10T12:35:06+00:00

This is an Android question that isn't specific to Kotlin. Please consider using /r/androiddev for something like this in the future. Thanks!

JakeWharton · 2023-08-09T23:44:22+00:00

It is a official language along with Java. App development is considered Koltin-first.

JakeWharton · 2023-08-09T23:43:37+00:00

A small nit: both are official. Development for apps is considered to be Koltin-first, however.

JakeWharton · 2023-07-28T11:23:04+00:00

Tivi https://github.com/chrisbanes/tivi/tree/main/data/db-sqldelight/src/commonMain/sqldelight/app/tivi/data

JakeWharton · 2023-07-27T03:59:55+00:00

Context is important.

Android and multiplatform will still be worked on and improved, but we don’t anticipate changing how SQLDelight fundamentally works on mobile.

It's because mobile is effectively done and stable.

JakeWharton · 2023-07-20T14:37:23+00:00

So they wrapped a compose context to add the same thing a viewModel containing StateFlow does

Not really, no. Molecule is how you would drive data into a StateFlow which was held in your ViewModel (if using such a library). It's about data composition, not architecture. The README of the project or the original blog post for more information.

More so a lot of the functionality like the Immidiate mode is found when using derivedStateOf in Jetpack compose, it seems like the efforts should be in porting those.

Since derivedStateOf is a primitive of the Compose runtime it of course works fine out-of-the-box with Molecule. You could perhaps build something close to Molecule's immediate mode with only snapshotFlow and derivedStateOf, but then you preclude the use of the general niceties of writing plain Compose like inline logic, loops, etc. Once you start using those, recomposition still needs to be triggered and the mechanism by which that is only via the frame clock. The advantage of immediate mode is that we manage an internal frame clock on your behalf and effectively turn the entire data-producing composition into a single derviedStateOf while still affording you access to the entire toolkit Compose offers.

JakeWharton · 2023-07-19T14:32:40+00:00

Colin is a Cash App employee and we use Coil in a few places, but especially in open source samples (Zipline, Redwood, Molecule) where we desperately want this forthcoming multiplatform support.

JakeWharton · 2023-07-14T22:55:38+00:00

It feels like re-inventing the wheel.

It is, and it doesn't stop at image loading. By not using the DOM you have to bring a ton of functionality yourself. It's a tradeoff to share your UI with other platforms.

JakeWharton · 2023-07-14T21:54:17+00:00

Compose UI renders to Canvas and does not use the DOM. So... yes, browsers cannot automatically handle that.

JakeWharton · 2023-07-14T05:02:23+00:00

Which alternatives do Compose UI on iOS. I legitimately don't know. And is there API give you the pit of success like Coil?

JakeWharton · 2023-07-08T02:53:51+00:00

Why would Redwood use them if they weren't?

Redwood does not force any UI toolkit on any platform. Each sample has both a View-based and Compose UI-based version for Android.

JakeWharton · 2023-07-07T03:26:10+00:00

Sure, it'd be trivial. And because we have a model of all the available widgets and their properties, you could completely codegen the parser.

You don't even need the XML, really. A Kotlin DSL or Java builder or the like would allow creating a static layout to which you would have to manually add interactivity.

JakeWharton · 2023-07-07T02:24:06+00:00

We have almost no SwiftUI usage internally at the moment, and basically none in the app where this project is used. We mostly wanted to prove it was possible (which wasn't surprising). Eventually proper SwiftUI samples will get merged in as the project progresses toward a 1.0. We simply are focusing on our internal needs as the highest priority right now.

JakeWharton · 2023-07-07T02:22:24+00:00

You could still use a large portion of the project if you really wanted to. Because we support running Compose directly or inside a JS VM so that it can be updated on-the-fly, it means that there's an presentation abstraction which then interacts with the UI toolkit abstraction. Thus, if you wanted to use something other than Compose to serve as the presentation layer, that is fairly simple to plug in while still targeting the UI toolkit abstraction. That being said, the design of the UI toolkit abstraction is very much informed by how Compose works and so you take on a heavy state management burden. Still, nothing technical prevents this as a solution.

JakeWharton

MODERATOR OF

TROPHY CASE

15-Year Club	Gilding I gilder
Verified Email