71–80 of 127 posts
Earlier quoted context omitted.
You forget: 1 person complaining about the amount of JavaScript loaded just to display this one article
Should we also complain at the amount of bootstrapping your OS had to do before your browser could show said site?
Can't wait to try out the new arch when 0.76 lands in expo.
Earlier quoted context omitted.
Should we also complain at the amount of bootstrapping your OS had to do before your browser could show said site?
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.
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?
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…
How does the renderer ensure consistency in case o multiple immutable tree references?
Earlier quoted context omitted.
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.
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...
Earlier quoted context omitted.
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.
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.
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 twi…
> 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?
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 discussi…
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 ...
I helped write this post, so feel free to ask me anything about the New Architecture!
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!
Earlier quoted context omitted.
> - 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?
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 lib…
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.