[haney]

All engineering requires trade offs, in this case you’re trading productivity in one area vs flexibility.

[filleduchaos]

All engineering may require tradeoffs, but when you're so prioritizing developer experience over the actual business that you're dropping perfectly viable features just so you can cling to the illusion of increased productivity, perhaps it's time to take a step back and reevaluate things.

What use is "productivity" without a performing product?

[spamizbad]

Depends on what feature we're talking about.

Is it a high-value feature to the end users? Then absolutely, you're correct.

Anyway, in my experience, most good PM and designers want an understanding as towards the amount of effort their features and designs mean for engineers. So if you aren't providing them that feedback, and letting them to factor that into their process, you're doing them a disservice.

[Jare]

MVPs are mostly about that. Unless a fancy feature not supported by RN is a necessary part of your core product, productivity takes priority.

[filleduchaos]

And is the app going to remain an MVP forever?

[Jare]

No, but the ability to produce an MVP within the limitations (time, budget, opportunity, etc) may be what allows having an app at all.

[on_and_off]

so productivity as long as you don't implement some features ?

I mean, I can double my native productivity that way too !

[haney]

Sure, I’m not advocating for developer experience above all else, just pointing out that the fast/cheap/good “pick any two” balancing problem can be solved in multiple ways. I totally agree that we build products for our users not ourselves.

[on_and_off]

oh yeah, I can get behind that.

If you need an app on both Android and iOS quickly, have low quality concerns and only one web dev .. RN is a no brainer.

It kinda occupies a completely different valley of the fast/cheap/good graph