Hacker News Reader

It may be ”single language”… until you have to dive into the insides of a React Native library at which point you also have to know at least Java AND Objective-C. Add to that Windows-specific language(s) if your library will want to support Windows.

And let’s not even think about those cases when a feature is written with not all the platforms in mind. I once had to fix a bug where a developer did not have access to an iOS simulator to test their pull request… so they had merged it in without support for iOS.

I would say... In a smart company, you would enjoy learning some* ObjC and Java while working on a React Native app. It can be tough, but at the end of the day, we nerd hackers know Python and C and Java and bits of C# and objC. If you have to dive into Native internals, it can be a really fun journey if your boss tells you to explore and research it carefully, but it can be really confusing if you on a tight deadline.

> developer did not have access to an iOS simulator to test their pull request

This is clearly a company's fault, just get him iPhone and Mac if he delivers mobile apps LOL

* and you really don't need much, unleast you need to implement a working WebRTC protocol from scratch, haha

Most importantly platforms like RN substantially lower the barrier to entry for making mobile apps, and cross platform ones at that. Whenever you lower the barrier to entry to something you inevitably attract low quality, low effort content that can obviously damage the perception of the broader platform. Setting that aside however, the development agility that RN provides I think is priceless. Most apps don’t need maximum performance, or the usage of niche platform specific APIs and so the time you’d spend working with two standalone codebases can be reinvested in your actual product and not mental overhead.

> 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?

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.

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.

You're proposing a perfectly fine setup, what people are trying to do is just a single web app for every platform, they achieve this by releasing their own web browser app which opens just their page

> you will have to use the design guidelines and native elements of every platform

This is exactly what react native does. It uses native components (there is a cross-platform abstraction, or you can use the platform-specific components directly) and you implement the design guidelines in platform specific files: https://reactnative.dev/docs/platform-specific-code

> but not the views themselves

Without the views, why would it be in react native? React is for building the UI...

> Having one mega-app seems more of a complication to me.

single codebase != mega-app. There is no "mega-app" as the compiler only uses the code for the target platform. You can even target specific architectures and/or devices as it uses the native sdks behind the scenes.

I think we're battling on the same side, I was generally speaking about subject of the OP post, where people make one web mega-app for all platforms with the same views, achieving this kind of single-codebase ;)

Oh! im with you. You mean that the views should be taiulored for each platform, not the same UX everywhere. Yeah, totally agree with that!

I run a fairly popular mobile web app and the most common request is for me to release it as a native app. I try to tell them that the app would just be a web wrapper and that they wouldn't get any different experience than from running it in the browser, but it doesn't matter. Even after showing them that they can install the PWA they just say "I'll come back when you release it as an app".

My point is that users don't care if just showing a website in a WebView is misused technology. They want an app regardless and telling them "a website is a website" is futile.

Or the users are not sophisticated enough to know the difference.

I would say it's a big misconception, when users want native app they don't want webview, native apps on each platform have a certain look and feel, as well as baseline performance, which they are used to. WebView will never be able to provide these key things, and it is prominently noticeable to most they are using one or another. So don't try to fool your users, then they want native they want native, and React Native is a perfect thing to build it using same technology as the Web, just with these crucial Native elements.

No, that's not correct at all. They want my web app as an app in the App Store/Google Play, even if it's just a WebView wrapper. I don't want to dox myself but it's more of a game than a regular application and all elements are custom graphics so there wouldn't be any native elements regardless.

Your case might be outstanding, surely there will be a situation where this is perfectly applicable, say you need such an app where utility prevails over the design, or maybe your html5 game works perfectly in the web view. For sure, you can take one of the custom browser solutions, and release a new browser just for your page, but it is not RN use-case, just use Flutter in this case

I do agree that native apps are better (mobile dev since 2009) but there are definitely ways to make your web app feel better and less sluggish if you care enough. Most shops don’t.

How would you make a multi-platform rich text editor in React Native?

Just like any other app. In React Native, there is a TextInput component which is fully under control, from caret position to nesting typography rules. You can build up all logic you need for text editing based on it.

TextInput does not appear to be rich text, I don’t see a way to represent bold text in the docs, much less complex rendering like @mentions tokens, images, or tables. Unfortunately when I Google “rich text input React native”, all the libraries I found use a Webview internally.

Can you explain in more detail how you’d style a Heading element, block level image element, and a Quote element within the same editable TextInput? The important UX feature is that the user should be able to start a text selection in a Heading, and end the selection in the Quote, so when they press delete, the image is removed and the quote is merged into the heading.

I personally implemented web-compatible rich text using TextInput and I will share some of my knowledge here which hopefully fills the gaps for you.

1. Most useful resource for creating this feature would be official TextInput doc [1], no need for googling.

2. Unlike Web, it is possible to nest <Text> elements inside <TextInput>, which is what you need to use for styling your blocks.

3. So finally, you will need your Rich State, and you need a Parser function, which will translate this Rich State into a collection of <Text> elements representing your blocks.

There is a lot of nuance still, say, Image elements cant be nested directly into TextInput, so you need to generate a spacer Text block where you will host your image. Also it requires some bits of excellence to work out the selection and caret logic correctly, but overall – it's not that big of a task, I would do it in few days

[1] https://reactnative.dev/docs/textinput

You do need to Google because the docs never mention that TsxtInput can contain Text!

In fact, never otherwise is mentioned, so generally you should feel free to experiment nesting everything inside anything unless otherwise mentioned explicitly. Of course you will discover that TextInput is only rendering Text elements this way, surely it's not documented well enough, although you should 100% of the time understand it's not the web and, with many many familiarities, things still work different here

I think this is the key reason why going hybrid native with a lightweight WebView was needed at Notion. If there was a ProseMirror-like standard library for rich text editor available for crossplatform, with:

- Native editor for IOS - Native editor for Android - Native editor for Web - Electron/Native desktop, etc...

These editor can share code via a clean architecture inspired state plugin hyerachy that's swappable (i.e, a shared provider that swap out state and data routing per platform). Then with metro or esbuild you can selectively prune the code branch. The UI can be done in RN-web if lazy or straight up native code. It doesn't matter at this level.

Then, anyone who wanted to clone Notion can consume this component in their RN app. However, this is against Notion interest atm afaik, since Notion must keeps its advantage (make it harder for people to clone Notion). I'd argue it will try to shutdown such an initiative until it found a better way to have an edge on these competitor (or maybe shift to a new market)

Facebook is building a framework with native components in Lexical: https://mobile.twitter.com/peterfriese/status/15674455305815...

I don’t know how we could possibly shut this initiative down, but I guess I should try!

For us to build such a project without backing it with a webview would probably take an order of magnitude more engineers working on the editor than we have today.

Agreed. I would even call such initiative premature optimization, with unknown gain compared to just optimize the WebView component in the native shell if that's ever needed. More so for any new startup trying to enter the KMS space in general.

I don't think Notion need to worry about FB. I think Notion might need to be worried about the potential market saturation caused by how easy it will be for a small team of 3 to clone Notion (and all of its integration, API, and so on) on all platform perfectly in a weekends. At that point, it's not the technology bottleneck anymore but more so a battle over branding and minor UX improvement.