Ask HN: How are you building cross-platform (mobile and browser) apps?

It's the third time I have to build the whole stack (web+ios+android).

For the first time, I used a webapp and was hoping that the ios/android experience would be good enough. Unfortunately, It wasn't and it was a big mistake. I'd only recommend this for quick mvp knowing that it'll need to be rewritten or if your audience really understand what it means to have a mobile webapp compared to a native app. I.e. if there's an IT department in place that can install it on the devices and understand the limitations.

For the second time, we went with ionic/phonegap. It was a huge improvement, but we hit too many limitations and scenarios where we wanted native tweaking for animations or handling the keyboard hiding fields or the topbar acting weird, etc. You don't see those issues at first.. but they start appearing as you start doing QA on more devices and with real users. And at that point, you've invested so much in trying to make it work that you can't just go back, so you start piling weird hacks on top of weird hacks.

For the third time, we went with react-native. Overall it was a great experience and unlike ionic, it's a real native app, not just a webview. We could reuse a big part of the code between web, ios and android. The issues we faced were often related to weird edge cases that are buggy within react-native itself such as input fields not working correctly when dictating or a "pull-to-refresh" supposed to be stateless but in practice being stateful and buggy if you call "refresh" on it twice within 30ms. However, it's a good feeling to know that when we'll have the time, we have the flexibility to either fix the library itself or re-write it (compared to ionic where we couldn't do much and web apps where the solution to most our problems would be to "wait a few years until the browsers decide to improve it".)

If I had to do it another time (a fourth time), I'd go with react-native again but I would make sure to stress test the libraries with real data on all the devices we'd want to support. Also, it's popular in the javascript ecosystem to have libraries that depend of another library that depends of another library that wraps another library.. in most cases, it's just better to write a quick wrapper for your app and only include the inner-most library that does most of the work anyway. Otherwise you're depending on too many authors and libraries quickly go out-of-sync and you're stuck with old versions that aren't compatible with new ones.

For JQBX the styling is done differently between mobile and web. I stared off using scss for web (old habits die hard) and then had to use JS styling for react-native. Not the biggest deal though since the UI is where the two apps diverge the most. Very few things use the exact same UI patterns between web and native. But if I were to do it again (and had a design laid out in advance) I would probably opt for JS-styled components across both versions- though the "CSS" syntax is a little different so you would need some way to port that. I think it still makes a bit of sense to keep styling separate between web and mobile though since you're dealing w/ a different interface... but like everything it depends on what you're building.

Pure html+css with as little js as possible...

eg: websites/single page webapps over native ios/android apps

How does it handle Electron apps? I thought playing with EXPO was a limited venture?

You can share JzvaScript code without having to use a framework. Both iOS and Android let you run JavaScript within a native app.