Comment by uzername
5 years ago
Is this a bet against React or a bet for ecosystem variety and choice? I feel it's the latter right now.
5 years ago
Is this a bet against React or a bet for ecosystem variety and choice? I feel it's the latter right now.
Seems more like variety. React is in a league of it's own with React Native. For web tech Svelte is cool, for app tech it's not on the radar.
I used to be a web developer, now I'm a React Native / RNW developer.
I don't use web tech unless I'm making a simple web page, when I do I use vanilla HTML/CSS/optional JS.
You get a web app for free when you make a RN app. You can share 95% of code among 5 platforms. (web, windows, macos, ios, android)
Conditionals can change any styling you need amongst them. You can swap out scripts depending on platforms, you can access any extra native platform function with extensions.
Svelte doesn't work for me because you need JS. I don't want to need JS for simple web pages, for apps I need cross-platform.
Svelte could work well for edge computing like CF workers.
How is RN? I have seen several teams try to consolidate their App Devs into RN devs, only to split back into iOS/Android devs. From what I’m told, if your app could be a webpage, RN is great. But if you need to really leverage the specific platforms, it’s hard to do that.
> But if you need to really leverage the specific platforms, it’s hard to do that.
Not my experience. I have a production app for web, ios, and android, with desktop platforms coming.
You can swap out anything per platform and write any extension for any native functionality you don't have, but the std and community extensions are plentiful.
RN sucks for "web pages", great for apps. In fact sometimes I embed web pages inside my RN apps. (surveys, etc.)
I haven't heard a single good argument of why it doesn't work. If you were going to write a native app you can write a native extension and share the common parts in JS.
RN is not Cordova, it's not a black box, it's very flexible and extensible.
-- @Jcampuzano2 because of post limit --
Earlier yes there's some fickleness with the toolchain, I don't really have issues now, it's fine unless you're on bleeding edge versions or old versions. Performance issues usually relate to the JS bridge, JSI will alleviate that, most devs won't experience an issue. I don't know why others struggle with RN, it works well for me. Flutter is a no go because it emulates native, it's not true native. You can feel the difference on iOS and the web part sucks so hard.
8 replies →
It's probably because they had a team of experienced iOS/Android engineers, who are significantly more productive in their respective platforms.
To me, it's uplifting the entire web ecosystem. There will always be developers who pick Svelte and friends over React, even if that reason is just syntax preference. Those developers should still have the best infrastructure for their apps. Better to be pragmatic than over-prescriptive.
If you are building a platform for web dev, it’s better to be able to control your technology. Any change FB makes to React may leave you scrambling to patch your tech. Or What if one day FB decides to stop supporting React, or they make a design decision incompatible with your business? While it sounds unlikely, it’s bitter pill to swallow from a business angle.
react is used so many places professionally that i think someone would just fork or remake react from scratch if they ever did that.
And then you would probably be forced to support classic FB React for customers that didn't want to migrate, and forked React.
The real issue is if you build any special sauce on top of React. Say you went all in on providing a customized React.Component that worked like a React.Component, but had your platform's logging, perf metrics, etc built in. Then React comes out with hooks and functional components and then you are stuck trying to reimplement your special sauce using these. Or you have to tell customers, "we only support class based components." While functional components are old, FB has shown it will introduce paradigm changes into React, and you are left holding the bag when it comes to supporting them in your platform. And if customers saw a new React feature previewed yesterday, be sure they will be asking for support for it today. FB isn't likely to hand over React to Apache or any sort of open governance model, so changes can be easily made without a huge amount of forewarning, or even a business relationship. Last time I checked FB wasn't selling support contracts or partnerships for React.