Comment by PragmaticPulp | Hacker News Reader

Comment by PragmaticPulp | Hacker News Reader

Parent Full thread

> I like flutter and would definitely pick it if I had to make a mobile app, but if you have to write a conditional at every step to pick the right component for each platform, I don't see the point of keeping one codebase any more.

I agree that wrapping every single UI widget in conditionals and writing it twice is not a good practice, but I'd still want one codebase.

Any reasonable application architecture will separate UI presentation code from application logic code. You'd still benefit from a single, shared backend to the codebase.

I managed a dual-platform software project a few years ago. I made the call to build native apps for each because our use case didn't work well with the cross-platform tools.

Writing the UI code on each platform was not difficult, but it was surprisingly challenging to make sure the application logic behaved the same on both platforms for every possible edge case. It's easy in a small app, but as complexity grows so do the edge cases. Having a shared codebase, even if the UI code had to be special-cased, wouldn't be too bad.

That said: The app in the article appears to have equivalent layouts for most screens on Mac and Windows. It seems that a single UI library could be constructed to handle both without special-casing every single thing. I'd much rather have a library that made a best-effort guess at the right thing for either platform and then add platform-specific exceptions.

We’ve build app with the business logic in Kotlin: https://kotlinlang.org/lp/mobile/

Yes! OP here, and I fully agree with your comments. Indeed, it should be trivial to make a separate package to handle picking the right UI component for each platform.

And yes, the main advantage of my approach is that I use the exact same business logic in both versions: database calls, models, settings, application behavior are shared in the codebase.

Sure, you can keep things common with one codebase, but why does that codebase have to be flutter? IMO dart is a pretty meh language, and as others have pointed out flutter doesn't even use native controls. There's tons of options for common logic in native apps these days that don't mandate a choice of view layer.

And IMO if you’re going to pick on Flutter, it’s surprising to me that you’d start with Dart. :)

I know JS is a lot better than it was 20 years ago and even half a dozen years ago, but it gave me enough PTSD over the years that compared to using JS for hybrid apps, Dart was such a breath of fresh air when I built my first Flutter app! I felt it made sense and just got out of the way so I could focus on what I wanted my app to do, and I didn’t even have to read any docs to start using it in Android Studio. And this is coming from having a lot of experience with compiled languages and a lot of Ruby in addition to JS.

Oh sure, I wanted to talk more about the "one codebase" idea - and with the state of FFI being what it is today, if you can pick anything, why pick Dart? is my thinking.

And I don't particularly hate Dart. It's fine. I've written a lot of Java so it's not much worse. But if I had free reign to choose, I'd much rather take Rust.

But for most users, do you really think they want to deal with manual memory management like with Rust? It's a UI framework not a backend performance critical one, I don't think Rust would make much sense. Dart is also compiled and gets good enough performance, at least way better than JS which is JIT not compiled to machine code.

Stateful hot reload is pretty awesome when doing UI work. On desktop that is pretty hard to find.

Also, as a TypeScript/Swift/Kotlin person, Dart is fine; sure I’d like algebraic data types but overall it is good. The tooling (auto completion etc) is great. And it has a few cool unique(ish?) features like cascade and every class is an ‘interface’.

Reply on news.ycombinator.com