|
|
|
|
|
by qwytw
1253 days ago
|
|
Electron itself is not really that bad though. Sure there is not insignificant overhead but you can still make fairly resource efficient apps with it if you actually want to (and you can use Tauri if you want to go even further). Also Slack, Discord etc. are not really using React Native (but rather normal web react if they are not using another framework). You don't really need Chromium for React Native which significantly reduces memory footpring (in fact a react native app can be close to indistinguishable from a "normal" native app in most ways). You can probably reduce React Native overhead to not much more than 100-200MB compared to purely native apps which seems reasonable. |
|
When I first started using react I loved it compared to what existed at the time, the ease of composing everything and the fact that it just used JS instead of a DSL for templating and it didn't mandate all these cargo-culted framework patterns.
But the warts are really starting to show up, writing React today with useEffect hooks everywhere reminds me of writing VHDL in college to simulate an automated train controller and now I'm reaching for things like XState to handle almost all state management (I have a feeling this complexity ends up appearing for all complex UI interactions though).
Also we are taking on a type system (which is good) but not seeing any of the performance benefits that could bring. Why is golang more than 100% faster than typescript? Both are statically typed languages but TS doesn't get any compiler optimizations because of the JS baggage.
That being said, I'll take JS with React + React Native if it means I can write apps once and ship to all three major platforms. It's exciting that ui frameworks like Tamagui allow for close to 90% code sharing.