marcprux

> I’m not convinced by leptos’s html style view macro. It’s cute, but you lose out on autocomplete and other IDE integration.

Yes, that was exactly my thinking. In addition to more natural IDE support, relying on plain-old-Rust and not having a macro-processed DSL for the view specification makes it more comprehensible for LLM-driven development and testing (since the agents will likely know how to write correct Rust, but struggle with a bespoke DSL that it hasn't been trained on).

> Leptos signals are Send. You can write to them from other threads.

That's nice — I wasn't aware of that. Day's is main-thread-only, which is currently a significant limitation. I'll definitely look closer at leptos’s reactive_graph for ideas.

> You're also using SwiftUI's layout, while I'm leaning on taffy instead for css-style flexbox / grid layout support. I'd love to know more about the deep tradeoffs going on here.

I was tempted by Taffy, since it is very mature and widely-used, but ultimately chose to have the clankers implement something homespun for Day. One of the major reasons was that I can have fine-grained control over the measure passes for optimization. Measuring is cheap for most platforms, but Android (for example) requires a FFI hop via JNI to communicate back and forth between Rust and Android's Java SDK, and that can be quite expensive. So being able to control how these requests are batched together and optimized was important for getting good performance there (and also potentially for ArkUI and other platforms that don't have C/C++/ObjC bridges directly into their UI frameworks).

More broadly, though, I feel like Day's SwiftUI-style "parent proposes size, child decides" paradigm is better suited for native components, which tend to have more non-negotiable requirements for many of their control sizes and layout.

> Write and post about it - this is cool!

Yes, I plan to!

I see two nines in there…

> I have very mixed feelings about Standard Ebooks[…]

Why?

Perhaps. And yet … 98% opposition from 4K respondents? I'd be very surprised to see any other poll that tilts the other way, regardless of sampling bias.

I am part of the team running keepandroidopen.org and corralling the signatures for the open letter opposing this program. We've been trying to get Google to reverse course on this program ever since it was announced.

As it stands, Android Developer Verification (ADV) is a death sentence for F-Droid, Obtainium, and other competitors to the Google Play Store, both commercial and non-commercial. We are disappointed that they are still trying to steamroll this through in the face of overwhelming public opposition.

There are numerous reasons to object to the program, but a few of the top ones are:

1. You own your computer, and you should be the sole decision-maker for what software you can install on it.

2. "Malware" means whatever Google says it means, and their terms and conditions change daily; today malware is banking scams, tomorrow it is … ad-blocking? VPNs? Their decisions are un-reviewable and opaque, and they have obvious commercial incentives to block certain kinds of (otherwise-legal) software.

3. Centralizing global developer registrations through a US corporation makes it subject to the rules (and whims) of the current regime. Citizens of sanctioned countries or members of sanctioned entities (like the International Criminal Court) will be legally barred from registering, blocking them from creating and distributing software _anywhere_ in the world (not just the US).

4. Scenarios that Google claims ADV will protect against — such as high-pressure phone calls manipulating vulnerable users into installing scam apps — have _already_ been addressed by incremental improvements to Android security over the years, such as "Enhanced Fraud Protection" introduced in Android 13 (and expanded in Android 15). Android has incrementally improved its security features over its near 20 years of existence. There is no evidence that anything has suddenly changed to justify such a disproportionate and extreme lockdown.

5. Being required to pay Google for the privilege of uploading your government identification so that you might be permitted to contribute to the Android software ecosystem is such an abominable insult to the developers that helped build the platform. It deserves all the utter contempt that has been heaped upon it thus far, and begs regulatory scrutiny from those few countries that still have the courage to stand up to these bullies.

We emphatically recommend against developers signing up for this program or endorsing it in any way.