Hacker News new | past | comments | ask | show | jobs | submit login

I recently tried to start a react native / typescript project, but the ecosystem confused me a lot. The various different tool recommended to create a project, some project templates not even compiling, the tons of different utilities required to process source files.. All that and not a single reliable source of documentation, made me feel it would be a real nightmare to maintain on the long run.

I have the same experience trying to use it myself. And this stacked on top of the mess that the Javascript, Android and iOS worlds themselves already can be sometimes. One of the apps I maintained got rewritten in React Native but I couldn't get it to build. One of the devs stepped in and helped it. "Oh just retry it a few times it'll work eventually" and sure it did.

So apparently the experience never gets really good as opposed to native iOS development where once you get to a certain level you don't spend that much time chasing weird build errors.

You are right. This is part of what made me try Flutter for a new app over RN. While it isn't perfect (no tooling is), the initial user experience is pretty good and the documentation is constantly updated as the product matures.

I used to be into flutter (theorically), but after seeing some bugs and performance issues, i’m now thinking the best combination would be :

- write once and compile all business logic (and server and fs i/o ideally) into a portable independant libray, either in something that compiles to C, or wasm (once it’s more mature)

- write native UI code using native tooling, and call the business logic library from there.

But i haven’t settled yet on the ideal PL to write that library and have it interface easily on both android and ios.

This is the approach we took at my current and previous mobile projects and has proven to be very effective (we chose C++ due to toolchain maturity over all platforms):

- It forces you to think about your business logic vs. UI structure.

- It forces you to make your core logic library easily testable.

- Since you can deploy the core logic library anywhere, you get native, no Electron bullshit, support for pretty much all major operating systems at a cost of running a CI on all compilers to catch non-portable parts of C++ quickly.

- The users get UI that's built for their platform with it's own quirks and doesn't burn 500MB of RAM.

- Using a serializable and portable message standard (we opted for Protobufs) to communicate between logic library and UI part makes deployment to server easy as well.

Biggest issues?

- Getting inflexible people to learn anything other than JavaScript.

- Getting slow compile times under control.

- Getting CI coverage to the point where it catches developers accidentally adding Apple or Linux specific headers into codebase.

- Learning to be conservative enough to not trust the platform and ship our own libraries. Even basic ones like SQLite.

> no Electron bullshit

Electron is a UI 'framework', so bringing it up is kind of a non sequitur. Your approach of a C++ core is entirely compatible with an Electron UI.

I worked on a project that had its 'core logic' implemented in C++, which we then ran that on the web in Javascript, for the same portability reasons.

how did the java interop work for you ? I used to work in a company that used that approach with gomobile (golang) , and frankly the dark magic required to have a decent java API to the shared library made me want to not touch that with a ten foot pole.

I believe it was due to JNI but my memories may be wrong.

The answer is in the parent's comment. They used protobufs, so I guess there's no JNI, just a simple RPC over a local socket.

Thanks, i completely missed that part. Very interesting solution...

We used Dropbox' Djinni for a long while and it was good for most cases, but there were performance limitations - we switched to protobuffs over byte[] arrays for complex data later.

How do you achieve this? Are you using some framework like Qt? Or is it custom?

As the previous poster mentioned, the UI is all native and written separately for each platform. To populate UI elements you call native calls so there's no UI framework like Qt needed.

We used C++14 which has a pretty good standard library and plugged the holes with some parts of Boost and then standalone libraries like SQLite, json11 and others to provide missing functionality.

I did not have a great experience with that approach. The now (in)famous DropBox article describes why way better than I ever could: https://blogs.dropbox.com/tech/2019/08/the-not-so-hidden-cos... My biggest pain points were tooling. For all of Xcode’s faults, C++ and Objective-C debugging and intermingling wasn’t one of them. Android, though, was another story.

The big thing the Dropbox article does not mention is the fact that they never really ported the Dropbox core functionality to C++ so they never reaped the benefits of sharing code in their most complex and most business logic heavy part of codebase.

We actually used their own Djinni library on one of the projects and it worked well - but even at that time the Dropbox team wasn't maintaining it at all since they never used this approach beyond the short-lived Carousel app.

This is the approach used with Kotlin multiplatform development.

I suspect it will be the best way going forward, other approaches all have serious issues.


I understand they are using the Dart langugage? Was it hard to master?

Super easy if you know JS/TS and turns out that I actually quite like it.

What's missing? TS has quite a few interesting language features that I assume Dart is missing (seems Dart has the reputation of being a Java-like language, with all the boilerplate that that entails).

Probably my largest complaint is the need to use codegen for the json stuff. Sure you can type it all out by hand, but the codegen really does automate a lot of it for you.

I have intentionally kept my very specific use case mobile app very very simple and not gone deep on the magic edge cases. It is a private app and will never be on the store. It is basically used as a QR code scanner to track equipment.

I'm sure that if you have a lot deeper/larger apps you'd find more to complain about, but so far I'm happy enough with going from zero to full fledged app in about a month of work.

IMHO, the boilerplate argument with Java is kind of outdated (Project Lombok and modern java solve a lot of that).

Is that really true? ‘react-native init AppName’ and your ready to go?

What is wrong with react natives official documentation? I think what many mess up(me included) is to look at the wrong version of the documentation. I guess that could be a little bit more obvious.

edir: oh, typescript! Yeah, that is a little bit more troublesome; https://facebook.github.io/react-native/blog/2018/05/07/usin...

>Is that really true? ‘react-native init AppName’ and your ready to go?

If you already know React/Redux/etc, perhaps.

Else "Ready to go" after reading about several concepts, libraries, and systems and getting how the work together, what performance pitfalls they have, etc...

If you would initiate a Swift app or any other for type of app for that matter, what language/frameworks give you a complete solution with state etc done for you.

I guess I’m asking; what other solution have you found that solves everything for you?

If you want to build an iOS app with Swift, the built-in frameworks give you everything you need. Swift as a language, Cocoa Touch (includes Foundation as a kind of standard library and UIKit or SwiftUI for the UI stuff), Xcode for the IDE and build system. There's one source of documentation, Apple, and there's years of third-party documentation all over the internet.

You can bring in libraries of course, but even for a large iOS project it's unlikely (and probably unnecessary) to have more than a handful.

My point wasn't from someone who expects the language/environment to "solve everything".

It was from someone familiar with GUI programming, who wants to try doing it in React Native and suddenly finds tons of new concepts to keep in mind (compared to common native GUI frameworks/libs).

> edir: oh, typescript! Yeah, that is a little bit more troublesome;

So appending '--typescript' is troublesome and not obvious? Like this?

react-native init AppName --typescript

That's it. I never knew in 2019 that adding an extra flag would be 'troublesome'. The description of your installation of a React Native and TypeScript project in 2018+ is greatly exaggerated.

According to the article, there are caveats.m, I don’t know, therefore I linked to the article.

Is the flag generating a project that works without anymore tweaking/setting up? If so, my reference to the blog is not accurate.

Also, a better reply would be “oh that article is not accurate anymore, now everything is setup for you I’d you add this flag!”

You are not wrong. It is a nightmare to maintain, and if you already took the leap you best keep that project updated as soon as possible or you will be fucked beyond repair.

There has to be a better way to write mobile applications. Is that Ionic? I don't know.

If you’re going to remain within Apple platforms, try SwiftUi:


There may be a chance of it being adapted for other platforms in the future.

i highly doubt apple will port that to android, so unless they open source the technology...

It uses standard (or about to be standard) Swift language features, mainly the ability to write DSLs.

Maybe other developers who really really love Swift and SwiftUI might port it to their preferred platforms. :)

> It uses standard (or about to be standard) Swift language features, mainly the ability to write DSLs.

that’s not the hard part, and apple knows it ^_^

it will be interesting when/if someone manages to get something close to apples implementation working, though my guess is they will have a “not fun” time trying to reimplement every ui interaction satisfactorily...

Ionic is quite decent, though can become sluggish once your app grows in complexity (even with lazy loading) if you're not careful.

Flutter looks interesting, going to check it out.

In the end one wants a true "write once, run everywhere" framework, not write the business logic and then write the UI 3+ times for each target platform. Ionic delivers on this front, but am curious to see if Flutter takes it to another level (blazing fast dev/reload cycles and native performance in production sound quite appealing).

Just came from trying Ionic, it now has ehmmm vanilla Cordova, Ionic Cordova and then there's Capacitor. They're all sort of compatible in terms of commands and application structure so it's pretty easy to screw stuff up if you end up in the wrong docs. At other moments you really do need to dip into vanilla Cordova using Ionic or Capacitor.

Seriously, take a stab at building an app in Flutter.

Agreed, I switched to Flutter from React Native. Although I don't particularly like Dart lang, everything just works way better on Flutter.

Never had performance issues on scroll ? The demo app on the ios app store has lagging scroll performance for a simple app on an iphone X

I don't have any pages that scroll. =) It is all single pages for now.

That said, who knows what the demo app was done with. If there is lagging scroll performance, it could be a lot of things.

I will say that figuring out where the performance problems are would be pretty enjoyable in IDEA. The tooling there for performance is quite good.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact