[moughxyz]

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

[Aaargh20318]

Tried the demo and it feels like a web ‘app’.

Nothing says “I don’t give a crap about our users or the user experience” like building a web app or using a cross-platform toolkit. It telegraphs you mainly care about doing it as cheap as you can instead of just building a good app.

The only way to build a decent mobile UX is by making an actual native app.

My experience with XP tools is that if you build anything but the most trivial of apps you keep running into issues where you have to do platform specific workarounds. Eventually it becomes an unmaintainable mess of exceptions and workarounds.

In the long run it’s faster and easier to just build a native app for each platform. That way you can provide the native UX a user of each platform expects without compromise.

[wiseowise]

> just building a good app.

> just

?

> The only way to build a decent mobile UX is by making an actual native app.

And that’s the problem.

[ramesh31]

>The only way to build a decent mobile UX is by making an actual native app.

But React Native is an actual native app. It is entirely compiled down to native code for your respective platform. I agree that the "hybrid" approaches of days gone by (Ionic, Cordova, Phonegap, et. al) were a terrible mess. But there is fundamentally no reason why RN cannot be equally performant to Swift/Kotlin based apps.

[cageface]

This is not accurate. There’s a JS bridge to a lot of non native elements. You can get acceptable performance out of RN if you know what you’re doing but it will never match true native code.

[acchow]

> It is entirely compiled down to native code for your respective platform

Has this changed recently? It’s been my understanding that react native has corresponding native components for many UI elements and uses them. But your react logic is still executing as JavaScript.

[ramesh31]

> But your react logic is still executing as JavaScript.

Yes, but this is no different than how native works. On iOS, The JS Bridge compiles to bytecode and talks to the Obj-C runtime for native needs like Cocoa, just as Swift does.

Sure you could get better performance by writing your apps directly in Obj-C, but I don't think many people want to go back to those days.

[dlivingston]

Sorry... what? The more I read this, the more asinine it sounds.

Some definitions:

- The Obj-C runtime is just a shared library that Swift links to on compilation (/usr/lib/libobjc.A.dylib). The performance to call into it is identical for Swift and Obj-C.

- "Sure you could get better performance by writing your apps directly in Obj-C..." Swift code is native code. Cost to access the runtime is identical.

- There is one "hop" to go from Swift to the Obj-C runtime.

- There are >2 "hops" to go through the JS Bridge. https://hackernoon.com/understanding-react-native-bridge-con...

[claytongulick]

> the more asinine it sounds.

HN is better without personal attacks and insults.

[pixel_tracing]

I’m sorry what?? Native code gives you access to libdispatch and concurrency. RN is single threaded. There are a myriad of processes, shared memory, optimizations, and daemons that run on your phone that coordinate better with native binaries.

Web won’t beat native on mobile phones, I’m sorry this argument has been had every single year it’s just absurd we keep arguing about it.

RN is implemented due to developer productivity at the cost of user experience. Which is fine more power to you, but understand that it doesn’t imply better UX.

The barriers to creating apps is also getting smaller (SwiftUI & Jetpack Compose).

Source: Multiple years working on Core Apple systems at Apple and also multiple years at Google

[dmitriid]

> Web won’t beat native on mobile phones

Honestly, it won't beat anything anywhere, but people do keep on trying to make it work.

[foreverCarlos]

I don’t think many people left those days TBH. I personally saw how 2 large RN efforts have been rolled back to native at a big tech company. I don’t know whether RN is gaining traction or is stagnating - would love to see some stats.

[acchow]

You mean Facebook sized large? Not every company has the resources to hire a full on Android and iOS team. So they write React Native instead, which is good enough for most.

[acchow]

Objective-C actually gets compiled down to machine code at compilation down. When you download an app from the app store, there is no more Objective-C.

RN doesn't "compile" the Javascript to bytecode or machine code. Instead, the closest competition you could get from RN is a JIT. But AFAIK iOS doesn't allow a Javascript JIT to run, so the JavaScript running is not being JITed to Bytecode.

Even if you assume that iOS allows a JS JIT now, you still have a JavaScript->Native bridge to cross. This adds a performance hit that Objective-C does not have.

[t3rra]

You have no idea. Swift is compiled into native code on build time

[lawgimenez]

You do realize that RN runs on single thread right? Have you tried implementing background processes in RN? I suggest you try also implementing push notification in RN.

[wiseowise]

React native uses native widgets and has bridge to communicate with platform. It can’t be as fast as native apps by definition.

[echelon]

> Nothing says “I don’t give a crap about our users or the user experience” like building a web app or using a cross-platform toolkit. It telegraphs you mainly care about doing it as cheap as you can instead of just building a good app.

What a better world we'd have if Apple and Google agreed upon a common UI toolkit baseline.

I'd rather a small, scrappy company spend their limited resources on solving their core competency and value prop than fitting to these two stupid and needlessly different platforms.

Web should have won. It still has a good chance. We should have a "native web" in the future: WASM, hardware renderer access, device control, and more. That'll be the target to develop for.

Building for Apple and Android is a total waste of annual human cognitive resources. I hope every company starts doing cross-platform.

[chii]

> Web should have won.

the web has won for a lot, but the companies that want to own their ecosystem, and have learnt from their past mistakes. Mobile is a fresh start, and they specifically made it so that web is a 2nd class citizen.

[steve1977]

Web is a 2nd class citizen because it’s designed for documents, not for interactive applications. All the application bits are afterthoughts and bolted on and it shows.

[chii]

By the time mobile was established as a platform, the web is known to be an application delivery platform.

The fact that platform owners such as apple (or indeed any of them, not just singling out apple) did not make it first class is evidence that they prefer to own the platform rather than operate an open platform.

Microsoft, with windows, did not understand this at the time when they had huge advantage with win32, and thus did not lock down the windows platform. You see them trying now, with windows app stores (which i'm glad is not succeeding).

apple has more foresight, and decided to lockdown their app ecosystem. They deliberately removed flash as a form of application delivery, because they know that it can be good (if only adobe could pull their shit together).

The fact that the web still can remain, and that people still use it, is testament that even for a system being hindered, it provides enough value. Unfortunately, it just cannot complete against platform owners who would preferentially make their own native platforms better than web.

[steve1977]

Apple actually wanted to have only web apps on iOS initially. They only published the iOS SDK after the outcry of developers, because web apps sucked so much.

I remember this well, as I was already developing with Cocoa on Mac OS X and was pretty disappointed in the beginning when there was no SDK for iOS.

https://en.wikipedia.org/wiki/IOS_SDK#History

https://9to5mac.com/2011/10/21/jobs-original-vision-for-the-...

[mike_hearn]

Google was and still is the canonical Web Company. Android went with Java and custom APIs over the web stack. More than a decade later and this hasn't changed. The new Android UI layer is Jetpack Compose - again, not the web.

At the same time, Palm decided to redo their own OS and they went all-in on the web stack. They even called it WebOS. Palm were a well known name with momentum and talented staff, but WebOS was a failure partly due to poor performance.

[dmitriid]

> They deliberately removed flash as a form of application delivery, because they know that it can be good

That is definitely not why they removed it. All the reasons Jobs listed against Flash were 100% true and a year later Android followed suit.

[wiseowise]

> Web is a 2nd class citizen because it’s designed for documents, not for interactive applications.

You’re talking about UI part, which hasn’t been a problem on mobile for a good 10 years.

[steve1977]

It still is a problem.

[crossroadsguy]

> solving their core competency

And what is the core competency?

- yet another syncing backend in 2023?

- figuring out another encryption?

- writing yet another web app in the guise of a mobile app?

- writing a notes app that locks the content and doesn’t even let you have raw files on your computer in easily readable format?

This is just absurd reasoning.

[wiseowise]

Things you’ve listed would be there regardless of platform they use.

[foreverCarlos]

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]

Indeed, compared to any native app it’s terrible.

If you care about UX, you should make native apps.

[Firmwarrior]

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

[foreverCarlos]

I am not trying to nitpick - just giving my honest feedback. This submission is not for a technological breakthrough that I would admire from a theoretical perspective.

This problem has been solved many times over the last decade or so. So claiming that _this_ is the future and not the more established (and smooth!) solution has to be supported by at least some evidence.

[mromanuk]

UX is a real thing. Any user that feel your app is crappy, slow, inconsistent, ugly, breaking OS paradigms, janky. Will just dump it, and just get another one (there are plenty) Users are the real judges giving you the Award of Excellence, any minute they keep using your app

[dontlaugh]

It’s perfectly reasonable to not care that much about UX.

We should however be clear about our trade offs and not pretend that web apps can replace native apps.

[wiseowise]

> pretend that web apps can replace native apps.

We don’t need to pretend. Web apps must and already did replace a whole class of apps that never should’ve been native to start with.

For example: why would you even need native app for HN?

[dmitriid]

Depends on the app. For example, I'm using Wikipedia's excellent native app even though Wikipedia is basically text-and-images only site.

I could imagine a nice native app for Hacker News, too

[dontlaugh]

I pretty much never use the HN website, fwiw. The UX is worse than the iOS app Hack.

I’d hate to use a web app for maps, notes, document writing, IDE, messaging, etc. I always prefer a good native app to a good website.

[xwowsersx]

Hmm, I was really intrigued by this post and am thinking about digging into capacitor a bit. It does seem to me, however, that there are often subtle ways in which the fact that an app isn't native bleeds through. For example, trying the demo you linked to: if I click on one of the notes in the list and then swipe right from the edge of the screen in order to go back (gesture navigation), I expected it to behave the same way the arrow in the top left would, but it doesn't and I found myself back on some other website. Maybe it doesn't work like this if I actually download the app on Android?

[pohuing]

One more thing to tidy up: your full screen hamburger menu in notes on android chrome/Firefox can't be dismissed with a back button press. Instead that closes the entire app, because apparently you're also missing a navigation stack?

[mccorrinall]

I used this in firefox on ios and the zooming bugs are awful: https://streamable.com/qnxz2z

[theCrowing]

Sorry but it is janky asf... and if it's easy to fix why deploy without said fix. Uninstalled. Unsubscribed. Alone for the condescending tone of this comment. At least the export is easy. sic.