I found the if-blocks more concerning than the lack of parentheses. Although I would’ve preferred parentheses for better parity with Kotlin for the if-else blocks (instead of then).

I’d still prefer code over a DSL. In fact, I just like Flutter. Hot reload and no fighting XML-as-a-DSL.

What I mean to say is that Google isn’t invested in native android either. It’s been repeatedly strip mined by first-timers looking for a quick promotion and left to burn.

Things got so bad that Google gave up on native Views and created Jetpack Compose, which has been a source of many complaints related to performance.

In 2024 Flutter has instant hot-reload, and the “native” (but 100% bundled) solution still requires a complete reinstall on the device. In fact, Dart can compile to native code (or JIT) without an issue, yet Kotlin Native is barely in GA in the new compiler support has been lagging while the new compiler isn’t out of beta and is still poorly supported by tooling.

Consider the absurdity: React Native is the only true native framework out of RN, Jetpack Compose, and Flutter. And all of this barely scratches the surface of the tooling problems that Flutter 99% avoids by allowing development on desktop, web or iOS simulator.

It’s really neat how many no_std I’ve seen popping up lately. I’m hoping stuff like Hermit takes off and we can finally stop worrying about Log4Shell or cURL.

I won’t be recommending that anyone use Dart or Flutter on new projects.

You seem to think Google cares at all. Android has been languishing and Flutter is lightyears ahead. KMP is junk compared to what Flutter has accomplished with a fraction of the bells and whistles.

I just hate reading it. I wish it looked more like Kotlin and less like JavaScript 😭

I like the approach Jetbrains has taken with extension libs to add functionality that could’ve been in a bloated standard library.

Wow this is awful on mobile lol

How do you feel about Kotlin?

Here’s a simple approach:

• Basic auth via a custom header, like X-Auth
• JWT auth on Authorization header
• uuid on the JWT (as a claim) that gets stored temporarily (until it expires) to allow the server to revoke the token

Initial request -> server looks for Authorization header, falls back to X-Auth header -> generates JWT and sends back to client in Authorization header (or whatever makes sense)

Subsequent request -> server looks for Authorization header -> checks JWT against revocation database/table and that it isn’t expired

Subsequent request with expired token -> server returns 401, client retries using X-Auth header -> server sends back JWT on Authorization header -> client updates locally-stored JWT for future requests

There are probably ways to make this more standard or optimal, but this is a simple approach.

I worked on a team that did, and it was the second-worst application I’ve ever touched.

How do you feel about line breaks?

I think they mean xcode.

I thought this as well.