Hacker News Reader

With the utmost respect to the gargantuan levels of effort put in by hundreds of developers:

I've never worked with tools where I had to guess/pray every morning "Will my app compile and run today?" until I worked with React Native.

Seemingly randomly my apps would not build and I had to waste entire days chasing down random Github issues and comments in unrelated packages to get things running. I have never since experienced something like that either.

I'm thankful that I don't have to work with React Native anymore. Even my younger brother has given up and just bit the bullet to work exclusively with Swift natively for mobile apps.

Again, with all due respect. :pray:

> I've never worked with tools where I had to guess/pray every morning "Will my app compile and run today?" until I worked with React Native.

Happened to me building a Kivy Android app using Buildozer. That marked the end of my use of Kivy and Buildozer. I really want to use Python to build apps, but not as much as I want to not randomly have apps suddenly refusing to build out of the blue, and Kotlin is a damn nice language.

The problem with Flutter is Dart. I considered it for a cross-platform project for my company, but ruled it out because it uses a language that essentially nobody knows. And when I say nobody, remember that the real world (and the contractors available in it) is not Hacker News.

I wish Google would settle on a language or two and stop with the seemingly endless parade of new ones. Kotlin for mobile, and ? for everything else. Or just... Kotlin.

Fortunately dart is fairly predicatable. It does few special things and they're all very approachable for anyone familiar with the other gc'ed oop languages(java, c# etc.). While I wish it had some more useful features, its mundanity was a big boon when picking it up.

The main reason for Kotlin's recent popularity is from its use on Android. Not that long ago it wasn't all that popular while many jvm better-than-java languages were competing. Same for Go.

If a substantial amount of Android (or other/cross-platform) dev happens with Flutter, Dart will become just as common. As a language, it's not great, but it's also not bad either.

Except the little detail that Android team couldn't care less about Dart/Flutter, it isn't even part of the official Android SDK.

Jake Wharton has a few rants about the Fluter/Dart vs Android politics.

It's true that Kotlin wasn't a breakout success 5 years ago. However, I would argue Kotlin's design decisions made it destined for its current success, whereas Dart has not.

The most obvious of this was same-build compatibility with Java. Mixing Kotlin and Java made it super easy to switch, and made using it a no-brainer vs other solutions. Android Studio also has a button that auto-converts Java to Kotlin, so in many cases a wholesale rewrite isn't even necessary.

At this point, Kotlin has also become a goto for backend Java for stream processing and other open-source JVM projects. It's rapidly replacing things like Scala for Flink, as an example.

Maybe Dart survives by the sheer force of will of Flutter, but I don't think there's a chance it catches Kotlin.

Kotlin also seems very similar to Swift, which is handy. The last time I saw the topic debated on this site, the consensus was that native is still the best way to go when developing mobile apps, even when you have to support both iOS and Android.

By native on Android you mean the 'widgets' APIs meaning Kotlin is fine (not the NDK with C/C++) I assume.

It takes an hour at most to grasp most of dart if you know java/typescript.

The problem with flutter is lack of high quality libraries. Jank. And finally, flutter web not being good enough yet.

Thanks. I don't know Javascript or Typescript, and nobody else among our developers did either. I know Swift and C++, and our products' firmware and other software is written in C++.

It's not that grasping it would be hard. It's just that nobody has time to dick around with it and making tooling for it. We ended up using Qt and constructing the UI in QML, which worked out quite well for a cross-platform desktop app. Still haven't tried mobile with it.

I use react native and I enjoy it, and I agree.

My biggest fear is running fine … and then when compiled something different. And it happens.

For “simple” apps I’m very happy with react native. I can’t say enough good things about it there … but I’m really nervous (especially as the primary developer) as if I’ve got this debugging black hole/ sword of damocles hanging around.

For web developers who want to hit both app stores I still highly recommend it. But with the note that you want to be deliberate about changes / know about that black hole.

Yep. Also, the decision is different when you don't use the app store for distribution.

I know lots of niche business-specific use cases where they don't care if it crashes half the time. If you need something on mobile quickly for a narrow use case, RN / Ionic can be your friend.

You nailed it, if we had a framework that took flutters approach but let you build in typescript or kotlin things would look a lot more appealing for cross platform dev.

Webapp beats native now IMO.

The antitrust pressure on apple is forcing the last holdout (iOS Safari) to step into line.

We've got our B2B customers using web apps on iPads managed via MDM solutions right now. Camera, location, push, Home Screen icon, etc all working flawlessly.

It took us almost 3 years to get to this point, but it's very stable now.

I agree you still need App Store presence for B2C, but there are paths here too with vanilla web stacks.

Webapp beating native is a stretch.

It’s getting there. Look up react-native-web, tamagui, and solito. Almost all the code is shared between web, iOS, and Android and the web experience feels like a native app[0].

0. https://tamagui.dev

Is there a specific use case you have in mind that would be infeasible to do as a web app? I'd even be interested in arguments about poor UX, because a lot of this has been resolved recently.

Top of my mind. Discovery, apart from devs (even that is a stretch), when I say app people quickly open play store/app store. When I say you just gotta click add to the home screen. They're like, you don't have an app? Isn't that just a failure of UX? I once tried to convince a founder so hard to go with webapp, I gave every advantage I could think of, then in our survey not one of our users was comfortable, they all weirded out. But hey web app works if it's forced like in a enterprise or MDM setting, but people would rather open app stores. Despite the flak, consumers trust app stores at some level than a random website, even if its more secure since it can't access a lot of APIs, but they don't know that. Every framework ionic, flutter etc I've tried since Cordova has had some weird feel to it. I can quickly recognize a webapp packaged as native in the first two mins, most of the users I worked with just think it's slow or janky since they Don't understand it's a webapp vs native.

Depends on app. I'm still waiting for web browsers to implement a way to schedule local notifications at specific time.

Agreed re: B2B, but I've looked at a handful of the Webapp / PWA solutions for B2C app store and it's still pretty far away.

B2C users really demand a consistent experience despite the state of the device, and it's hard to get a web stack to do this well. Logical offline behavior is one, but even things like the click response being slightly too slow vs native UI can turn people off.

Beyond that, you hit the same problem with RN / Ionic: Native plugins don't work as well, native support isn't there, and it becomes very hard to debug. This is especially true if you "present" the app to the user as native but use a web stack. For a website in a browser users tend to have patience for things like slow buttons, for native they do not.

As a point of comparison, think about how responsive a game engine can be. That is the user experience people expect on mobile. It's a heavy lift to get web there, and if you don't someone else will build a native experience that will.

I tried Flutter recently. It's so good compared to any other cross platform solution.

Dart is an easy language, but wow I wish they used anything else. It's a big mistake making people adopt a language as well as a framework.

Exactly. I wanted to consider Flutter, but no way could I sell my company (already stretched thin with developer resources) on a platform using a language that nobody (including me) knows and that has essentially no payoff for learning outside this one thing.

Dart is pretty straightforward, but there are some idiomatic concepts you need to get just to get started. Laying out a View and updating values is the most obvious one, but also how startup and libraries integrate also comes to mind.

The biggest problem with Dart is that it looks nothing like other UI languages ... by design. It ostensibly was supposed to be a uniform UI layout language, but it suffers from the "XKCD standards" [1] problem of now making its own decisions with no basis for comparison.

To code a cross platform app, you already likely need to know Objective C, Swift, Kotlin, Java, and/or JS. If you do Unity, you need C#. Dart looks like none of these, and is at best half-loved by Google as much as say, Go.

I almost want to just spend time writing a Kotlin -> Dart compiler, but I feel like that would make the problem worse. "Now we have 16 standards".

[1] https://xkcd.com/927/

Maybe someone then will make dart to kotlin transpiler and port whole flutter to kotlin? I seen unity framework that ported pretty much whole flutter to c#/unity

Flutter’s demo app is roughly 70MB in APK size, our native production app is around 20MB.

Yep, this is a problem that Flutter shares with Unity: It's BYO(everything) and not at all APK optimized. You use native, Android won't re-download libraries that are already on the device. Drops your APK size, increases your rankings.

FWIW, Apple doesn't care as much, and their users are used to it, so that's a plus I suppose.

Not the same but also related: Using RN and Ionic can just destroy battery life and CPU for apps because you are essentially running a full JS engine on top of all the native stuff. This can cause them to get aggressively killed when backgrounded and / or punished in other ways.

Yes, but in a country where internet is very expensive. This is a dealbreaker.

Debug builds are big. Production releases of Apps are very small - one of my Flutter Apps 7.6 MB.

Sure you checking the right build? Production builds are usually much smaller in size than debug builds. I had a complicated app that was only 20 MB in production, but like 300 MB in debug.