20 ms·

React Native is not the future

280 points by samwillis 4y ago

matchbok 4y ago
With the right libraries and clean code, going native for iOS/Android is usually the solution. Building UI/networking/etc quickly in Swift/Kotlin just isn't an issue anymore. RN/Flutter won't be used in 5 years.
- Ian_Macharia 4y ago
  Strongly disagree. Both frameworks save on dev time to a very significant degree. I actually foresee better cross platform solutions being introduced in 5 years
  - ericlewis 4y ago
    I don't agree, and I have worked with this significantly as a consultant and core contributor to react-native. What typically happens is people convince themselves what you are saying is true then there ends up being huge delays to spin up all the infra app side... THEN eventually, they kinda are okay. until the next react-native release. edit: would like to clarify that of course I would recommend better ways... but... clients do as clients do.
    - tested23 4y ago
      You are looking at this with hindsight bias and are assuming that for some reason the future will remain the same as the past. There are no fundamental reasons why ios and android development occur with two different ui frameworks in two different languages. With low interest rates companies will not be able to justify paying 3x to maintain 3 different apps when they could theoretically just pay 1x for one app that works everywhere
      - turdprincess 4y ago
        The key word here is “theoretically”. These cross platform solutions are great in theory - who wouldn’t want to share code across all platforms? It’s a great sell, especially to the folks holding the purse. The reality though is it doesn’t work well. The tooling, performance, debugging, library stability and observability are all substantially worse. Your team might save a ton of time spinning up a React Native app, but lose it all right back once you keep hitting gnarly Android performance issues. In the future, once we have a proper cross platform development kit officially supported by Android and Apple, code sharing will be great. But today it doesn’t exist. And that’s why none of (the good) apps you use are written in a cross platform way.
        Apocryphon 4y ago
        Flutter’s development experience is better than RN’s, and perhaps even better frameworks will come in time.
        ericlewis 4y ago
        Hard to leverage JS devs when it's an entirely different language from JS.
        latchkey 4y ago
        Dart really isn't hard to pick up and is surprisingly nice to write code in.
      - Existenceblinks 4y ago
        Good metrics for proposal to VCs .. to steel the cake from native platform overlord. Lets eat the apple and google cake to boost our return margins. Bam! VCs alliance for new scene graph renderer for the web on any device.
        wiseowise 4y ago
        It’s the other way around. Don’t let native overlords eat into our cake.
  - matchbok 4y ago
    For simple apps, maybe. But anything complex still requires native resources and expertise. So the value is greatly diminished.
    - fargo 4y ago
      How would you define a simple app out of curiosity?
    - wiseowise 4y ago
      > But anything complex still requires native resources and expertise. Any examples of simple and complex apps?
- agsnu 4y ago
  I'm just holding out for a Jetpack Compose for iOS :)
  - pixel_tracing 4y ago
    It’s called SwiftUI?
    - wiseowise 4y ago
      > SwiftUI Complete separate toolkit with its own patterns and semantics. I’d rather use one then learn two. https://touchlab.co/compose-ui-for-ios/ https://touchlab.co/compose-ui-for-ios/
      - wiseowise 4y ago
        Than*
    - agsnu 4y ago
      Apple breaks too much stuff in software updates. I want to control what versions of key libraries I'm integrated with and rev them on my own schedule.
  - mike_hearn 4y ago
    It exists: https://touchlab.co/compose-ui-for-ios/ https://touchlab.co/compose-ui-for-ios/
    - mwcampbell 4y ago
      Apparently Jetpack Compose for iOS has zero accessibility support so far, if the Droidcon NYC app is a representative sample. I'm sure that will come; just don't use it yet for anything more important than the iOS version of an Android conference app.
- tested23 4y ago
  Ios and android development as they exist today will die once governments mandate then end of the app store monopolies.
  - myko 4y ago
    There is no Android app store monopoly. You can download apks and install them already. See: https://f-droid.org/ https://f-droid.org/
    - wiseowise 4y ago
      Just as there was no “IE monopoly”, even though you could technically download separate browser.
      - myko 4y ago
        I don't think that works as a metaphor. IE got MS in trouble because it was so embedded into the OS that it was literally required, and MS did everything they could to force users to use it. Android works fine when built from source with no Play Store at all, using F-Droid as the primary store.
  - dmitriid 4y ago
    Ah yes, this mandate will immediately make all APIs across all OSes the same
- jacobp100 4y ago
  Have you tried SwiftUI? It’s not replacing RN any time soon
robertoandred 4y ago
Sounds like he's just inventing a slower, less native version of React Native.
- yawnr 4y ago
  Yeah seriously. Just a worse version of the bridge. IMO the cart is leading the horse on this one. Might be more convenient for their dev team to just have a web codebase (though I’d argue if they took the time to transition their web codebase to react native web they’d see the same benefit), but it will definitely hurt UX.
  - moughxyz 4y ago
    There's no reason it has to hurt UX in theory. The difficulty is just in spending a lot of extra time perfecting the animations and interactions, which is 100% doable. We just released navigation present and dismiss animations a few weeks ago, which feel pretty great imo. They're non-interactive, and again, this will take a lot of extra work you get for free with native, but the tradeoff is worth it for us, and again, amenable.
    - KerrAvon 4y ago
      You seem to be in very heavy denial. This will never be as nice to use as a native app, because you cannot replicate all of the small details of how native UI works on each platform. And say you manage to get close to emulating a native app on one platform — when the OS UI updates, you’ll be behind again. I get that it’s inconvenient/expensive for you to build three UI layers. But that’s the only way to do this well. This was true for cross-platform apps in 1989 and it remains true decades later.
      - locutous 4y ago
        > This will never be as nice to use as a native app, because you cannot replicate all of the small details of how native UI works on each platform. Not sure how much of that is necessary. I mean, a button doesn't "look native", so what? It's a button. Apps written to require network requests to resolve a navigation are much worse than JavaScript handling a user event. > And say you manage to get close to emulating a native app on one platform — when the OS UI updates, you’ll be behind again. Not really the goal. You have this backwards. Keeping up with OS churn is one of the reasons to use an abstraction like this. It doesn't break your app nearly as much. The browser is a much more stable target than native mobile APIs. > I get that it’s inconvenient/expensive for you to build three UI layer. But that’s the only way to do this well. Inconvenient is dramatically understating the case. 3x spend is flat out impossible for many places.
CharlesW 4y ago
> Our new mobile app still uses React Native… The big reveal is that React Native is still their future. TLDR: Their app continues to use React Native, but they've given up on using it to provide a native user experience, and instead just use it to access OS APIs.
- ericlewis 4y ago
  NativeScript would prob suit them better.
- teg4n_ 4y ago
  What they decided to do is really quite strange. Something like Capacitor makes much more sense but they said they wanted access to React Native libraries... I hope https://github.com/OpenNative/open-native https://github.com/OpenNative/open-native can address their requirements in the future. It's goal is to make things like React Native native modules work across frameworks (e.g., react native libraries working in capacitor and native script)
billllll 4y ago
I don't have personal experience with this, but React Native Web claims to solve this issue: https://necolas.github.io/react-native-web/ https://necolas.github.io/react-native-web/, not sure if anyone has had experience with this. Of course, you will have issues with dependency hell/package maintenance. Another great option seems to be Flutter web. I was really impressed by the "batteries included" approach to Flutter, and Dart has a pretty comprehensive standard library. This is in contrast to React's "just find a random package on npm and pray it doesn't bite you in the future." Obviously rewrites are expensive, but I personally think both approaches are worth considering versus abandoning native components completely. WebView isn't without problems (and also, you don't need React Native to use WebView).
- ericlewis 4y ago
  combining RN and RNW is a pain in practice. It can be done, but not easily.
  - phist_mcgee 4y ago
    I've done it. Once you're setup, it really does work quite out of the box. What you do have to be mindful of is clear separation of concerns when designing platform specific components - you have to think in terms of Button.native.ts and Button.web.ts when you're doing things like haptic feedback or animations. The only thing that's really a pain is that react dev tools has a harder time dealing with RNW components, and debugging in general can be a bit of a pain.
    - no_butterscotch 4y ago
      How are you liking it so far? Perf issues or no? Any concise/clear resource or guide you used?
      - phist_mcgee 4y ago
        >How are you liking it so far? Perf issues or no? Perf seems totally within reasonable bounds for a react app, no issues so far. In terms of resources or guides, it's pretty spotty out there. The project has definitely slowed down in terms of dev and i'm not sure where things like react 18 fit into the picture across platform, but we've setup our own config that works just fine for now. We may need to reappraise in 2-3 years if react does change architecturally too much.
marstall 4y ago
this is a cool model and I do something similar (I use native code to render the webview). though I wouldn't describe it as abandoning RN, because I use react-native-web inside that webview. rn-web provides certain features that are crucial for a native feel on mobile, like better coordination of touches within scrollviews.
- sureglymop 4y ago
  Do you have/know any example app to try out?
  - marstall 4y ago
    I don't - but check out WKWebViewController ... and its WKScriptMessageHandler delegate, which lets you receive messages from javascript embedded in the currently viewed page.
mrbombastic 4y ago
One codebase sounds great but I always feel devs try to ignore that there just are significant differences between platforms that you must address if you want a well integrated app. Writing separate codebases in native iOS, Android, and web has a huge amount of waste but you can achieve higher quality and os integration, writing react native and react on web means you get just 2 codebases and higher dev productivity but at the cost of pain in libraries which typically also means less native integration, the solution proposed here means 1 codebase and even less native integration. If it is right for you great but like everything it is tradeoffs, pick your poison.
- danielvaughn 4y ago
  Agreed. Although the economic reality is that it’s borderline impossible for a company to develop a cross-platform native product unless they have significant amounts of money. Cross-platform is a terrible necessity to that end.
  - ericlewis 4y ago
    Eh. Not sure I agree, unless you mean taking a non-native already made react bit and try to turn it into RN.. that is far harder and does require lots of money. too many people don't realize just how non-portable react code can be.
    - danielvaughn 4y ago
      No I mean building a product that works on web, android, and iOS, and has a native experience on all platforms. It’s hard enough to find a good web dev, but it’s far harder to find good iOS and Android devs. It’s a very large and expensive endeavor.
      - ericlewis 4y ago
        It is definitely a challenge, but as prev EM / hiring manager of many iOS / Android devs it certainly isn't impossible. Not sure about large and expensive. Surprisingly most of my best devs were all inbound, not via recruiters. Felt recruiters usually wasted our time and small teams of native devs can get a lot more done than web teams (at least so it seems based on my subjective exp). My previous company had probably well over a dozen web engineers and then for our mobile side we had a total of 3, myself included. We also often had to adapt designs ourselves and work with product to fix flows for native. But we still managed to keep up with web. edit: and not "keep up with web" in the we are working 80 hour weeks type thing, very normal working hours, 9-5. Possibly more normal than the web team.
gigel82 4y ago
*for you It's all about trade-offs; you decided to trade better performance and native look&feel for faster/easier development. Perfectly reasonable, but for others that are making different trade-offs React Native totally is the future. I think RN is a great middle-ground where you get native looking&feeling UX, but still get to share 95%+ of the code across platforms.
sureglymop 4y ago
Tried it out on Android and it feels janky. It just feels like a web app and it's not working well. To just give one example, if I click on the header of a note, a menu with "options" shows up. But Android also selects the text in the header and pops up a menu with "Cut, Copy, Paste, etc." which is exactly on top of that menu I was actually trying to get to...
- moughxyz 4y ago
  Eh, these are easy fixes. We're making progress daily on making it feel more "native" (i.e recently added present/dismiss animations). Try the demo[0] in your mobile browser, should feel pretty smooth. We've tested extensively on a whole range on devices and performance wasn't an issue. It's really the animations (or lack thereof) that make or break perception of "jankiness." What we have now is our first solid functionality-oriented release; next releases focus on tidying up the edges. [0]: https://standardnotes.com/demo https://standardnotes.com/demo
  - foreverCarlos 4y ago
    Depends on the user’s expectations, I guess. The demo you linked does not feel close to native yet. Lots of reflows, small shifts, inconsistent rough animation… even for a web app it’s not smooth enough (iOS Safari)
    - dontlaugh 4y ago
      Indeed, compared to any native app it’s terrible. If you care about UX, you should make native apps.
      - Firmwarrior 4y ago
        You guys are technically correct, but also dead wrong with your outlook They're trying to make a useful app for humans, not trying to win the HackerNews Award for Excellence in UX. If accepting a little unfixable edge case jank makes their goal way easier to attain, they're going to end up with a much better app overall
CosmicBagel 4y ago
As someone who uses this off an on amount, I was really disappointed when I opened the app to the new web app. It was slow, janky, required me authenticating multiple times (biometric then username and password). I'm now looking for alternatives because "as fast as possible" is an important feature for me. I keep the app on my android home row, not because I use it a lot, but because when I need it, I need it instantly. Massive downgrade for the user imo, this only benefits the developer.
- throw03172019 4y ago
  It sounds like they are migrating portions to native first.
teucris 4y ago
So, essentially Phonegap/Cordova again? I always liked that model. I’m not entirely clear why it fell out of favor.
- marpstar 4y ago
  I spent the last 6 years building an Ionic app for “enterprise”. The still-not-native UX is the main reason why it’s not more popular, in my opinion. In our case, our users had little say in their respective organizations’ decisions to buy our product, and “good enough” was still better than what our competitors were offering anyway. We spent a lot of time of time debugging native layer issues, and WebGL bugs that would crash the webview (vector maps using the ArcGIS JS SDK) so it’s not a magic bullet in those respects either.
  - martini333 4y ago
    I agree 100%. Ionic's default UI is aweful; it makes me so sad.
    - farmin 4y ago
      I reckon there is space for a drop in replacement ui for Angular and Ionic that respects screen real estate and users ability to interep a more dense set of information. Less padding etc. I'd pay for it. Or there could just be a few small modifications to make what is there more workable.
  - kyleyeats 4y ago
    The worst part of this approach in my experience is that, at the end, you always feel like it's an optimization problem on your end.
- codeptualize 4y ago
  I think people still use Ionic, which uses Cordova or Capacitor for native. There are certainly use cases for it but also many downsides, it's mainly just hard to get the UI right.
- 4y ago
meerita 4y ago
We did Fotolog.com using mobile and it gave us several problems. Webviews aren't good at all. We tried Flutter, and we also had complete troubles, but not related to the technology but finding people who were able to do it. The answer was react-native with a good balance of performance, pool of people who knew how to work on it.
librish 4y ago
Is the actual view rendering done in webviews? I've struggled with that because the compatibility between different Android webviews can be very janky, and lead to some really obscure bugs, plus on many phones it just feels "off".
- SirHound 4y ago
  No - the point is to render in platform-native (hence the name) views.
  - akmarinov 4y ago
    From the article > Our new mobile app still uses React Native, but is literally just 1 component: a function that renders a webview.
turdprincess 4y ago
Ive been an iOS dev for 10 years now and every few years a new cross platform framework comes along. They all suck. Either the development experience is awful, or the user experience is awful. Actually, it's usually both. The thing is that its easy to get 90% there with these things. But getting that last 10% is often a huge hurdle, erasing most of the efficiency gains you just made. Then, when a new hot framework comes along, the old hottness you bet your project on quickly becomes deprecated, and you have to rewrite your whole project under duress. I tried the new hotness recently - Kotlin Multiplatform. Sharing code was great, debugging sort of worked but not really, and it wasn't long before I was pen pals with an overseas developer - no documentation on the bleeding edge! Ive been developing iOS for 10 years and my all-native workflow never relied on the mercy of a kind Bulgarian... How long before people give up on that and move on to the next thing? Hiring is really tough as well. With cross platform, at the end of the day, when you get that crazy memory issue or app crash, you need native expertise. So to be an effective cross platform engineer, you have to be an expert in iOS, Android, and whatever hot framework you bet on. If you need to get to market very quickly and are OK with throwing it all away in a few years, cross platform is a great choice. But if you want your app to stand the test of time, the best thing you can do is to write it in the only framework which is officially supported by the platform - all native.
- api 4y ago
  ... which means you have to write the application at least twice for mobile and at least three times for desktop. On desktop nobody does it any more, not even big companies. Everyone just uses Electron or something similar. It's a worse experience for the user but it's not bad enough to be a major barrier to adoption in most cases. On mobile I guess only two platforms is not quite as bad so more people cope with it?
  - trog 4y ago
    > It's a worse experience for the user but it's not bad enough to be a major barrier to adoption in most cases. One thing I don't quite get is why giant companies with zillions of dollars of recurring revenue just keep using Electron (other than the obvious reason that it's there and it works already), when they could massively improve the user experience & make themselves significantly less vulnerable to competition by building native applications. I mean, I get that making native applications is really hard, and trying to keep feature parity between version is a huge challenge (indeed, the the point of TFA). But it's obviously possible & some large organisations do it despite the difficulty (indeed, even some open source projects run by volunteers have it figured out). I think about this every time I use Slack & feel the janky horribleness every time I click around the interface and have to deal with all the latency of waiting for it to update. I get that average users might not notice this but anyone who grew up with native applications surely can "feel" it and despair.
riveralabs 4y ago
What are your users saying? Especially mobile users. Are they expecting a native experience? Engineering decisions that sacrifice user experience usually don’t have a happy ending. As a native iOS developer the best feedback I can get is when somebody tells me that my app looks like it was developed by Apple. I like using vanilla controls as much as possible. But as previously mentioned its all about tradeoffs.
akmarinov 4y ago
The author is reinventing Cordova, lol
- martini333 4y ago
  [flagged]
- deleted 4y ago
  [deleted]
z3t4 4y ago
I was waiting for "progressive web app" (PWA). Safari is lagging behind in stuff like native file system access. But for most apps a PWA would most likely do the job.
- kadomony 4y ago
  Apple's monopoly via an app store and its market share is the only reason why PWAs aren't already ubiquitous. It makes no sense why I can't download a web app to my phone directly from any browser other than "well, that would cut into our monetization through IAPs and the app store." Genuinely, fuck Apple for holding the web back.
  - Existenceblinks 4y ago
    fanbois have entered the reply 3 2 1: no no no it's evil google's agenda that will invade your privacy and security on your devices .. a lot of excuse.
akmarinov 4y ago
“And then we wanted to write a widget or use the dynamic island and we realized we can’t, so we just delivered a subpar experience, but hey - who cares about user UX when our dev UX is so great”
- codeptualize 4y ago
  I don't see why that wouldn't be possible, they are still using React Native so they still can use native functionality where necessary.
  - akmarinov 4y ago
    But that’s two codebases… three with the RN wrapper
    - codeptualize 4y ago
      I think the point is that they write their UI once. There will always be platform specific parts, but those are a lot smaller if your UI is shared between platforms.
      - Aaargh20318 4y ago
        But the point is that the UI is the one thing cannot be shared.
Izkata 4y ago
> Quite simple really: a bridge between web-land and mobile native-land. Our new mobile app still uses React Native, but is literally just 1 component: a function that renders a webview. I don't know about the wrapper, but the entire app being a webview is how Peapod (grocery delivery) has been for years.
deleted 4y ago
[deleted]
stmw 4y ago
This is an important technical discussion, one that the community needs to keep having to reduce unnecessary work and get more cross-platform support. There is a lot to be learned from (and reused) from history. For example, part of the post here is "When web-land wants to access the device keychain, it sends a message to native-land, and native-land responds with a primitive value. Neither native-land or web-land ever have to think about "messages" though. They're just function calls. Web-land has no idea that its function calls are being converted to postMessage calls behind the scenes." That is very similar to Microsoft COM, DCOM and COM+, which all appeared at the points when Microsoft had to cope with levels of complexity similar to those in the browser and mobile platform diversity observe todday. ref: https://en.wikipedia.org/wiki/Distributed_Component_Object_Model https://en.wikipedia.org/wiki/Distributed_Component_Object_M...
college_physics 4y ago
I have read the post and 60 comments but the "future" is as clouded as ever. I wonder if there was ever a period where developers had such difficulty identifying how to best deliver applications.
- rubicon33 4y ago
  There is no difficultly in identifying how to best deliver applications. The issue is entirely resources. If you want to deliver the best applications, there is one answer - native. If you want to deliver the best application given a small team or other constraints like time, then you have a plethora of hybrid options at your disposal (react native, flutter, etc.) But at the end of the day the fact remains that almost every app written in a hybrid framework, would be better, smoother, and less of a frustration at scale, than hybrid.
  - college_physics 4y ago
    Identifying a key variable (resources) helps but doesnt really solve the optimisation problem. Resources depend on the context and business model and that might not be under the control of the developer. Resources may also be variable over time, e.g when the funny money runs out. In the post and comments you see the anxiety about having to support diverse codebases. Thinking longer term you also need to address how platforms and stacks and the application requirements might evolve over a few years. You dont want to compromise your future options. This is even more critical for open source projects. Further, it is not even a binary choice as there are multiple types of "native" and "hybrid" per platform. E.g. on android you could have pure java, or some variable amount of kotlin (or even qt/c++, depending on your definition of native) and desktop is much worse. The bottom line is that its much more of a gamble than might have been in the past.
deedubaya 4y ago
Turbolinks/Turbo have been enabling this for ages?
hokumguru 4y ago
Really do check out Turbo Native from the Basecamp team. They’ve taken this hybrid web approach a step further with a bridge and native navigation. It is quite difficult actually to distinguish between their apps and real native UI, the library is astonishingly good.
- stanislavb 4y ago
  And, what is more, it’s heaps easier to develop and maintain compared to React.
- stevenhuang 4y ago
  Interesting tech. Looks like it's developed by hey.com, and their email app on Google Play store is only 9MB, which is impressive. From what sparse commentary I could find online, looks like this is a middle ground between web dev and native dev. It allows reusing server logic to emit html markup for mobile UI, but requires platform developers to put in the necessary native pieces piecemeal (sensible choice considering the leaky abstractions in react native). https://play.google.com/store/apps/details?id=com.basecamp.hey https://play.google.com/store/apps/details?id=com.basecamp.h...
  - deleted 4y ago
    [deleted]
lawgimenez 4y ago
Web app and making it try hard to be native is not the future too. Maintaining different codebase is achievable.
- wiseowise 4y ago
  Increased costs and useless reinventing of apps three times, what a great future.
  - lawgimenez 4y ago
    Both platforms have different UI guidelines. It's more on respecting the users of each platforms.
    - wiseowise 4y ago
      Who’s stopping you from respecting different platforms with your web ui?
      - dickersnoodle 4y ago
        I'd say it's the inherent foolishness of spending time and $$$ trying to get your web UI into the uncanny valley of looking "as close as possible to the native UI" instead of spending that time and $$$ actually using the native UI and components, but that's just me.
jitl 4y ago
This sounds exactly like Notion’s mobile app tech stack roughly 4 years ago - a web app running in a React Native wrapper webview. We really struggled to get that architecture to perform well, in particular for local caching, although improved React Native bridge performance might make it more feasible these days. What we noticed is that we’d incur substantial performance bottleneck for anything that needs to move data to/from native because of the number of encode/decode steps and “bridge hops”. For example to read a row from SQLite, count the bridge hops: Webview JS -> Java: postMessage to read a row from SQLite Java -> React Native JS: hey, a postMessage happened, what to do? React Native JS -> Java: please select * from … where … Java -> C: ok really run this SQL Then the stack of conversions repeats on the way back to the webview: SQL C -> Java -> RN JavaScript -> Java -> Webview JavaScript The other thing that plagued us performance wise was boot-up speed. At the time (before Hermes JS VM for React Native), we’d have to wait for RN’s JS to boot, figure out our cache status, then boot the webview JS. And then the webview JS would do the bridge dance above to pull data from SQLite to render. Slow - 40 seconds on low end Android slow. Today we are still mostly a web app, but our wrapper is pure native code. We cold start to a native view and boot the web app in the background. Our throughout & latency to native APIs is substantially faster without the extra bridge hops into and out of the RN JavaScript VM. We managed the original architecture swap from RN -> true native wrapper with a team of three - myself, our first iOS engineer, and our first Android engineer. We do have a large mobile team now though. There’s some more FAQs and answers about this on Twitter here: https://twitter.com/jitl/status/1530326516013342723?s=46&t=x00nsPtqGkZhwGzABOGR9A https://twitter.com/jitl/status/1530326516013342723?s=46&t=x... One thing I’d add is that deciding to use a webview wrapper is quite common for multiplatform rich text content editors. Google Docs, Dropbox Paper, Quip, Coda, Notion all use this architecture on iOS and Android because implementing an editor is extremely complex. It’s much more expensive to implement an editor 3x than say implementing a few list views and a form 3x.
- skrebbel 4y ago
  How do you boot the webview in the background? I tried this once but couldn’t figure it out.
  - 4y ago
todotask 4y ago
On other hand, on the energy impact, if anyone can find RN consumes more energy compare to Ionic that probably use Capacitor under the hood? https://ionic.io/blog/ionic-vs-react-native-performance-comparison https://ionic.io/blog/ionic-vs-react-native-performance-comp...
crossroadsguy 4y ago
There is no better way to build a mobile app than a native app. This was shown yet again when I tried Standard Notes few days ago for the nth time. It still is sluggish and slow and felt like having too many jerks and clunks. Downright unusable for a major notes app in 2022.. well 23. Among Joplin, Obsidian, FS Notes, Bear and few more Standard Note was the worst experience by a margin. Not to mention they still not allowing local raw files citing “but encryption”, or maybe they’ve moved to another reason now. Another example of how developers can become blissfully oblivious of what users find good and start confusing it for what is “good” for developers themselves.
- WhitneyLand 4y ago
  Correct. >Our mobile app is just our web app There are limitations that come with this philosophy and if the trade offs aren’t stated it usually means they’re not fully considered.
  - deleted 4y ago
    [deleted]
- stevenhuang 4y ago
  IIRC Obsidian is also built using web technologies, via Capacitor
  - smcleod 4y ago
    Yep and it's dreadful as a mobile app.
    - stevenhuang 4y ago
      Hah I rather meant that as an example of a well made mobile app using web tech, like Discord. There are some UX decisions that I disagree with but I feel the underlying tech stack is solid (fast, looks good, feels native, etc)
      - 4y ago
deleted 4y ago
[deleted]
marvindanig 4y ago
pwa+webview+webassembly is the future of everything.
- arcturus17 4y ago
  I wish, but I don't think it'll be the case as long as Apple and Google control the mobile platform. The problem was always economical, and not technological. The tides of regulation seem to be changing, and we might get key rulings on their stranglehold on the app stores in the coming years, but it's very hard to conceive how the regulator could compel them to open their systems, and for example implement certain PWA APIs.
  - marvindanig 4y ago
    i absolutely agree 100%
todd3834 4y ago
We went forward with this exact solution years ago at a company I worked for. In our case our mobile usage was actually really low compared to web. It just didn’t make sense to invest in native development. So we found React Native with web views to work pretty well. We also tried React Native Web, it was a lot newer and kind of an experiment back then. It was cool that we could get it to work but the web results were a little crazy when you care about semantic markup and SEO. It might have changed a lot since then. More recently I worked on a team that wrote a lot of business logic in C++ to share across android and iOS. We ended up compiling it to WASM and we were able to build a web interface pretty quickly. A lot of languages are trying to make this easier. Kotlin standing out to me as an easy learning curve and prioritizing this. Challenge there is not using Java platform specific libraries on the shared stuff. I do think there is something to be said for sharing pieces of the UI too. I think the future looks bright for multi platform development. There is still some work to be done but it’s all heading in the right direction in my opinion. I think you’ll have iOS, Android and Web specific code mixed with multi platform pieces. Both business logic and UI.
- todd3834 4y ago
  As always it’s going to depend on the app. The Tesla mobile app in React Native works perfectly fine for me on iOS. At the same time web views for YouTube would probably suck. So many situations and so many options… again I’m very optimistic about the direction things are goin.
  - wiseowise 4y ago
    > At the same time web views for YouTube would probably suck. That’s only the case because YouTube sucks to start with.
can16358p 4y ago
So, wrapping a web app in a webpage in a native app is the future?
satvikpendem 4y ago
Interesting, no mention of Flutter here. I found the dev experience as well as customer experience far better than web apps on web and mobile as they mention here.
- mike_hearn 4y ago
  Flutter and Kotlin Multiplatform have the potential to be sleeper hits here. Kotlin in particular is interesting because it lets you go in at several points on the spectrum - you can share just logic code between platforms and use Apple UI on iOS / HTML for a web version, or you can use Jetpack Compose and use the same UI toolkit on each platform. You can also create desktop apps this way and that opens up the possibility of just skipping the web version entirely: use Kotlin and Jetpack Compose for Android, iOS and Desktop. This is nice because it means you can do things like consistently use multithreading throughout, share libraries, use GraalVM native image to optimize startup time and memory usage on desktop, have low latency UI everywhere, work offline, use files, integrate with the host OS and so on. This is one reason I created Conveyor (https://hydraulic.software/ https://hydraulic.software/) - if you go this route without it then you'll hit the painful desktop distribution process. With Conveyor it's no harder than publishing a static webapp, and you can avoid the desktop app stores with their various rules and rakes.
dariosalvi78 4y ago
They basically reinvented Cordova
- jacobp100 4y ago
  Cordova would be a lot more performant for their setup. Right now, they spin up a JS VM, parse and evaluate ~800kb JS, then call out to native to add a web view. It’s a lot to do - and only really worth it if you’re using the rest of RN
andrewstuart 4y ago
You can build cross platform single code base mobile apps with Delphi. https://learndelphi.org/kiskis-the-crazy-social-network-for-android-and-ios-in-delphi/amp/ https://learndelphi.org/kiskis-the-crazy-social-network-for-...
yellow_lead 4y ago
> Packages for React Native are their own special breed of monstrosity because the package author would be the one writing code twice: once for iOS and once for Android (and of course the JavaScript wrapper). The result is a drastic increase in library abandonment and stability issues. In addition, keeping your packages in sync with the latest version of React Native (which is notoriously difficult to keep up to date) was a nightmare of its own. This is an accurate observation. I notice the same thing. It doesn't help that there are N Android versions and M iOS versions as well
gauddasa 4y ago
With tons of effort put on browsers to adhere to web standards and seamlessly interface with different kinds of hardware and platforms, the nasty hard work has already been done. How many times will the wheel be reinvented? It is consumers who should openly demand for web applications and resist efforts pushing for app alternative. This will help the consumers hide their backs and developers save their backs.
- krzat 4y ago
  On desktop this is already settled and most of everyday stuff is done through websites or electron apps. I suspect that Apple/Google will never let this happen due to 30% tax they steal from devs.
  - sfe22 4y ago
    Apple google don't “steal” from devs. Devs are a business and if they are worth their salt they account for business expenses in their pricing. If anything Google and apple “steal” from their OS customers. This is the same as saying government steal from corporations, while technically true they in reality steal from citizens as businesses account for their government expenses in their pricing.
- scrame 4y ago
  But then how would a crappy fly-by-night startup pull in all your local data and sell it off when the VC money runs out?
gloosx 4y ago
React Native, which was meant for writing amazing native apps, is just misused as a browser web-view thing. I am an expert in this field. Just never use React native to open single WebView. Never try to turn your website into mobile app like this. If it's a website, it's a website. If you need app make app. React, Electron and React Native enables you to make apps using Javascript, which is same as your website, it means you can have the same business logic between web and native app, same language it all written in, team talking on the same language, only the rendering logic will be different, which is huge saves. But it's not Flutter. It was not meant just to present webviews with your webpage. There is a Browser for that. Finally there is a PWA for just exactly that. Amazing stuff which React + Electron + React Native enabled - abstracting JS from Web to App - is so much crooked by folks trying to turn it inside out React Native is not the future – for folks who don't understand how to use it. In fact they hate using it wrong. For me – it's the future, i can use only one language to create an Android, iOS, Windows, Linux and Mac native apps. (of course, i would never try to fit it into a single front-end codebase, this is pure madness)
- supermatt 4y ago
  > of course, i would never try to fit it into a single front-end codebase, this is pure madness If its a single app for multiple platforms, and you are sharing code and views, why wouldnt you fit it in a single codebase? Surely to do otherwise would be unnecessarily complicated?
  - gloosx 4y ago
    Because two things, UI is different between platforms, to make a quality native-feeling app, you will have to use the design guidelines and native elements of every platform. What you can share is the business logic, abstract ui logic, but not the views themselves. You absolutely don't need to merge codebases in order to share something between them, you just need to have it portable. Having one mega-app seems more of a complication to me.
    - davedx 4y ago
      Think people are talking about different things. When I think about sharing the same code base I think about a single repo with lerna packages, where a lot of the common code is in packages, and each platform's native app is also its own package with its own build toolchain, that pulls in the shared code packages.
diimdeep 4y ago
The only way to survive with a single code base is to go the way of gamedev, to own the substrate you are running on completely. From rendering of fonts to user input. This, of course, depends on the complexity of software. App in this blog post is not really that hard compared to the effort any game would need to go to render on screen. C'mon, it is just a text editor, there is not much of anything there really. All this just shows the state of modern development of too many abstractions for really nothing in exchange except a slow, overengineered fashion hype train. Surprised, there is no mention of WebAssembly in there. (edit typos)
- barrkel 4y ago
  I assume you're sarcastic, because creating a good native editing experience from the ground up is not trivial, when you try to make context menus look native, have native editing keyboard shortcuts, integrate with system IMEs and accessibility for screen readers, etc.
  - diimdeep 4y ago
    No. There are absolutely no problems with providing accidental native context menu elements or integration with menubar, etc. BTW, I just tried this app on Android, it is broken, it is simply showing white blank screen. And on macOS, and it asks $90 a year for basic markdown features. Just no. And then, there is this. https://standardnotes.com/principles#negativity https://standardnotes.com/principles#negativity https://standardnotes.com/longevity https://standardnotes.com/longevity We are complexity bigots. We don’t merely hate complexity in software—we detest it. This is literally contradicting the technology stack that they chose. In the end, it seems to me like a low effort, money making enterprise with some sprinkles and wishful thinking.
    - barrkel 4y ago
      How many times have you tried this? Text editors are not easy to write. There's a wonderfully fractal level of detail. The differences in text editing experiences between platforms abound. The boundaries the cursor moves to for different inputs; e.g. are spaces skipped when moving word by word; are they only skipped at the start, at the end, or does the algorithm change depending on the direction of cursor travel. How selection changes from character-based to word-based if it starts with a double-click. How the scroll position changes based on cursor movement, selection extension drag, and so on. Do you support multiple selection of text? Windows' built-in text box does, if you hold Ctrl down, you can select multiple discontiguous text ranges and delete, cut or copy them. Cursor navigation isn't trivial. In word-wrapped text, a single location in the text can be represented by a cursor at the start of wrapped a line or the end. Do you go with what Emacs calls goal column (i.e. when cursor passes through short lines and needs to move backwards, does it "remember" where it was when you cursor through to a long line again)? Or does it gradually work its way back to column 0. And of course for variable-width fonts, targeting needs computing in pixels, not characters. It's extremely rare for games to include a fully featured text editing experience. In the old days, you'd consider yourself lucky to get a navigable cursor over fixed-width text. Even today, where games take text input, it's frequently a simple one-line text box with just a navigable cursor and no selection. Games also take a big shortcut on performance: a game loop is always running, always presenting frames ideally at the refresh rate. An editor can't afford that, it consumes too much energy. So now you need to worry about dirty regions and damage control, efficiently filling in areas revealed by scrolling and edits, taking care that letters may extend beyond naive bounding boxes, whether due to ligatures, kerning, anti-aliasing, and so on.
kbcool 4y ago
> There is also no practical way to build on React Native without using a metric ton of third party libraries As an author of a few quite large React Native apps I have to disagree. There's a few key ones and apart from that it's down to maturity. Immature developers will always reach for whatever crutch they can find first. Doesn't matter what language. The same immaturity shows up in their attempt to recreate (a not so great) wheel with their Phonegap/Cordova clone. I would seriously be embarrassed about an article like this if it was my business.
- krosaen 4y ago
  Can you share more about your RN apps? Would be great to have some more examples.
obrhoff 4y ago
People don't speak about other approaches. For example my team adopted the BFF (Backend for frontend) pattern. Android and iOS Developers work together on a shared BFF and encapsulate there as business logic as possible. Also we define OpenAPI specs on the BFF to generate data models and API code for the clients. It works pretty good for us.
- danieldisu 4y ago
  The ol’ moving more logic to the backend I see this being a trend in the coming years
- jacobr 4y ago
  Isn't a shared BFF an oxymoron, considering that you typically build a BFF specifically for one client and its needs? Maybe you just have a backend :)
  - obrhoff 4y ago
    If you want to nitpick ofc. in this case its about mobile.
bundie 4y ago
[dead]
ndomanop 4y ago
I've also been wondering why people still use ReactNative despite the availability of much simpler stacks. For me I use React to create User interface for all platforms then ship it as a mobile app using native webviews on Android and iOS, also I can use Electron to create a desktop version. Good thing is that these webviews offer Javascript Interfaces where you can access all native functionality you need. With a little bit of craftiness you can make your React Code (User interface) detect whether it runs on web version, mobile version or desktop version then make it behave according to what you want. I choose React for UI coz it's damn simple though you can use any other javascript based UI library.
jeswin 4y ago
If an app is available in native and PWA/webapp versions, I always install the PWA/webapp version. It's usually lighter, is better w.r.t. privacy, will need fewer permissions, and might allow copying text.
josefrichter 4y ago
User experience. It seems like it’s rarely mentioned in discussions like this. The sad truth is it’s usually sacrificed. This approach, as well as RN, will never give you the experience you get from native app. That applies to Standard Notes app too - it’s not great, not terrible. I understand using RN for an MVP when you have no money. But many times I feel like the issues described are organizational rather than technical.
Farreation 4y ago
These note apps created by tiny companies are useless and trying to reinvent the wheel. Standard notes has no reason to exist because Apple Notes and Google Keep already fill that niche better, and they actually know how to code, contrarily to these buffons.
anonred 4y ago
I look forward to the blog post in 2 years where Standard Notes realizes that reinventing Cordova was not in fact the right solution to building a high quality, cross platform app!
samirsd 4y ago
when you optimize for engineering effort rather than user experience you choose react and accomplish neither
cenny 4y ago
We do cross functional mob programming at my company with native iOS and Android apps. Works like a charm with a small team and I don’t think a react native app would offer any advantage. Instead we try to build the best app for each platform as one team. I’ve never believed the hype of code once run everywhere. All solutions have drawbacks you just have to pick one.
6510 4y ago
Okay, let me be that guy... I was that guy telling people no no don't send your customers to Facebook, Noooo twitter is not the superior RSS replacement. Live journal is the wrong choice, your Myspace efforts are not history in the making and your Geocities was historically just as much a waste of time. Flickr is not the place for your family album and neither is Picassa. There are countless active platforms and other walled gardens that offer actually great tools and do just what you want them to do but the thing is, non of it is yours! You are not making something for yourself, you are working to enrich the Zuck who can turn on you at any moment, from a benevolent friend to a brain eating zombie overnight. Take youtube, its still a great product but it's nothing like the fantastic thing it started out as. Yours may one day go from a popular channel or from quality content to being not advertiser friendly. You've invested countless hours only to be discarded with various motivations. You helped build these digital prisons, no faith can be cruel enough. Who cares that web is slower than native. People with slow phones should buy a faster one. If they cant afford to they have no money for you either. We pretend phones are not fast enough to do anything?? They are insanely fast compared to desktops from not to long ago. The only reason they are slow is that you've piled to much crap onto them, crap that shouldn't be there. I suggest we stop executing tasks and just pile them up, gradually execute them little bits at a time. Don't let anyone else manage this for you! Others will think their stuff takes priority over the user trying to input text. If I'm inputting text I honest to god want all other processes suspended until I'm done. Perhaps if I'm not typing for 20 seconds, gazing at the input area, perhaps you can send me a push notification. Its still heretical interference with the writing process. Apps are slow because the user just isn't important anymore. To do a silly analogy: Some people get stuck in a monologue, say after 2 beers. Others may find themselves unable to get a word in. The problem is not that they are not talking fast enough.
pat64 4y ago
Having read through the comments and tried standard notes I can see why users might have been disappointed going from native to this web implementation. I recently went through the process of switching to a web stack from a native iOS stack when it came time to support Android with one of my apps (https://getradiant.app/ https://getradiant.app/) and my biggest concern was making it feel a near as possible to the native app it was replacing and having it perform as well as possible on older Android devices. It turned out quite well and I’ve never had a user complain about the transition. The trick to my mind was to treat web dev like mobile dev. Focus on bundle size, load speed and fluidity within the confines of a mobile environment. Constantly compare what you’re building to a native app. Probably focus on SPA over SSR/MPAs. And remember, if you apply all of the above to much less restrictive desktop browser environment with a much higher performance ceiling, the experience is going to be pretty good. TLDR; think small, think fast and start with the most constrained environment you’re targeting, usually mobile, usually older Android. If you understand the limitations and considerations of browser engines when taking into account the above, the rest will follow and you’re going to have a good time.
randyrand 4y ago
I wish they went more into how they architected a complex webapp. Vanilla html and js?
jamesxtreme 4y ago
Why not use react-native-web and target all three platforms at once?

280 points by samwillis 4y ago

With the right libraries and clean code, going native for iOS/Android is usually the solution. Building UI/networking/etc quickly in Swift/Kotlin just isn't an issue anymore. RN/Flutter won't be used in 5 years.

Ian_Macharia 4y ago
Strongly disagree. Both frameworks save on dev time to a very significant degree. I actually foresee better cross platform solutions being introduced in 5 years
- ericlewis 4y ago
  I don't agree, and I have worked with this significantly as a consultant and core contributor to react-native. What typically happens is people convince themselves what you are saying is true then there ends up being huge delays to spin up all the infra app side... THEN eventually, they kinda are okay. until the next react-native release. edit: would like to clarify that of course I would recommend better ways... but... clients do as clients do.
  - tested23 4y ago
    You are looking at this with hindsight bias and are assuming that for some reason the future will remain the same as the past. There are no fundamental reasons why ios and android development occur with two different ui frameworks in two different languages. With low interest rates companies will not be able to justify paying 3x to maintain 3 different apps when they could theoretically just pay 1x for one app that works everywhere
    - turdprincess 4y ago
      The key word here is “theoretically”. These cross platform solutions are great in theory - who wouldn’t want to share code across all platforms? It’s a great sell, especially to the folks holding the purse. The reality though is it doesn’t work well. The tooling, performance, debugging, library stability and observability are all substantially worse. Your team might save a ton of time spinning up a React Native app, but lose it all right back once you keep hitting gnarly Android performance issues. In the future, once we have a proper cross platform development kit officially supported by Android and Apple, code sharing will be great. But today it doesn’t exist. And that’s why none of (the good) apps you use are written in a cross platform way.
      - Apocryphon 4y ago
        Flutter’s development experience is better than RN’s, and perhaps even better frameworks will come in time.
        ericlewis 4y ago
        Hard to leverage JS devs when it's an entirely different language from JS.
        latchkey 4y ago
        Dart really isn't hard to pick up and is surprisingly nice to write code in.
    - Existenceblinks 4y ago
      Good metrics for proposal to VCs .. to steel the cake from native platform overlord. Lets eat the apple and google cake to boost our return margins. Bam! VCs alliance for new scene graph renderer for the web on any device.
      - wiseowise 4y ago
        It’s the other way around. Don’t let native overlords eat into our cake.
- matchbok 4y ago
  For simple apps, maybe. But anything complex still requires native resources and expertise. So the value is greatly diminished.
  - fargo 4y ago
    How would you define a simple app out of curiosity?
  - wiseowise 4y ago
    > But anything complex still requires native resources and expertise. Any examples of simple and complex apps?
agsnu 4y ago
I'm just holding out for a Jetpack Compose for iOS :)
- pixel_tracing 4y ago
  It’s called SwiftUI?
  - wiseowise 4y ago
    > SwiftUI Complete separate toolkit with its own patterns and semantics. I’d rather use one then learn two. https://touchlab.co/compose-ui-for-ios/ https://touchlab.co/compose-ui-for-ios/
    - wiseowise 4y ago
      Than*
  - agsnu 4y ago
    Apple breaks too much stuff in software updates. I want to control what versions of key libraries I'm integrated with and rev them on my own schedule.
- mike_hearn 4y ago
  It exists: https://touchlab.co/compose-ui-for-ios/ https://touchlab.co/compose-ui-for-ios/
  - mwcampbell 4y ago
    Apparently Jetpack Compose for iOS has zero accessibility support so far, if the Droidcon NYC app is a representative sample. I'm sure that will come; just don't use it yet for anything more important than the iOS version of an Android conference app.
tested23 4y ago
Ios and android development as they exist today will die once governments mandate then end of the app store monopolies.
- myko 4y ago
  There is no Android app store monopoly. You can download apks and install them already. See: https://f-droid.org/ https://f-droid.org/
  - wiseowise 4y ago
    Just as there was no “IE monopoly”, even though you could technically download separate browser.
    - myko 4y ago
      I don't think that works as a metaphor. IE got MS in trouble because it was so embedded into the OS that it was literally required, and MS did everything they could to force users to use it. Android works fine when built from source with no Play Store at all, using F-Droid as the primary store.
- dmitriid 4y ago
  Ah yes, this mandate will immediately make all APIs across all OSes the same
jacobp100 4y ago
Have you tried SwiftUI? It’s not replacing RN any time soon

robertoandred 4y ago

Sounds like he's just inventing a slower, less native version of React Native.

yawnr 4y ago
Yeah seriously. Just a worse version of the bridge. IMO the cart is leading the horse on this one. Might be more convenient for their dev team to just have a web codebase (though I’d argue if they took the time to transition their web codebase to react native web they’d see the same benefit), but it will definitely hurt UX.
- moughxyz 4y ago
  There's no reason it has to hurt UX in theory. The difficulty is just in spending a lot of extra time perfecting the animations and interactions, which is 100% doable. We just released navigation present and dismiss animations a few weeks ago, which feel pretty great imo. They're non-interactive, and again, this will take a lot of extra work you get for free with native, but the tradeoff is worth it for us, and again, amenable.
  - KerrAvon 4y ago
    You seem to be in very heavy denial. This will never be as nice to use as a native app, because you cannot replicate all of the small details of how native UI works on each platform. And say you manage to get close to emulating a native app on one platform — when the OS UI updates, you’ll be behind again. I get that it’s inconvenient/expensive for you to build three UI layers. But that’s the only way to do this well. This was true for cross-platform apps in 1989 and it remains true decades later.
    - locutous 4y ago
      > This will never be as nice to use as a native app, because you cannot replicate all of the small details of how native UI works on each platform. Not sure how much of that is necessary. I mean, a button doesn't "look native", so what? It's a button. Apps written to require network requests to resolve a navigation are much worse than JavaScript handling a user event. > And say you manage to get close to emulating a native app on one platform — when the OS UI updates, you’ll be behind again. Not really the goal. You have this backwards. Keeping up with OS churn is one of the reasons to use an abstraction like this. It doesn't break your app nearly as much. The browser is a much more stable target than native mobile APIs. > I get that it’s inconvenient/expensive for you to build three UI layer. But that’s the only way to do this well. Inconvenient is dramatically understating the case. 3x spend is flat out impossible for many places.

CharlesW 4y ago

> Our new mobile app still uses React Native… The big reveal is that React Native is still their future. TLDR: Their app continues to use React Native, but they've given up on using it to provide a native user experience, and instead just use it to access OS APIs.

ericlewis 4y ago
NativeScript would prob suit them better.
teg4n_ 4y ago
What they decided to do is really quite strange. Something like Capacitor makes much more sense but they said they wanted access to React Native libraries... I hope https://github.com/OpenNative/open-native https://github.com/OpenNative/open-native can address their requirements in the future. It's goal is to make things like React Native native modules work across frameworks (e.g., react native libraries working in capacitor and native script)

billllll 4y ago

I don't have personal experience with this, but React Native Web claims to solve this issue: https://necolas.github.io/react-native-web/ https://necolas.github.io/react-native-web/, not sure if anyone has had experience with this. Of course, you will have issues with dependency hell/package maintenance. Another great option seems to be Flutter web. I was really impressed by the "batteries included" approach to Flutter, and Dart has a pretty comprehensive standard library. This is in contrast to React's "just find a random package on npm and pray it doesn't bite you in the future." Obviously rewrites are expensive, but I personally think both approaches are worth considering versus abandoning native components completely. WebView isn't without problems (and also, you don't need React Native to use WebView).

ericlewis 4y ago
combining RN and RNW is a pain in practice. It can be done, but not easily.
- phist_mcgee 4y ago
  I've done it. Once you're setup, it really does work quite out of the box. What you do have to be mindful of is clear separation of concerns when designing platform specific components - you have to think in terms of Button.native.ts and Button.web.ts when you're doing things like haptic feedback or animations. The only thing that's really a pain is that react dev tools has a harder time dealing with RNW components, and debugging in general can be a bit of a pain.
  - no_butterscotch 4y ago
    How are you liking it so far? Perf issues or no? Any concise/clear resource or guide you used?
    - phist_mcgee 4y ago
      >How are you liking it so far? Perf issues or no? Perf seems totally within reasonable bounds for a react app, no issues so far. In terms of resources or guides, it's pretty spotty out there. The project has definitely slowed down in terms of dev and i'm not sure where things like react 18 fit into the picture across platform, but we've setup our own config that works just fine for now. We may need to reappraise in 2-3 years if react does change architecturally too much.

marstall 4y ago

this is a cool model and I do something similar (I use native code to render the webview). though I wouldn't describe it as abandoning RN, because I use react-native-web inside that webview. rn-web provides certain features that are crucial for a native feel on mobile, like better coordination of touches within scrollviews.

sureglymop 4y ago
Do you have/know any example app to try out?
- marstall 4y ago
  I don't - but check out WKWebViewController ... and its WKScriptMessageHandler delegate, which lets you receive messages from javascript embedded in the currently viewed page.

mrbombastic 4y ago

One codebase sounds great but I always feel devs try to ignore that there just are significant differences between platforms that you must address if you want a well integrated app. Writing separate codebases in native iOS, Android, and web has a huge amount of waste but you can achieve higher quality and os integration, writing react native and react on web means you get just 2 codebases and higher dev productivity but at the cost of pain in libraries which typically also means less native integration, the solution proposed here means 1 codebase and even less native integration. If it is right for you great but like everything it is tradeoffs, pick your poison.

danielvaughn 4y ago
Agreed. Although the economic reality is that it’s borderline impossible for a company to develop a cross-platform native product unless they have significant amounts of money. Cross-platform is a terrible necessity to that end.
- ericlewis 4y ago
  Eh. Not sure I agree, unless you mean taking a non-native already made react bit and try to turn it into RN.. that is far harder and does require lots of money. too many people don't realize just how non-portable react code can be.
  - danielvaughn 4y ago
    No I mean building a product that works on web, android, and iOS, and has a native experience on all platforms. It’s hard enough to find a good web dev, but it’s far harder to find good iOS and Android devs. It’s a very large and expensive endeavor.
    - ericlewis 4y ago
      It is definitely a challenge, but as prev EM / hiring manager of many iOS / Android devs it certainly isn't impossible. Not sure about large and expensive. Surprisingly most of my best devs were all inbound, not via recruiters. Felt recruiters usually wasted our time and small teams of native devs can get a lot more done than web teams (at least so it seems based on my subjective exp). My previous company had probably well over a dozen web engineers and then for our mobile side we had a total of 3, myself included. We also often had to adapt designs ourselves and work with product to fix flows for native. But we still managed to keep up with web. edit: and not "keep up with web" in the we are working 80 hour weeks type thing, very normal working hours, 9-5. Possibly more normal than the web team.

gigel82 4y ago

*for you It's all about trade-offs; you decided to trade better performance and native look&feel for faster/easier development. Perfectly reasonable, but for others that are making different trade-offs React Native totally is the future. I think RN is a great middle-ground where you get native looking&feeling UX, but still get to share 95%+ of the code across platforms.

sureglymop 4y ago

Tried it out on Android and it feels janky. It just feels like a web app and it's not working well. To just give one example, if I click on the header of a note, a menu with "options" shows up. But Android also selects the text in the header and pops up a menu with "Cut, Copy, Paste, etc." which is exactly on top of that menu I was actually trying to get to...

moughxyz 4y ago
Eh, these are easy fixes. We're making progress daily on making it feel more "native" (i.e recently added present/dismiss animations). Try the demo[0] in your mobile browser, should feel pretty smooth. We've tested extensively on a whole range on devices and performance wasn't an issue. It's really the animations (or lack thereof) that make or break perception of "jankiness." What we have now is our first solid functionality-oriented release; next releases focus on tidying up the edges. [0]: https://standardnotes.com/demo https://standardnotes.com/demo
- foreverCarlos 4y ago
  Depends on the user’s expectations, I guess. The demo you linked does not feel close to native yet. Lots of reflows, small shifts, inconsistent rough animation… even for a web app it’s not smooth enough (iOS Safari)
  - dontlaugh 4y ago
    Indeed, compared to any native app it’s terrible. If you care about UX, you should make native apps.
    - Firmwarrior 4y ago
      You guys are technically correct, but also dead wrong with your outlook They're trying to make a useful app for humans, not trying to win the HackerNews Award for Excellence in UX. If accepting a little unfixable edge case jank makes their goal way easier to attain, they're going to end up with a much better app overall

CosmicBagel 4y ago

As someone who uses this off an on amount, I was really disappointed when I opened the app to the new web app. It was slow, janky, required me authenticating multiple times (biometric then username and password). I'm now looking for alternatives because "as fast as possible" is an important feature for me. I keep the app on my android home row, not because I use it a lot, but because when I need it, I need it instantly. Massive downgrade for the user imo, this only benefits the developer.

throw03172019 4y ago
It sounds like they are migrating portions to native first.

teucris 4y ago

So, essentially Phonegap/Cordova again? I always liked that model. I’m not entirely clear why it fell out of favor.

marpstar 4y ago
I spent the last 6 years building an Ionic app for “enterprise”. The still-not-native UX is the main reason why it’s not more popular, in my opinion. In our case, our users had little say in their respective organizations’ decisions to buy our product, and “good enough” was still better than what our competitors were offering anyway. We spent a lot of time of time debugging native layer issues, and WebGL bugs that would crash the webview (vector maps using the ArcGIS JS SDK) so it’s not a magic bullet in those respects either.
- martini333 4y ago
  I agree 100%. Ionic's default UI is aweful; it makes me so sad.
  - farmin 4y ago
    I reckon there is space for a drop in replacement ui for Angular and Ionic that respects screen real estate and users ability to interep a more dense set of information. Less padding etc. I'd pay for it. Or there could just be a few small modifications to make what is there more workable.
- kyleyeats 4y ago
  The worst part of this approach in my experience is that, at the end, you always feel like it's an optimization problem on your end.
codeptualize 4y ago
I think people still use Ionic, which uses Cordova or Capacitor for native. There are certainly use cases for it but also many downsides, it's mainly just hard to get the UI right.
4y ago

meerita 4y ago

We did Fotolog.com using mobile and it gave us several problems. Webviews aren't good at all. We tried Flutter, and we also had complete troubles, but not related to the technology but finding people who were able to do it. The answer was react-native with a good balance of performance, pool of people who knew how to work on it.

librish 4y ago

Is the actual view rendering done in webviews? I've struggled with that because the compatibility between different Android webviews can be very janky, and lead to some really obscure bugs, plus on many phones it just feels "off".

SirHound 4y ago
No - the point is to render in platform-native (hence the name) views.
- akmarinov 4y ago
  From the article > Our new mobile app still uses React Native, but is literally just 1 component: a function that renders a webview.

turdprincess 4y ago

Ive been an iOS dev for 10 years now and every few years a new cross platform framework comes along. They all suck. Either the development experience is awful, or the user experience is awful. Actually, it's usually both. The thing is that its easy to get 90% there with these things. But getting that last 10% is often a huge hurdle, erasing most of the efficiency gains you just made. Then, when a new hot framework comes along, the old hottness you bet your project on quickly becomes deprecated, and you have to rewrite your whole project under duress. I tried the new hotness recently - Kotlin Multiplatform. Sharing code was great, debugging sort of worked but not really, and it wasn't long before I was pen pals with an overseas developer - no documentation on the bleeding edge! Ive been developing iOS for 10 years and my all-native workflow never relied on the mercy of a kind Bulgarian... How long before people give up on that and move on to the next thing? Hiring is really tough as well. With cross platform, at the end of the day, when you get that crazy memory issue or app crash, you need native expertise. So to be an effective cross platform engineer, you have to be an expert in iOS, Android, and whatever hot framework you bet on. If you need to get to market very quickly and are OK with throwing it all away in a few years, cross platform is a great choice. But if you want your app to stand the test of time, the best thing you can do is to write it in the only framework which is officially supported by the platform - all native.

api 4y ago
... which means you have to write the application at least twice for mobile and at least three times for desktop. On desktop nobody does it any more, not even big companies. Everyone just uses Electron or something similar. It's a worse experience for the user but it's not bad enough to be a major barrier to adoption in most cases. On mobile I guess only two platforms is not quite as bad so more people cope with it?
- trog 4y ago
  > It's a worse experience for the user but it's not bad enough to be a major barrier to adoption in most cases. One thing I don't quite get is why giant companies with zillions of dollars of recurring revenue just keep using Electron (other than the obvious reason that it's there and it works already), when they could massively improve the user experience & make themselves significantly less vulnerable to competition by building native applications. I mean, I get that making native applications is really hard, and trying to keep feature parity between version is a huge challenge (indeed, the the point of TFA). But it's obviously possible & some large organisations do it despite the difficulty (indeed, even some open source projects run by volunteers have it figured out). I think about this every time I use Slack & feel the janky horribleness every time I click around the interface and have to deal with all the latency of waiting for it to update. I get that average users might not notice this but anyone who grew up with native applications surely can "feel" it and despair.

riveralabs 4y ago

What are your users saying? Especially mobile users. Are they expecting a native experience? Engineering decisions that sacrifice user experience usually don’t have a happy ending. As a native iOS developer the best feedback I can get is when somebody tells me that my app looks like it was developed by Apple. I like using vanilla controls as much as possible. But as previously mentioned its all about tradeoffs.

akmarinov 4y ago

The author is reinventing Cordova, lol

martini333 4y ago
[flagged]
deleted 4y ago
[deleted]

z3t4 4y ago

I was waiting for "progressive web app" (PWA). Safari is lagging behind in stuff like native file system access. But for most apps a PWA would most likely do the job.

kadomony 4y ago
Apple's monopoly via an app store and its market share is the only reason why PWAs aren't already ubiquitous. It makes no sense why I can't download a web app to my phone directly from any browser other than "well, that would cut into our monetization through IAPs and the app store." Genuinely, fuck Apple for holding the web back.
- Existenceblinks 4y ago
  fanbois have entered the reply 3 2 1: no no no it's evil google's agenda that will invade your privacy and security on your devices .. a lot of excuse.

akmarinov 4y ago

“And then we wanted to write a widget or use the dynamic island and we realized we can’t, so we just delivered a subpar experience, but hey - who cares about user UX when our dev UX is so great”

codeptualize 4y ago
I don't see why that wouldn't be possible, they are still using React Native so they still can use native functionality where necessary.
- akmarinov 4y ago
  But that’s two codebases… three with the RN wrapper
  - codeptualize 4y ago
    I think the point is that they write their UI once. There will always be platform specific parts, but those are a lot smaller if your UI is shared between platforms.
    - Aaargh20318 4y ago
      But the point is that the UI is the one thing cannot be shared.

Izkata 4y ago

> Quite simple really: a bridge between web-land and mobile native-land. Our new mobile app still uses React Native, but is literally just 1 component: a function that renders a webview. I don't know about the wrapper, but the entire app being a webview is how Peapod (grocery delivery) has been for years.

deleted 4y ago

[deleted]

stmw 4y ago

This is an important technical discussion, one that the community needs to keep having to reduce unnecessary work and get more cross-platform support. There is a lot to be learned from (and reused) from history. For example, part of the post here is "When web-land wants to access the device keychain, it sends a message to native-land, and native-land responds with a primitive value. Neither native-land or web-land ever have to think about "messages" though. They're just function calls. Web-land has no idea that its function calls are being converted to postMessage calls behind the scenes." That is very similar to Microsoft COM, DCOM and COM+, which all appeared at the points when Microsoft had to cope with levels of complexity similar to those in the browser and mobile platform diversity observe todday. ref: https://en.wikipedia.org/wiki/Distributed_Component_Object_Model https://en.wikipedia.org/wiki/Distributed_Component_Object_M...

college_physics 4y ago

I have read the post and 60 comments but the "future" is as clouded as ever. I wonder if there was ever a period where developers had such difficulty identifying how to best deliver applications.

rubicon33 4y ago
There is no difficultly in identifying how to best deliver applications. The issue is entirely resources. If you want to deliver the best applications, there is one answer - native. If you want to deliver the best application given a small team or other constraints like time, then you have a plethora of hybrid options at your disposal (react native, flutter, etc.) But at the end of the day the fact remains that almost every app written in a hybrid framework, would be better, smoother, and less of a frustration at scale, than hybrid.
- college_physics 4y ago
  Identifying a key variable (resources) helps but doesnt really solve the optimisation problem. Resources depend on the context and business model and that might not be under the control of the developer. Resources may also be variable over time, e.g when the funny money runs out. In the post and comments you see the anxiety about having to support diverse codebases. Thinking longer term you also need to address how platforms and stacks and the application requirements might evolve over a few years. You dont want to compromise your future options. This is even more critical for open source projects. Further, it is not even a binary choice as there are multiple types of "native" and "hybrid" per platform. E.g. on android you could have pure java, or some variable amount of kotlin (or even qt/c++, depending on your definition of native) and desktop is much worse. The bottom line is that its much more of a gamble than might have been in the past.

deedubaya 4y ago

Turbolinks/Turbo have been enabling this for ages?

hokumguru 4y ago

Really do check out Turbo Native from the Basecamp team. They’ve taken this hybrid web approach a step further with a bridge and native navigation. It is quite difficult actually to distinguish between their apps and real native UI, the library is astonishingly good.

stanislavb 4y ago
And, what is more, it’s heaps easier to develop and maintain compared to React.
stevenhuang 4y ago
Interesting tech. Looks like it's developed by hey.com, and their email app on Google Play store is only 9MB, which is impressive. From what sparse commentary I could find online, looks like this is a middle ground between web dev and native dev. It allows reusing server logic to emit html markup for mobile UI, but requires platform developers to put in the necessary native pieces piecemeal (sensible choice considering the leaky abstractions in react native). https://play.google.com/store/apps/details?id=com.basecamp.hey https://play.google.com/store/apps/details?id=com.basecamp.h...
- deleted 4y ago
  [deleted]

lawgimenez 4y ago

Web app and making it try hard to be native is not the future too. Maintaining different codebase is achievable.

wiseowise 4y ago
Increased costs and useless reinventing of apps three times, what a great future.
- lawgimenez 4y ago
  Both platforms have different UI guidelines. It's more on respecting the users of each platforms.
  - wiseowise 4y ago
    Who’s stopping you from respecting different platforms with your web ui?
    - dickersnoodle 4y ago
      I'd say it's the inherent foolishness of spending time and $$$ trying to get your web UI into the uncanny valley of looking "as close as possible to the native UI" instead of spending that time and $$$ actually using the native UI and components, but that's just me.

jitl 4y ago

This sounds exactly like Notion’s mobile app tech stack roughly 4 years ago - a web app running in a React Native wrapper webview. We really struggled to get that architecture to perform well, in particular for local caching, although improved React Native bridge performance might make it more feasible these days. What we noticed is that we’d incur substantial performance bottleneck for anything that needs to move data to/from native because of the number of encode/decode steps and “bridge hops”. For example to read a row from SQLite, count the bridge hops: Webview JS -> Java: postMessage to read a row from SQLite Java -> React Native JS: hey, a postMessage happened, what to do? React Native JS -> Java: please select * from … where … Java -> C: ok really run this SQL Then the stack of conversions repeats on the way back to the webview: SQL C -> Java -> RN JavaScript -> Java -> Webview JavaScript The other thing that plagued us performance wise was boot-up speed. At the time (before Hermes JS VM for React Native), we’d have to wait for RN’s JS to boot, figure out our cache status, then boot the webview JS. And then the webview JS would do the bridge dance above to pull data from SQLite to render. Slow - 40 seconds on low end Android slow. Today we are still mostly a web app, but our wrapper is pure native code. We cold start to a native view and boot the web app in the background. Our throughout & latency to native APIs is substantially faster without the extra bridge hops into and out of the RN JavaScript VM. We managed the original architecture swap from RN -> true native wrapper with a team of three - myself, our first iOS engineer, and our first Android engineer. We do have a large mobile team now though. There’s some more FAQs and answers about this on Twitter here: https://twitter.com/jitl/status/1530326516013342723?s=46&t=x00nsPtqGkZhwGzABOGR9A https://twitter.com/jitl/status/1530326516013342723?s=46&t=x... One thing I’d add is that deciding to use a webview wrapper is quite common for multiplatform rich text content editors. Google Docs, Dropbox Paper, Quip, Coda, Notion all use this architecture on iOS and Android because implementing an editor is extremely complex. It’s much more expensive to implement an editor 3x than say implementing a few list views and a form 3x.

skrebbel 4y ago
How do you boot the webview in the background? I tried this once but couldn’t figure it out.
- 4y ago

todotask 4y ago

On other hand, on the energy impact, if anyone can find RN consumes more energy compare to Ionic that probably use Capacitor under the hood? https://ionic.io/blog/ionic-vs-react-native-performance-comparison https://ionic.io/blog/ionic-vs-react-native-performance-comp...

crossroadsguy 4y ago

There is no better way to build a mobile app than a native app. This was shown yet again when I tried Standard Notes few days ago for the nth time. It still is sluggish and slow and felt like having too many jerks and clunks. Downright unusable for a major notes app in 2022.. well 23. Among Joplin, Obsidian, FS Notes, Bear and few more Standard Note was the worst experience by a margin. Not to mention they still not allowing local raw files citing “but encryption”, or maybe they’ve moved to another reason now. Another example of how developers can become blissfully oblivious of what users find good and start confusing it for what is “good” for developers themselves.

WhitneyLand 4y ago
Correct. >Our mobile app is just our web app There are limitations that come with this philosophy and if the trade offs aren’t stated it usually means they’re not fully considered.
- deleted 4y ago
  [deleted]
stevenhuang 4y ago
IIRC Obsidian is also built using web technologies, via Capacitor
- smcleod 4y ago
  Yep and it's dreadful as a mobile app.
  - stevenhuang 4y ago
    Hah I rather meant that as an example of a well made mobile app using web tech, like Discord. There are some UX decisions that I disagree with but I feel the underlying tech stack is solid (fast, looks good, feels native, etc)
    - 4y ago

deleted 4y ago

[deleted]

marvindanig 4y ago

pwa+webview+webassembly is the future of everything.

arcturus17 4y ago
I wish, but I don't think it'll be the case as long as Apple and Google control the mobile platform. The problem was always economical, and not technological. The tides of regulation seem to be changing, and we might get key rulings on their stranglehold on the app stores in the coming years, but it's very hard to conceive how the regulator could compel them to open their systems, and for example implement certain PWA APIs.
- marvindanig 4y ago
  i absolutely agree 100%

todd3834 4y ago

We went forward with this exact solution years ago at a company I worked for. In our case our mobile usage was actually really low compared to web. It just didn’t make sense to invest in native development. So we found React Native with web views to work pretty well. We also tried React Native Web, it was a lot newer and kind of an experiment back then. It was cool that we could get it to work but the web results were a little crazy when you care about semantic markup and SEO. It might have changed a lot since then. More recently I worked on a team that wrote a lot of business logic in C++ to share across android and iOS. We ended up compiling it to WASM and we were able to build a web interface pretty quickly. A lot of languages are trying to make this easier. Kotlin standing out to me as an easy learning curve and prioritizing this. Challenge there is not using Java platform specific libraries on the shared stuff. I do think there is something to be said for sharing pieces of the UI too. I think the future looks bright for multi platform development. There is still some work to be done but it’s all heading in the right direction in my opinion. I think you’ll have iOS, Android and Web specific code mixed with multi platform pieces. Both business logic and UI.

todd3834 4y ago
As always it’s going to depend on the app. The Tesla mobile app in React Native works perfectly fine for me on iOS. At the same time web views for YouTube would probably suck. So many situations and so many options… again I’m very optimistic about the direction things are goin.
- wiseowise 4y ago
  > At the same time web views for YouTube would probably suck. That’s only the case because YouTube sucks to start with.

can16358p 4y ago

So, wrapping a web app in a webpage in a native app is the future?

satvikpendem 4y ago

Interesting, no mention of Flutter here. I found the dev experience as well as customer experience far better than web apps on web and mobile as they mention here.

mike_hearn 4y ago
Flutter and Kotlin Multiplatform have the potential to be sleeper hits here. Kotlin in particular is interesting because it lets you go in at several points on the spectrum - you can share just logic code between platforms and use Apple UI on iOS / HTML for a web version, or you can use Jetpack Compose and use the same UI toolkit on each platform. You can also create desktop apps this way and that opens up the possibility of just skipping the web version entirely: use Kotlin and Jetpack Compose for Android, iOS and Desktop. This is nice because it means you can do things like consistently use multithreading throughout, share libraries, use GraalVM native image to optimize startup time and memory usage on desktop, have low latency UI everywhere, work offline, use files, integrate with the host OS and so on. This is one reason I created Conveyor (https://hydraulic.software/ https://hydraulic.software/) - if you go this route without it then you'll hit the painful desktop distribution process. With Conveyor it's no harder than publishing a static webapp, and you can avoid the desktop app stores with their various rules and rakes.

dariosalvi78 4y ago

They basically reinvented Cordova

jacobp100 4y ago
Cordova would be a lot more performant for their setup. Right now, they spin up a JS VM, parse and evaluate ~800kb JS, then call out to native to add a web view. It’s a lot to do - and only really worth it if you’re using the rest of RN

andrewstuart 4y ago

You can build cross platform single code base mobile apps with Delphi. https://learndelphi.org/kiskis-the-crazy-social-network-for-android-and-ios-in-delphi/amp/ https://learndelphi.org/kiskis-the-crazy-social-network-for-...

yellow_lead 4y ago

> Packages for React Native are their own special breed of monstrosity because the package author would be the one writing code twice: once for iOS and once for Android (and of course the JavaScript wrapper). The result is a drastic increase in library abandonment and stability issues. In addition, keeping your packages in sync with the latest version of React Native (which is notoriously difficult to keep up to date) was a nightmare of its own. This is an accurate observation. I notice the same thing. It doesn't help that there are N Android versions and M iOS versions as well

gauddasa 4y ago

With tons of effort put on browsers to adhere to web standards and seamlessly interface with different kinds of hardware and platforms, the nasty hard work has already been done. How many times will the wheel be reinvented? It is consumers who should openly demand for web applications and resist efforts pushing for app alternative. This will help the consumers hide their backs and developers save their backs.

krzat 4y ago
On desktop this is already settled and most of everyday stuff is done through websites or electron apps. I suspect that Apple/Google will never let this happen due to 30% tax they steal from devs.
- sfe22 4y ago
  Apple google don't “steal” from devs. Devs are a business and if they are worth their salt they account for business expenses in their pricing. If anything Google and apple “steal” from their OS customers. This is the same as saying government steal from corporations, while technically true they in reality steal from citizens as businesses account for their government expenses in their pricing.
scrame 4y ago
But then how would a crappy fly-by-night startup pull in all your local data and sell it off when the VC money runs out?

gloosx 4y ago

React Native, which was meant for writing amazing native apps, is just misused as a browser web-view thing. I am an expert in this field. Just never use React native to open single WebView. Never try to turn your website into mobile app like this. If it's a website, it's a website. If you need app make app. React, Electron and React Native enables you to make apps using Javascript, which is same as your website, it means you can have the same business logic between web and native app, same language it all written in, team talking on the same language, only the rendering logic will be different, which is huge saves. But it's not Flutter. It was not meant just to present webviews with your webpage. There is a Browser for that. Finally there is a PWA for just exactly that. Amazing stuff which React + Electron + React Native enabled - abstracting JS from Web to App - is so much crooked by folks trying to turn it inside out React Native is not the future – for folks who don't understand how to use it. In fact they hate using it wrong. For me – it's the future, i can use only one language to create an Android, iOS, Windows, Linux and Mac native apps. (of course, i would never try to fit it into a single front-end codebase, this is pure madness)

supermatt 4y ago
> of course, i would never try to fit it into a single front-end codebase, this is pure madness If its a single app for multiple platforms, and you are sharing code and views, why wouldnt you fit it in a single codebase? Surely to do otherwise would be unnecessarily complicated?
- gloosx 4y ago
  Because two things, UI is different between platforms, to make a quality native-feeling app, you will have to use the design guidelines and native elements of every platform. What you can share is the business logic, abstract ui logic, but not the views themselves. You absolutely don't need to merge codebases in order to share something between them, you just need to have it portable. Having one mega-app seems more of a complication to me.
  - davedx 4y ago
    Think people are talking about different things. When I think about sharing the same code base I think about a single repo with lerna packages, where a lot of the common code is in packages, and each platform's native app is also its own package with its own build toolchain, that pulls in the shared code packages.

diimdeep 4y ago

The only way to survive with a single code base is to go the way of gamedev, to own the substrate you are running on completely. From rendering of fonts to user input. This, of course, depends on the complexity of software. App in this blog post is not really that hard compared to the effort any game would need to go to render on screen. C'mon, it is just a text editor, there is not much of anything there really. All this just shows the state of modern development of too many abstractions for really nothing in exchange except a slow, overengineered fashion hype train. Surprised, there is no mention of WebAssembly in there. (edit typos)

barrkel 4y ago
I assume you're sarcastic, because creating a good native editing experience from the ground up is not trivial, when you try to make context menus look native, have native editing keyboard shortcuts, integrate with system IMEs and accessibility for screen readers, etc.
- diimdeep 4y ago
  No. There are absolutely no problems with providing accidental native context menu elements or integration with menubar, etc. BTW, I just tried this app on Android, it is broken, it is simply showing white blank screen. And on macOS, and it asks $90 a year for basic markdown features. Just no. And then, there is this. https://standardnotes.com/principles#negativity https://standardnotes.com/principles#negativity https://standardnotes.com/longevity https://standardnotes.com/longevity We are complexity bigots. We don’t merely hate complexity in software—we detest it. This is literally contradicting the technology stack that they chose. In the end, it seems to me like a low effort, money making enterprise with some sprinkles and wishful thinking.
  - barrkel 4y ago
    How many times have you tried this? Text editors are not easy to write. There's a wonderfully fractal level of detail. The differences in text editing experiences between platforms abound. The boundaries the cursor moves to for different inputs; e.g. are spaces skipped when moving word by word; are they only skipped at the start, at the end, or does the algorithm change depending on the direction of cursor travel. How selection changes from character-based to word-based if it starts with a double-click. How the scroll position changes based on cursor movement, selection extension drag, and so on. Do you support multiple selection of text? Windows' built-in text box does, if you hold Ctrl down, you can select multiple discontiguous text ranges and delete, cut or copy them. Cursor navigation isn't trivial. In word-wrapped text, a single location in the text can be represented by a cursor at the start of wrapped a line or the end. Do you go with what Emacs calls goal column (i.e. when cursor passes through short lines and needs to move backwards, does it "remember" where it was when you cursor through to a long line again)? Or does it gradually work its way back to column 0. And of course for variable-width fonts, targeting needs computing in pixels, not characters. It's extremely rare for games to include a fully featured text editing experience. In the old days, you'd consider yourself lucky to get a navigable cursor over fixed-width text. Even today, where games take text input, it's frequently a simple one-line text box with just a navigable cursor and no selection. Games also take a big shortcut on performance: a game loop is always running, always presenting frames ideally at the refresh rate. An editor can't afford that, it consumes too much energy. So now you need to worry about dirty regions and damage control, efficiently filling in areas revealed by scrolling and edits, taking care that letters may extend beyond naive bounding boxes, whether due to ligatures, kerning, anti-aliasing, and so on.

kbcool 4y ago

> There is also no practical way to build on React Native without using a metric ton of third party libraries As an author of a few quite large React Native apps I have to disagree. There's a few key ones and apart from that it's down to maturity. Immature developers will always reach for whatever crutch they can find first. Doesn't matter what language. The same immaturity shows up in their attempt to recreate (a not so great) wheel with their Phonegap/Cordova clone. I would seriously be embarrassed about an article like this if it was my business.

krosaen 4y ago
Can you share more about your RN apps? Would be great to have some more examples.

obrhoff 4y ago

People don't speak about other approaches. For example my team adopted the BFF (Backend for frontend) pattern. Android and iOS Developers work together on a shared BFF and encapsulate there as business logic as possible. Also we define OpenAPI specs on the BFF to generate data models and API code for the clients. It works pretty good for us.

danieldisu 4y ago
The ol’ moving more logic to the backend I see this being a trend in the coming years
jacobr 4y ago
Isn't a shared BFF an oxymoron, considering that you typically build a BFF specifically for one client and its needs? Maybe you just have a backend :)
- obrhoff 4y ago
  If you want to nitpick ofc. in this case its about mobile.

bundie 4y ago

[dead]

ndomanop 4y ago

I've also been wondering why people still use ReactNative despite the availability of much simpler stacks. For me I use React to create User interface for all platforms then ship it as a mobile app using native webviews on Android and iOS, also I can use Electron to create a desktop version. Good thing is that these webviews offer Javascript Interfaces where you can access all native functionality you need. With a little bit of craftiness you can make your React Code (User interface) detect whether it runs on web version, mobile version or desktop version then make it behave according to what you want. I choose React for UI coz it's damn simple though you can use any other javascript based UI library.

jeswin 4y ago

If an app is available in native and PWA/webapp versions, I always install the PWA/webapp version. It's usually lighter, is better w.r.t. privacy, will need fewer permissions, and might allow copying text.

josefrichter 4y ago

User experience. It seems like it’s rarely mentioned in discussions like this. The sad truth is it’s usually sacrificed. This approach, as well as RN, will never give you the experience you get from native app. That applies to Standard Notes app too - it’s not great, not terrible. I understand using RN for an MVP when you have no money. But many times I feel like the issues described are organizational rather than technical.

Farreation 4y ago

These note apps created by tiny companies are useless and trying to reinvent the wheel. Standard notes has no reason to exist because Apple Notes and Google Keep already fill that niche better, and they actually know how to code, contrarily to these buffons.

anonred 4y ago

I look forward to the blog post in 2 years where Standard Notes realizes that reinventing Cordova was not in fact the right solution to building a high quality, cross platform app!

samirsd 4y ago

when you optimize for engineering effort rather than user experience you choose react and accomplish neither

cenny 4y ago

We do cross functional mob programming at my company with native iOS and Android apps. Works like a charm with a small team and I don’t think a react native app would offer any advantage. Instead we try to build the best app for each platform as one team. I’ve never believed the hype of code once run everywhere. All solutions have drawbacks you just have to pick one.

6510 4y ago

Okay, let me be that guy... I was that guy telling people no no don't send your customers to Facebook, Noooo twitter is not the superior RSS replacement. Live journal is the wrong choice, your Myspace efforts are not history in the making and your Geocities was historically just as much a waste of time. Flickr is not the place for your family album and neither is Picassa. There are countless active platforms and other walled gardens that offer actually great tools and do just what you want them to do but the thing is, non of it is yours! You are not making something for yourself, you are working to enrich the Zuck who can turn on you at any moment, from a benevolent friend to a brain eating zombie overnight. Take youtube, its still a great product but it's nothing like the fantastic thing it started out as. Yours may one day go from a popular channel or from quality content to being not advertiser friendly. You've invested countless hours only to be discarded with various motivations. You helped build these digital prisons, no faith can be cruel enough. Who cares that web is slower than native. People with slow phones should buy a faster one. If they cant afford to they have no money for you either. We pretend phones are not fast enough to do anything?? They are insanely fast compared to desktops from not to long ago. The only reason they are slow is that you've piled to much crap onto them, crap that shouldn't be there. I suggest we stop executing tasks and just pile them up, gradually execute them little bits at a time. Don't let anyone else manage this for you! Others will think their stuff takes priority over the user trying to input text. If I'm inputting text I honest to god want all other processes suspended until I'm done. Perhaps if I'm not typing for 20 seconds, gazing at the input area, perhaps you can send me a push notification. Its still heretical interference with the writing process. Apps are slow because the user just isn't important anymore. To do a silly analogy: Some people get stuck in a monologue, say after 2 beers. Others may find themselves unable to get a word in. The problem is not that they are not talking fast enough.

pat64 4y ago

Having read through the comments and tried standard notes I can see why users might have been disappointed going from native to this web implementation. I recently went through the process of switching to a web stack from a native iOS stack when it came time to support Android with one of my apps (https://getradiant.app/ https://getradiant.app/) and my biggest concern was making it feel a near as possible to the native app it was replacing and having it perform as well as possible on older Android devices. It turned out quite well and I’ve never had a user complain about the transition. The trick to my mind was to treat web dev like mobile dev. Focus on bundle size, load speed and fluidity within the confines of a mobile environment. Constantly compare what you’re building to a native app. Probably focus on SPA over SSR/MPAs. And remember, if you apply all of the above to much less restrictive desktop browser environment with a much higher performance ceiling, the experience is going to be pretty good. TLDR; think small, think fast and start with the most constrained environment you’re targeting, usually mobile, usually older Android. If you understand the limitations and considerations of browser engines when taking into account the above, the rest will follow and you’re going to have a good time.

randyrand 4y ago

I wish they went more into how they architected a complex webapp. Vanilla html and js?

jamesxtreme 4y ago

Why not use react-native-web and target all three platforms at once?