Hacker News new | ask | show | jobs
by awesomepeter 1926 days ago
If you had to pick a multiplatform solution (for whatever reason) which one would you pick? I've been exploring this space a bit, and it's really hard to form an opinion on this.
4 comments

I've been in that situation 3 times, I choose React Native and Flutter each once. I was forced to use Ionic. I would NEVER use Ionic again, terrible experience and very difficult to get decent quality/performance. I like Flutter's technology much more. I like that it is natively compiled. I dislike that it has it's own UI toolkit. React Native with TypeScript is a highly productive environment but I LOATHED the developer experience and any code that had performance goals was way harder to be successful with, not impossible but the threading model that RN imposes (it doesn't really thread at all) was hard to make the UI snappy and crisp as it should be. I've played with Xamarin also since I was a .net dev for 10+ years (I'm old in the industry 25 years now) and the developer experience was actually pretty good but the compile times and the UI performance were not. Though that was not a production level app and I might have been able to make it work.

tldr; If I HAD to do cross platform I'd use the following logic to choice one: If I have a team of react JS/TS devs: React Native else if I have a .net team: Xaramin else: Flutter

Then I'd apply for a job writing native apps in Swift/Kotlin and run away ;)

Sorry to hear you had a bad experience with Ionic. The stack has improved considerably in recent years and actually Capacitor, our replacement for Cordova, was just rated the highest satisfaction mobile tool on the latest State of JS survey. Cordova was definitely a sore spot for Us but we’ve since moved beyond that and you can use any web stack to build apps with Capacitor (seeing a lot of React + Next.js apps of late)
Out of curiosity, what version of Ionic were you using?

Ionic 4+ is a complete rewrite from the ground up to use web components.

I use it in a non-traditional way, I do vanilla js + lit-html + web components and it works great.

Performance is smooth, mobile first approach makes responsive apps straightforward.

I don't do any of the native things or command line app creation or any of that.

I've been generally pleased with it.

> a job writing native apps

Sadly, a shrinking market day by day.

This area is one that I've been pondering for a long time. In my view, the most sensible approach is to abstract the entire UI and write to the abstracted UI. Then you write the translation piece in whatever toolkit(s) and platform(s) you care about (and in whatever language is most appropriate). This hard separation of the platform and toolkit opens the door for some nice benefits (cross platform being the first and most obvious).

However, the benefits don't need to stop with cross-platform. By adding location independence to the non-application part of the code, you get the flexibility to decide later (even after the application is written) whether to deploy it as a "fat" app (application logic running locally) or "thin" (UI commands and events routed over network to your app running on a server).

I've been experimenting with these ideas for years and it's all doable. I've done various UI/toolkit implementations such as: Cocoa/ObjC, Gtk/C++, wxWidgets/C++, win32/C++, Delphi VCL/Pascal, HTML/JS, Java Swing, Java SWT, etc.

I look forward to being able to share publicly (once I decide which license to use).

If if a CRUD frontend for data, just go with mobile Web.

If doing games, Unity.

If I require some native access, Xamarin.

Finally, using C++ in a MVVM approach with native Views for anything else.

Those answers are for personal projects, at work we just do mobile Web, and with Chrome and Chrome Edge teams pushing the agenda of Web APIs =~ ChromeOS, we get to do most of the stuff we care about.

If you know the native platforms then Xamarin.Native. Shared business logic, platform-specific UI. Over time create your own Xamarin.Forms like DSL to do shared UI.