[HN Gopher] New Architecture is here
___________________________________________________________________
New Architecture is here
Author : stigi
Score : 129 points
Date : 2024-10-24 17:28 UTC (5 hours ago)
(HTM) web link (reactnative.dev)
(TXT) w3m dump (reactnative.dev)
| ramesh31 wrote:
| Is there any sane way of using RN without locking into the Expo
| ecosystem? Last I checked it was a nightmare dealing with native
| dependencies otherwise.
| l_r wrote:
| Config plugins have made this way easier - you're now able to
| hook into the native code generation process to add native
| modules that aren't already packaged for expo.
| k4rli wrote:
| Been working on one RN project Expo-free since 0.6x. It's
| really not needed at all, neither is it complicated to set up
| without Expo.
|
| I've only used Expo during hackathons and university to quickly
| get something running, but for actual production apps it's
| should be avoided imo.
| stuckinaloop wrote:
| that's an interesting perspective, curious to what your
| reasons are for avoiding expo in production?
| diggan wrote:
| Last time I played around with React Native was probably
| around when it first launched, there was no Expo then, and
| I haven't used React Native since so I don't even know what
| Expo is.
|
| But another commentator wrote "yet another SaaS with
| questionable payment tiers" about Expo
| (https://news.ycombinator.com/item?id=41937886) which makes
| me already not want to use it if I ever touch React Native
| again. Not sure why a SaaS would be involved at all in this
| process.
| tcoff91 wrote:
| You don't have to use Expo's SaaS to use Expo. Expo
| framework is 100% FOSS. However Expo Application Services
| is a really great SaaS product for doing things like
| cloud builds and Over-The-Air updates.
|
| The anti expo sentiment is almost all based on the old
| days where you had to eject to use native dependencies.
| Expo is amazing now.
| martinsnow wrote:
| I love that you asked this question. As someone who has created
| a few react native applications in the past, non expo
| environments has felt as an afterthought. I hope the react
| native team will improve the documentation and encourage the
| native platform as well as the expo platform. Some of us don't
| want to be locked into yet another SaaS with questionable
| payment tiers - when building your own modules and publishing
| is:
|
| - Easier in the long run
|
| - You're able to ship a far more featureful application if you
| deal with media and/or VoIP
|
| - Passing apples reviews seem to be faster if you ship the
| modules yourself in my experience
| RussianCow wrote:
| > - You're able to ship a far more featureful application if
| you deal with media and/or VoIP
|
| Can you expand on this? How does Expo prevent or make it
| harder for you to ship media- and VOIP-related features?
| martinsnow wrote:
| When you're using expo you cannot bundle your own native
| extensions. At my previous job we used pjsip. This
| extension uses JNI and native calls in iOS via objective-c.
| You can't bundle native extensions when using expo. You're
| locked to their prebuilt ones.
|
| To use your own extensions you have to eject/or start a new
| application with their own native libraries. For most of
| what expo does you can use the unimodules libraries,
| they're quite good in my experience.
| RussianCow wrote:
| > When you're using expo you cannot bundle your own
| native extensions. [...] You're locked to their prebuilt
| ones.
|
| Unless I'm misunderstanding what you're saying, this
| isn't true at all. At $day_job we have an Expo app with a
| custom native library and it works just fine; you just
| have to write an Expo-specific adapter for it and can't
| use Expo Go in that case.
|
| Source: https://docs.expo.dev/workflow/customizing/
| davmar wrote:
| how long ago was the last time you checked?
|
| expo has solved the native dependencies issue, and it's a
| fantastic way to build an app.
|
| this is one of the few hills i'm willing to die on. expo is
| great for the RN community.
|
| also you can download my RN expo app here: www.shopcats.app.
| tcoff91 wrote:
| Having used bare RN for 5 years, and recently started using
| Expo, there really is no reason to not use Expo at this point.
|
| The native dependencies are 100% solved by prebuilds, CNG, and
| config plugins.
| s_tec wrote:
| React Native added auto-linking years ago, which solved the
| native dependency problems. Just `yarn add` whatever you need,
| and if it has native code, the the Android side will
| incorporate it on the next build. On the iOS side, you do have
| to run `pod install` to lock in the changes, but everything
| after that is automatic.
|
| Use Expo because you like the extra features it ships with, but
| not because you have problems with native dependencies. The
| React Native built-in experience is pretty much perfect to
| start with.
| pbreit wrote:
| Could someone suggest a good CRUD starter kit?
| matlin wrote:
| I've used React Native quite a bit in the past and I gotta say I
| wish it didn't have to exist at all.
|
| It's often times fine on iOS and then incredibly slow on Android.
| Hermes is very exciting but still requires many polyfills to make
| simple NPM packages work. I hope one day, the web (and embedding
| web apps on mobile) makes React Native fully obsolete.
| DCH3416 wrote:
| Who would've thought steve jobs was right (although premature)
| with the initial iPhones only having web apps.
|
| That's interesting though, I would've expected iOS to be slower
| with android largely leveraging chrome because Google.
| pbreit wrote:
| Premature by 17+ years? He was and remains completely wrong.
| DCH3416 wrote:
| No? Most modern apps these days _are_ just web apps. Why
| does it need the overhead architecture of running full
| standalone applications when a web clip works just as well?
| Plus there's no need for updating.
|
| The problem at the time was multifaceted. The devices
| couldn't handle it, the network couldn't handle it, and
| webkit was still relatively limited. But it did work.
| https://9to5mac.com/2021/06/03/remembering-apples-sweet-
| solu...
| jonas21 wrote:
| If that's the case, then why does nearly every company
| have a native app in addition to their website? Surely,
| they could save a lot of time and money by just not
| building and maintaining the app.
| DCH3416 wrote:
| Because it's a pain in the ass to distribute. And there's
| not much for support integrated into mobile operating
| systems for seamless browser windows.
|
| MacOS is getting there kind of lately with safari being
| able to turn web pages into apps. But there isn't really
| built in mechanisms for that:
| https://www.macrumors.com/2023/06/14/how-web-apps-work-
| macos...
| ChocolateGod wrote:
| Web apps will always on paper be slower (not including
| badly made applications on both) than native apps, and
| also bring in additional security issues (since code is
| loaded remotely) than native applications.
| johnny22 wrote:
| apps built using the webview don't necessarily have to be
| loaded remotely. If you're building with capacitor, then
| nothing happens remotely until you choose.
|
| The part about being slower is still true though.
| slothtrop wrote:
| Native apps make more money, because of phone data. A lot
| of effort is now put into facilitating cross-platform
| builds, a wrapper/container around a glorified web app is
| among the easiest ways
| chasd00 wrote:
| There's no adblock for native apps. Also, they can keep
| running/monitoring-you in the background easier.
| Miraste wrote:
| I have never, ever used a web app that runs as well as
| the native app.
| skydhash wrote:
| Most modern apps are just services. If you don't mind you
| computer being a thin client to someone's computer on the
| internet, go ahead. But the rest of us do use native
| software because the web is just a pale imitation.
| candiddevmike wrote:
| With all of the APIs _modern_ browsers are exposing these
| days, web apps are extremely capable and remain the best
| multi-platform solution.
| martinsnow wrote:
| Reddit is a better place for non technical discussions.
| martinsnow wrote:
| That doesn't make sense to me at all. When you delegate heavy
| workloads to native view engines, both rendering and
| interfacing with native media/sdp will undoubtly be faster. The
| only issue i can see is if you install a lot of web only npm
| packages which has to go through the translation layer.
|
| That's not what react native is for. Its for building native
| applications with a react-like syntax for the views. To me it
| seems like you used hammer to put in screws, no?
| ARandomerDude wrote:
| I've had the complete opposite experience. React Native has
| been amazing for the team I work on. It's fast, quick to
| develop in, and I've never felt blocked. Camera, TCP sockets,
| custom Bluetooth protocols, Protobuf, etc. React Native +
| libraries do it all.
|
| We don't use Expo, either. It's very painless.
| rickhanlonii wrote:
| I helped write this post, so feel free to ask me anything about
| the New Architecture!
| andy_ppp wrote:
| Thank you! Slightly off topic but every time new Xcode versions
| happen or as a result of time passing I always seem to get a
| messed up/corrupted Xcode project and so I end up copying the
| src folder and create a new project usually with an updated
| React Native version. This can be a real pain to be honest,
| taking sometimes a day or two of messing around with package
| version compatibility hell.
|
| Is there a plan to fix this flakiness that I experience every 3
| months or so?
| rickhanlonii wrote:
| Yeah this is a tricky problem, and it's one of the reasons we
| updated our recommendation to use a framework like Expo that
| can make upgrades be smoother by being more opinionated about
| the setup.
|
| As the core library, we need to support all the different
| ways React Native can be added to an app (from fully react
| native to adding react native to an existing app) and all the
| different build tools an existing app may use. So it's hard
| for us to be opinionated about the setup in a way that would
| make upgrades seamless, but a framework can solve this for
| you.
| andy_ppp wrote:
| Maybe I can un-eject given the plugins system from Expo. I
| do not like the way they throw all your code around though
| and I think this ability to steal peoples work given the
| prevalence of LLMs to unobsfuscate code is problematic. You
| should consider providing a way to drop the bundle in in
| byte code or something too... while I'm writing out my
| laundry list of issues ;-)
|
| Seriously, thanks for all your (and team's) hard work, I
| look forward to all my packages being on the new
| architecture and upgrading!
| chacham15 wrote:
| First off, thanks for all the work! I have a few questions if
| thats ok:
|
| 1. What is the next thing that the team wants to focus on
| improving?
|
| 2. What are the performance differences between the old
| architecture & new one?
|
| 3. What are your thoughts on the fragmented state of rn wrt
| react-native-web/react-native-windows/react-native-macos?
|
| 4. It is quite difficult to know what supports RN vs what
| relies on react-dom. Is there any thought to create some
| ecosystem focused around RN? Or if something like that is too
| cumbersone, perhaps even just adding some badge to github pages
| for "Supports RN"?
|
| 5. I forget what it was called, but the creator of react-
| native-web stated that they wanted to start winding down
| support in favor of an alternate approach which attempts to
| bring web apis to native instead of trying to make the native
| api work on web. I.e. instantiate div elements in native
| instead of view. What are your thoughts on this?
|
| 6. React (and IMO Meta as a whole) seems to generally have had
| the tech philosophy of take what you want, leave what you dont.
| With the dropping of create-react-app and endorsement of
| frameworks like Expo, it seems like its getting harder to just
| take the pieces we want. Is there any thought about this trend?
|
| 7. Related: as for the upgrade process: it would be cool if
| there were a way to "opt-in" to auto upgrades. E.g. what if
| there were a package which contained a base class controlled by
| the RN team so that a client side upgrade could be as simple as
| updating the version of the library the base class is in?
| (customization would be simple extending the class and doing
| w/e else needed there)
|
| Again, thanks for all the work!
| jdthedisciple wrote:
| Where are the performance benchmarks (and comparisons with
| Flutter)?
| cynicalpeace wrote:
| Is Capacitor a viable solution yet? I saw this tweet saying "it
| just works" for porting a webapp on NextJS:
| https://x.com/marc_louvion/status/1836023560462360746
| rickhanlonii wrote:
| Capacitor is really cool because it allows you to build a web
| app in iOS and Android and access the platform APIs from
| JavaScript. The rendering layer is a bit different though,
| because in React Native you can use the platform APIs _and_ the
| platform components. In React Native, the views you render on
| iOS are the same UIKit UIViews that a native app would write.
| In Capacitor, these are DOM elements in a webview. There are
| different tradeoffs, but this difference is what makes React
| Native look and feel more native.
| martinsnow wrote:
| In my opinion no. Capacitor has the same pitfalls like
| NativeScript. They're both clunky and lacks proper integration
| between the native layer and the emulated javascript world.
| minhnhut wrote:
| No matter what framework you roll with, you're gonna hit the
| same ol' clunky mess--it's just how app development goes.
|
| The trick is, some frameworks smooth over the rough spots and
| throw a few sweet perks your way, while others give you a
| taste of both the good and the gritty.
| martinsnow wrote:
| That is true and neither platform is free from their
| issues. But NativeScript, Capacitor, Ionic and at last...
| Cordova. Has each of ther own oddities. NativeScript has a
| really awesome typing translation of the native apis to
| typescript. That's honestly the most fantastic to work with
| of any of all of them. Great for prototyping.
|
| But when it comes to performance. None of them beats RN.
| You can make some good looking continous animation of most
| of them (not cordova or ionic). But when it comes to lag
| when moving between screens, RN on mobile comes on top
| without doubt.
| serial_dev wrote:
| It's a very basic, indie hacker, habit tracker app, if
| Capacitor wouldn't "just work" for that, that would be _really_
| bad.
|
| Most mobile apps (at least the ones that get you paid), though,
| are different, usually need good quality integration with
| native APIs, keyboard, etc...
| jurmous wrote:
| I have built a React Native app in the past. Nowadays I would go
| for Kotlin Multiplatform. It is already the primary language on
| Android and now it is possible to create native binaries on iOS.
| With Compose multiplatform it also has the ability to also share
| UI code with a declarative syntax on multiple platforms.
|
| I think React Native was the go to place in the past but it has
| been surpassed now.
| theThree wrote:
| I did a performance test last year, rendering thousands of views,
| and Flutter's rendering speed was 5 times faster than React
| Native. I wonder if this version will be improved after the
| update. Interestingly, I used React on the web to render the same
| number of views, and its speed was much faster than React Native.
| Zelphyr wrote:
| I'm speaking out of turn here since I'm not a React Native
| developer but, it seems to me that it suffers from the penalty
| of having to use the JS bridge that neither Flutter nor web
| use.
| rickhanlonii wrote:
| In the post we explain that this release removes the bridge,
| so the JS thread calls C++ directly without a queue,
| serialization, or bridge:
| https://reactnative.dev/blog/2024/10/23/the-new-
| architecture...
| Zelphyr wrote:
| Thanks for the clarification.
| jdthedisciple wrote:
| I'm telling you, Flutter has amazing performance (+ incredible
| dev experience).
| theThree wrote:
| OK,just now I tested the new version and it is still slow.
|
| Use "npx create-expo-app@latest --template default@beta" to
| install new version. Start with production mode, using android
| device, it takes about 300ms to render 2000 Views. The same
| test on React web is still much faster.
| arijo wrote:
| Guys, help me understand these changes:
|
| Can I comprehend this as a new Virtual Native UI immutable tree
| running in native space?
|
| And react native mounts and updates basically synchronally
| updating this immutable tree and reconciliation being done in
| native space, dynamically updating the app layout?
| rickhanlonii wrote:
| Kind of. We already had a native UI tree running in native (the
| same way the browser has it's own internal representation of
| the DOM). The difference in this release is that we rewrote it
| in C++ and made it immutable. That means instead of having a
| different UI tree in each platform (one for iOS, one for
| Android, etc), we have one C++ tree that all platforms use. And
| since it's immutable, it's thread safe and we can read layout
| and commit it from different threads if needed.
|
| Reconciliation is still done in React on the JS thread, similar
| to React DOM.
| arijo wrote:
| Thanks for the clarification. Dumb question:
|
| How does the renderer ensure consistency in case o multiple
| immutable tree references?
| jdthedisciple wrote:
| Wondering the same (replying to easier find your comment
| and hopefully the answer since i cant favorite comments)
| adolfojp wrote:
| At the time of writing this comment, we've got:
|
| 1 person talking about how they wish react native didn't exist
|
| 1 person asking about Capacitor
|
| 1 person complaining about Expo
|
| 1 person saying that they wouldn't use react native and
| recommending Kotlin Multiplatform instead
|
| 1 person complaining about the quality of the discussion (Me)
|
| 0 people talking about the new architecture
|
| I still love Hacker News but the discussions are becoming
| increasingly pointless.
|
| All that's missing is:
|
| 1 person complaining about the style in which the article was
| written
| pavlov wrote:
| You forget:
|
| 1 person complaining about the amount of JavaScript loaded just
| to display this one article
| martinsnow wrote:
| Should we also complain at the amount of bootstrapping your
| OS had to do before your browser could show said site?
| robinsonb5 wrote:
| Yes, absolutely. Just because it's been hidden behind
| decades of advances in CPU and storage technology doesn't
| mean it's not incredibly wasteful.
| martinsnow wrote:
| Explain to me why rendering html in javascript in
| wasteful? GNOME and Edge does the exact same thing for
| ther shells.
| esaym wrote:
| The site doesn't even load at all now (lol)
| mdgrech23 wrote:
| Reddit does a lot better of job bringing good relevant comments
| to the top.
| poincaredisk wrote:
| I strongly disagree, Reddit brings the most engaging comment
| to the top, which is usually funny or ironic, but rarely
| informative.
|
| Congrats on being the person comparing HN to Reddit.
| martinsnow wrote:
| Reddit has a lower barrier to entry, which will invite lower
| quality comments. Sadly product officers are starting to flow
| into HN and other people with no programming experience, so
| the quality of comments are as such. If there was a fizzbuzz
| challenge to sign up, i'd bet the comments would not consist
| of such nonsense.
| RussianCow wrote:
| This is extremely elitist and reductionist. Plenty of the
| best comments/discussions on HN come from non-programmers.
| Personally, I like that people from various backgrounds
| come together like this as it tends to provoke more
| interesting discussion and makes HN less of an echo chamber
| than Reddit.
| mardifoufs wrote:
| It really depends. I guess on more specific subs, sure. Like
| if this was posted on the react or react native sub.
|
| If this was on programming or even web dev you'd just see
| "react bad" or "embedding a browser for an app is blablabla"
| (when react native doesn't even do that)
| andy_ppp wrote:
| And you are complaining about the complaining. Great work.
|
| EDIT: I've added to the problem which is ironic and just missed
| the delete button.
| adolfojp wrote:
| That's literally point #5 of my comment. Didn't you read it?
| martinsnow wrote:
| Congrats. You added nothing to the discussion.
| adolfojp wrote:
| You're not being clever. You're just being argumentative.
| martinsnow wrote:
| I was pointing out the needlessness of your original
| comment. Why post it in the first place....
| supriyo-biswas wrote:
| Such comments should really be directed at dang who keeps
| maintaining that there's no data point to think that the state
| of discussions are declining.
|
| One way to address this might be to compute some relevance
| metrics using embeddings (they're the new hotness after all)
| and downrank low relevance discussions. I assume it'd be
| especially effective for the "ads and JavaScript" discussions.
| burningChrome wrote:
| >> keeps maintaining that there's no data point to think that
| the state of discussions are declining.
|
| I would simply say a lot of contrarian viewpoints, regardless
| of merit, are downvoted into oblivion. Once you get hammered
| on something you simply had a different viewpoint on? Users
| tend to stop commenting for fear of reprisals. Your "karma"
| on here is not easy to obtain so when people downvote you
| simply for a differing opinion, it makes it less likely they
| will wade into a discussion again and find themselves on the
| wrong side of some Hacker News diva having a bad day.
|
| This means you have a lot of people (like myself) simply
| opting out of a lot of discussions because if you're not on
| the right side, your comment will get downvoted immediately.
| There is no data point on people like myself, so there's no
| way to tell people that the quality on HN is declining,
| everything is just fine and normal when in reality, you have
| a lot of users who aren't engaging for fear of getting
| downvoted into oblivion.
| mynameisvlad wrote:
| > Your "karma" on here is not easy to obtain so when people
| downvote you simply for a differing opinion, it makes it
| less likely they will wade into a discussion again and find
| themselves on the wrong side of some Hacker News diva
| having a bad day.
|
| Why do fake internet points matter so much? Yes, karma is
| difficult to attain, but it also does (almost) nothing
| other than indicate how active a person is here.
|
| > This means you have a lot of people (like myself) simply
| opting out of a lot of discussions because if you're not on
| the right side, your comment will get downvoted
| immediately.
|
| In short, so what? Does it really matter if one thing you
| said one time gets downvoted? We're all (supposed to be)
| adults here. All that happens is fewer people read your
| comment. Big whoop.
| stnmtn wrote:
| You can say it shouldn't matter, but it looks like on
| every social media platform and for most people, they do
| care about these things.
| xboxnolifes wrote:
| It's not about the points. It's about knowing that
| writing a comment on a topic is a pointless endeavor, so
| you withhold. HN, like all communities, has topics that
| you learn to generally avoid interacting with because the
| community opinion is so strongly engrained. Going against
| the community opinion is akin to pushing boulders by
| hand. Sure, you might make it move once in a while, but
| do you really want to put in the effort?
| moralestapia wrote:
| >but the discussions are becoming increasingly pointless
|
| And hostile.
|
| Point out that someone is wrong (even with hard evidence at
| hand) and people will still try to push their deluded
| conclusions nonetheless.
|
| Same thing for expressing an opinion outside what the hivemind
| deems acceptable.
|
| Btw, I think this phenomenon is a widespread cultural thing,
| not HN specific. Happens irl so much that it is now almost
| impossible to have an actual conversation with anybody.
|
| Meanwhile, solitude and suicides are skyrocketing and people do
| not see the correlation ...
| adolfojp wrote:
| I've seen what you're describing and it worries me deeply.
|
| I think it's a combination of:
|
| 1. Ragebait being so useful at generating engagement that
| it's become a standard form of human interaction
|
| 2. The Internet making people feel safe from physical
| repercussions which makes people feel comfortable with
| treating others badly
|
| 3. Internet communities quickly becoming echo chambers where
| you're forced to pick a side if you want a sense of belonging
|
| So we've been programmed and manipulated to be angry, to be
| tribal, and to act without fear of retaliation, and all for
| what? For ads and followers.
| moralestapia wrote:
| Oh man, this is a very interesting take.
|
| Indeed, it is definitely the case that this kind of
| behavior/content gets amplified. When you log in, in some
| sense, any reality could be crafted just for you, for good
| or for bad. The overwhelming majority of people are
| vulnerable to this. What they see == what they think it's
| real, me included, btw.
|
| I once read an article about how the vast majority of
| dating now begins through an online interaction (say ,
| Tinder), and how also the vast majority of these apps are
| controlled by 2-3 companies. Think about the massive power
| they have over everyone else's lives. You want to encourage
| interracial relationships? Suppress matches within the same
| race and encourage matches outside of it. (And the opposite
| could be done, I'm not making a political statement here).
| These people have the power to completely change the
| demographic landscape of a country in a couple decades(!).
| They should be heavily regulated, but far from it, no one
| is even aware of this.
|
| It will only get worse with "AI", unfortunately.
| fullstackchris wrote:
| It's funny too, because what New Architecture allows (direct
| access to native interfaces) could solve a lot of the problems
| with having to fight external dependency hell - you can now
| write your own, so there's no excuses.
|
| But, somehow devs _still_ expect a 100% perfect DX while
| maintaining the ability to publish to mind-boggling different
| targets such as iOS, Android, and Web
|
| -\\_(tsu)_/-
| mhammerc wrote:
| I have been working for the past four years exclusively on react-
| native apps and their backend API, from bootstrap to publishing,
| adding new features every few months and maintaining the apps.
|
| It was a mixed experience. When I migrated to expo two years ago,
| many problems were solved but not all.
|
| But I still encounters bugs and problems with many common
| dependencies. It is not uncommon to have bugs on certain Android
| brands, with the community on github reporting the bug but
| waiting months for it to be fixed.
|
| iOS is by far better and more stable than Android.
|
| Performance is great on iOS, but less great on Android.
|
| Our apps are animation heavy using react-native-reanimated and
| react-native-skia. Everything went perfect on iOS but we had to
| remove some animations or simplify them on Android.
|
| Upgrading your dependencies every four months will probably break
| something somewhere : deep links stop working, some animations
| stop working, or maybe it's another dependency from the JS world.
| Sometime the fix is easy, other time an issue with the regression
| can be found on Github, other time we have no data.
|
| Overall I'd say react-native is perfectly servicable and is easy
| to learn for anyone, which is a big plus. I'd recommend react-
| native because it is easy, have a big JS ecosystem, but I am now
| on the Flutter side.
| swatcoder wrote:
| Congratulations! You've described the universal experience of
| using cross-platform frameworks.
|
| They can be great as long as you _and your customers_ stay on
| their most well-trodden path. But as these frameworks grow and
| become more byzantine, and as your project requirements start
| reaching for more rarified features and your customers start
| using new and differing runtime platforms, maintenance overhead
| starts to dominate and you find yourself running into invisible
| walls that make it hard for you to deliver on your project
| roadmap or satisfy the support standards you want for your
| customers.
|
| This has _always_ been the case for these frameworks, going
| back many decades, but especially since the explosion of
| efforts to build them around web stacks, which are easier for
| developers to use but harder for framework designers to keep
| sufficiently robust and capable as they age.
| tcoff91 wrote:
| There's no free lunch when it comes to targeting multiple
| platforms. It sucks to have to maintain separate iOS,
| android, and web apps, and it also sucks to use a cross
| platform framework.
|
| But I still feel in the end that for many CRUD style apps
| it's worth it to deal with react native's problems,
| especially if you can also have significant code sharing with
| your web app.
|
| If you're trying to build the next snapchat or tiktok you'd
| better go full native though.
| david_allison wrote:
| > It is not uncommon to have bugs on certain Android brands,
| with the community on github reporting the bug but waiting
| months for it to be fixed.
|
| Welcome to Android. That's not just a React Native issue
|
| https://github.com/M66B/FairEmail/blob/master/app/src/main/j...
| heroprotagonist wrote:
| Soooo.. more react-native contributors have bought in to the
| Apple ecosystem, so frameworks and components are better
| designed and tested there?
|
| Which similar frameworks' developers have subscribed to the
| Android ecosystem and do much better work there?
| cageface wrote:
| Having used both RN and Flutter quite a bit I also much prefer
| Flutter, despite being a big fan of Typescript and React for
| the web.
|
| Flutter just feels like a much more polished and stable
| platform built explicitly for purpose and I've never had any
| performance issues.
| tcoff91 wrote:
| React native is finally pretty good this year. It still has
| problems but I feel like it's really starting to pick up
| momentum.
|
| When react-strict-dom is totally ready for prime time it's going
| to be a game changer and react native will become an absolute
| juggernaut.
| RussianCow wrote:
| How so? What makes this a game changer for the average dev?
| serial_dev wrote:
| I'm a Flutter dev since 2018 and I am honestly not sure if
| Flutter or React Native still make sense in 2024 and onwards.
|
| When they emerged, the mobile development scene was completely
| different than today.
|
| Today, we have Swift UI and Compose, both are pretty solid. I'm
| not sure if it's the consensus amongst mobile developers, but I
| believe that on the mid/long run you will be better off - even if
| you write things twice. In terms of end user experience,
| developer experience, and in the business sense, everywhere.
|
| Sure if you have an Flutter / RN app that has years of
| engineering efforts invested into it, go ahead and continue
| (duh), but I wouldn't start new apps with them.
| johnny22 wrote:
| > I believe that on the mid/long run you will be better off -
| even if you write things twice.
|
| People have believed this the whole time and also a ton of
| people didn't then and don't now. What has actually changed?
| serial_dev wrote:
| Swift and Kotlin are now the de-facto languages for these two
| platforms for new development, and Swift UI and Compose got
| released and gained traction since 2018.
| mixmastamyk wrote:
| Hmm, what about desktop and/or web?
| serial_dev wrote:
| I don't want to say you should never, under any
| circumstances, use cross platform tools. Sure, if you have
| Android, iOS, web, macOS, Linux and Windows apps that are all
| roughly the same, go ahead and use cross platform
| technologies.
|
| I don't think most apps are like that, though. If it is worth
| having a desktop app (instead of just, you know, having a web
| app), than that app is probably relying heavily on native
| integration. Also, mobile apps and desktop apps are usually
| quite different (as they should), those are two completely
| different interfaces.
|
| About web, I'm not sure about RN, but Flutter IMO is so
| terrible on web, that it's so rare that it would make sense
| to use it, that my default advice would be that write the web
| in something different, even if you use Flutter already on
| mobile and desktop.
| mixmastamyk wrote:
| Well, I need to make a media-player type of app, that will
| run on Linux/Wayland devices, which are like small
| desktops. Mainstream mobile devices would be a nice-to-have
| too, but there are so many bureaucratic issues, like
| getting into stores I might just avoid them for now. Web
| stuff can stay web.
|
| Was thinking of learning Flutter or even RN, but now not so
| sure. On the other hand, it could mean writing it three
| times.
| EddieRingle wrote:
| Compose UI has the potential answer there, as well:
| https://www.jetbrains.com/compose-multiplatform/
| mixmastamyk wrote:
| Great, another one. Recently someone else was touting
| something called avalonia for .net? Then there are older
| ones that still exist, like Kivy and QT.
|
| These folks should be working together on just a few open-
| source projects :-D. Trying to support every mainstream
| platform is a huge undertaking and as mentioned in this
| thread, few succeed, and even fewer over the long term.
| jdthedisciple wrote:
| I agree with you only in terms of Flutter and Web: Been a
| Flutter dev since years now as well and would definitely NOT
| encourage it for the Web.
|
| That said, it is absolutely up there with the best choices for
| mobile app dev these days.
|
| I don't see any reason not to use it there, and the industry
| seems to be thinking in the same direction atm
| e63f67dd-065b wrote:
| I'm not familiar with UI development at all, but I'm kind of
| amazed that the old solution of a giant async bridge where the
| renderer enqueued native function calls worked at all. What was
| the initial reasoning behind this architecture? (that is to say,
| why did it seem like a good idea at the time?)
| tmitchel2 wrote:
| Love react native, I'll be updating to this version soon. Really
| hoping it makes suspense work correctly with libs like Relay.
| Well done and thank you RN team.
| coldblues wrote:
| I will now inform everyone here that the Windows 11 Start Menu
| uses React Native. You're welcome :)
| theThree wrote:
| Only the "recommended" section.
| terandle wrote:
| Seems to be a lot of negativity around RN, and I can understand
| that if you haven't used it in a while. But these days I have
| nothing but great things to say about React Native when used with
| Expo. It's great to want custom bespoke individual native apps
| for each platform but as a solo dev that just isn't really
| practical and RN has enabled me to ship things I wouldn't have
| been able to otherwise. Also that hot reloading react DX is just
| great in general. And I really want the RN model of using the
| platforms native controls to win out vs rendering everything to a
| canvas like Flutter.
|
| Can't wait to try out the new arch when 0.76 lands in expo.
| ppsreejith wrote:
| This is pretty incredible, kudos to the team! I wonder if there's
| still an option to call native modules asynchronously (since I'd
| guess the synchronous native calls block JS execution?)
|
| Also, I remember transferring lots of data through the bridge
| could be a bottleneck for some use cases. Is that effectively
| solved with this architecture?
| pixelready wrote:
| It's looking really good so far. Some known issues in the expo
| and RN ecosystem are called out under the troubleshooting section
| here:
|
| https://docs.expo.dev/guides/new-architecture/
___________________________________________________________________
(page generated 2024-10-24 23:01 UTC)