6 ms·

While all of the points you brought up are valid, I've hated every react native app I've ever had to work on. Not because of react native itself, but because th

While all of the points you brought up are valid, I've hated every react native app I've ever had to work on. Not because of react native itself, but because they usually take random react developers to work on these apps and the structure they create is absolutely horrible to work with (compared to, for example, native apps). What was your experience on that aspect with Flutter?

meerita 1mo ago
I agree. RN has historically attracted a lot of web developers who treat mobile like a React website, and the result can be terrible. But I've seen exactly the same architectural problem in Flutter: huge widgets, mixed responsibilities, state everywhere, and very little separation of concerns. The framework doesn't protect you from bad engineering.
- Degorath 1mo ago
  Ah, that's a shame to hear. I would only like to add that at least for Android apps that I've been "hanging around" (my team never really worked on them), the teaching materials that are provided have generally made them a lot more pleasant compared to the RN stuff.
- gman83 1mo ago
  No framework prevents bad engineering. If a tool is rigid enough to make messy code impossible, it becomes too limited to build anything non-trivial. Aren't you conflating framework design with dev discipline? You can write a monolithic disaster in React, native iOS, or Flutter with equal ease. Bad architecture usually happens when devs copy-paste habits from web or imperative paradigms without adapting to a declarative model. Flutter actually gives you great primitives for clean code. UI components are lightweight config objects, so breaking a huge screen into tiny, modular pieces has virtually zero performance penalty. Its state model naturally separates logic from rendering, making it easy to isolate business logic into testable layers. Plus, the built-in analyzer catches anti-patterns like memory leaks at compile time. all the tools to enforce separation of concerns are there, imo
  - meerita 1mo ago
    The case of RN is different: it's made from a web point of view and applied to mobile. Therefore, it's not per se about the framework, but rather a coincidence that mobile and web are two completely different worlds. Hence, it's quite normal to see abominations when you allow people who are used to the web to do mobile development.
puelocesar 1mo ago
I was forced to migrate from pure native development to React Native and Redux is one of the stupidest things I ever witnessed. Or at least the way the previous devs setup that thing, because it’s so easy to make costly mistakes with it. I lost so many days of my life profiling and debugging to figure out why hundreds of components were re-rendering when a tiny thing changed somewhere completely unrelated
- tcfhgj 1mo ago
  > figure out why hundreds of components were re-rendering when a tiny thing changed somewhere completely unrelated Could you explain how this comes from React Native and/or redux? I have used Angular with redux (ngrx) and redux made it quite obvious what changed what and why
- user43928 1mo ago
  Redux is great and it solves exactly that problem. You create a selector. You use the selector in a React component. The component re-renders when the selector outputs a different value, with the usual reference equality caveat. Does it get any simpler than that? However, yes, I have seen most developers use Redux incompetently. They would use actions like "setOrder" instead of "itemAdded", defeating the purpose of a state machine from the start.
  - satvikpendem 1mo ago
    They might have been using Redux before it did a major API change in the form of slices.
    - user43928 1mo ago
      That would be about 7 years ago, when Redux Toolkit released in 2019.
      - satvikpendem 1mo ago
        That's probably right. Lots of people migrated from Redux onto other state management libraries.

meerita 1mo ago

I agree. RN has historically attracted a lot of web developers who treat mobile like a React website, and the result can be terrible. But I've seen exactly the same architectural problem in Flutter: huge widgets, mixed responsibilities, state everywhere, and very little separation of concerns. The framework doesn't protect you from bad engineering.

Degorath 1mo ago
Ah, that's a shame to hear. I would only like to add that at least for Android apps that I've been "hanging around" (my team never really worked on them), the teaching materials that are provided have generally made them a lot more pleasant compared to the RN stuff.
gman83 1mo ago
No framework prevents bad engineering. If a tool is rigid enough to make messy code impossible, it becomes too limited to build anything non-trivial. Aren't you conflating framework design with dev discipline? You can write a monolithic disaster in React, native iOS, or Flutter with equal ease. Bad architecture usually happens when devs copy-paste habits from web or imperative paradigms without adapting to a declarative model. Flutter actually gives you great primitives for clean code. UI components are lightweight config objects, so breaking a huge screen into tiny, modular pieces has virtually zero performance penalty. Its state model naturally separates logic from rendering, making it easy to isolate business logic into testable layers. Plus, the built-in analyzer catches anti-patterns like memory leaks at compile time. all the tools to enforce separation of concerns are there, imo
- meerita 1mo ago
  The case of RN is different: it's made from a web point of view and applied to mobile. Therefore, it's not per se about the framework, but rather a coincidence that mobile and web are two completely different worlds. Hence, it's quite normal to see abominations when you allow people who are used to the web to do mobile development.

puelocesar 1mo ago

I was forced to migrate from pure native development to React Native and Redux is one of the stupidest things I ever witnessed. Or at least the way the previous devs setup that thing, because it’s so easy to make costly mistakes with it. I lost so many days of my life profiling and debugging to figure out why hundreds of components were re-rendering when a tiny thing changed somewhere completely unrelated

tcfhgj 1mo ago
> figure out why hundreds of components were re-rendering when a tiny thing changed somewhere completely unrelated Could you explain how this comes from React Native and/or redux? I have used Angular with redux (ngrx) and redux made it quite obvious what changed what and why
user43928 1mo ago
Redux is great and it solves exactly that problem. You create a selector. You use the selector in a React component. The component re-renders when the selector outputs a different value, with the usual reference equality caveat. Does it get any simpler than that? However, yes, I have seen most developers use Redux incompetently. They would use actions like "setOrder" instead of "itemAdded", defeating the purpose of a state machine from the start.
- satvikpendem 1mo ago
  They might have been using Redux before it did a major API change in the form of slices.
  - user43928 1mo ago
    That would be about 7 years ago, when Redux Toolkit released in 2019.
    - satvikpendem 1mo ago
      That's probably right. Lots of people migrated from Redux onto other state management libraries.