Is this a bet against React or a bet for ecosystem variety and choice? I feel it's the latter right now.
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.
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.
I personally also worked with React Native for a while, and sure, you can write native extensions for everything, but the biggest complaint is how fickle it is when it comes to upgrading, package management, mind boggling errors related to the metro bundler, etc.
I.E. It's great when it works and you have something simple, but things broke so often compared to native development when you had to do anything complex. And the performance characteristics weren't very great on top of this.
I haven't done React Native in a bit more than a year but from people I talk to not much has changed, and most people I talk to who were all in on React Native mention to use Flutter instead nowadays if you really want cross platform UI.
React uses webpack usually, RN uses metro usually, you can use esbuild, swc, etc for either though.
Svelte is a web tech, and thus uses web bundlers like webpack, thus has the same "faults", though I'm not sure what specifically is being critiqued.
When comparing RN to other cross platform solutions like Flutter you're wanting to compare it's package manager / bundler to Metro and the native dependency systems such as Cocoapods.
Just wanted to clear that up.
But every update was a large effort in bringing the app back into compliance with the new changes. The debugging platform used a different interpreter than in app resulting in things that worked in the debugger but not in production. Odd bugs at boundary layers nobody could (easily) decipher. The inability to even catch or do anything with some crashes.
It was the worst experience I ever had with a development tool chain in my entire career.
What discrepancies did you notice? It depends on the target platform which JS engine is used. Sometimes the debugging platform shares the same engine.
> Odd bugs at boundary layers nobody could (easily) decipher.
I'm not sure I understand, could you provide an example?
> The inability to even catch or do anything with some crashes.
Strange, you're able to catch and debug both JS and native crashes currently. I'm not aware of a past limitation but I could be wrong.
> What discrepancies did you notice? It depends on the target platform which JS engine is used. Sometimes the debugging platform shares the same engine.
Exactly what I said, there would be some code that would run differently in the two environments. I know more now than I did then, but I believe the example was specifically on iOS the app was using JavaScriptCore and the desktop dev tools was using v8.
> I'm not sure I understand, could you provide an example?
> Strange, you're able to catch and debug both JS and native crashes currently. I'm not aware of a past limitation but I could be wrong.
Best as I recall, there was a semi-frequent bug that happened down in our logging system. When it blew up we got a native stack trace instead of JS. My best guess is some kind of handshaking problem between the two layers. Neither used code we wrote and maintained.
Because the whole thing happened inside our error reporting engine, it wouldn't end up in our logs other than a high level apparent failure. It was a mess, and we had limited native experience on the team when it happened. We hired a dev with more native experience, but we still didn't ever figure it out while I was there.
The tool chain always felt like it was a hacked together early beta. To complicate our experience our internal APIs were a mess and unreliable and our React Native codebase wasn't dramatically better. Between our internal problems and all the idiosyncrasies and unintuitive issues in the tool chain it was really miserable.
It wasn't unusual for everyone on the team to spend more than a day simply trying to get the app running again after an update, that is after a dev had completed a 1 to 2 week migration required after the update.
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.