4 ms·

I have very positive experience with React native, and also with React Native Web. Being able to share source of full pages/activities/forms across both Mobil

I have very positive experience with React native, and also with React Native Web. Being able to share source of full pages/activities/forms across both Mobile platform + Web browsers, while having Native look and feel -- is incredible. Very rewarding not just being able to use the same 'code base', but also leverage same paradigms to manage UI Layouts between native and web (with flux). As a side note, I absolutely despair when I have to fall back to CSS or even bootstrap. Once I, finally, 'groked' flux -- it was huge productivity booster and I can rely on that learn-once-use-in-many-places knowledge across not just my app, but also when building small web-sites (in web tech only). My approach for the app, is of a 'hybrid'. That is, my app starts out as Native, and then, for some 'activities' (in Android-speak) -- I use react-native. I have implemented native modules to get access to platform specific elements from React native code (eg networking apis, security, hardware device access, device-preference/database stores) -- while basic forms/widgets and navigation logic for some pieces are in React, leveraging React-native and react-native-web underneath. I think the UI paradigm introduced by React is a sweet spot for UI development (concentrating on state as first-class-citizen). I am hoping same paradigm (and similar abstractions) are adapted by MS toolchain for desktop and console UI in .NET-based solutions. Another side note (not RN specific) : C# is really a much better language than JavaScript, but until browsers can supports C#-subset, JavaScript is the only game in town for the 'modern' cross-platform dev efforts (eg. cross mobile, desktop and web-browsers) ). In terms of some challenges I have experienced with RN: a) build system. Creating a release build is a major undertaking. As the solution has to merge the 2 worlds: native and JavaScript-specific asset management pipelines. Error messages are obscure (eg I ran into issues, for example, where a path for an Icon file was too deep, moving it to shorter path, solved that one). Guides are for primitive (and non-hybrid) approaches. b) Lack of standard (RN and RNWeb ) support navigation component. c) Small things like: no Checkbox component for IoS.. d) Cross-platform app-store compatible icon management is not built in. I use react-native-vector-icons -- so that solves that problem for me. But app-store compliancy like this should, ideally be part of such platform. e) As the article points out, the integration bridge between RN and native is not efficient for 'constant interaction'. Because it requires you to serialize data structures back and forth. So impossible to write 'hybrid' apps where small parts are in RN -- instead it has to be 'bigger things' that would not require too much back-and-forth. f) the Debugging with Chrome over TCP bridge -- is basically a horrible/slow/barely working. Navigations from one screen to another take like 2 seconds, while the debug mode. Because my components work on web browsers, thanks to React-native-web - I end up, most of the time, debugging my RN logic using React-native-web within browser debugging tools (rather than starting up the native app and then spawning the debugger with Chrome bridge).

andrewmcwatters 8y ago
> I am hoping same paradigm (and similar abstractions) are adapted by MS toolchain for desktop and console UI in .NET-based solutions. You're at least a couple of decades late, there, and the other way around: instead of `Winuser.h`, it's `react.js`.
- 75dvtwin 8y ago
  I do not think we had something similar prior to React Native. I programmed MFC, Delphi, YACL (if folks remember..), wxWidgets, Borland OWL, Dojo toolkits. There was never a concept of State-as-first-class citizen for UIs. And there as never a cohesive multi-screen layout engine story, like we have now with flexbox (via RN and RNW). So in my view, the data binding via explicit state-management paradigm that React introduced -- will survive for decades, and will be copied to other programming environments. Same, probably for flexbox as a layout management model... Although, there, I wish that it would be more 'typefull' where various incompatible layouts could be flagged as errors or warnings at compile time. Perhaps (and may be this is is far fetched) with the advancements in practical category theory, compute power (including at compile time) -- we should be able to do 'shape' management as algebraic concepts -- where layout engines, should be able to treat layout definitions as composeable, multi-variable functions. WRT javascript vs C#, I was just noting, that, in my view C# is just a much better language, and I wish it would have been a de-facto web-standard and not javascript. This way something like React, would not have been conceived in javascript.

andrewmcwatters 8y ago

> I am hoping same paradigm (and similar abstractions) are adapted by MS toolchain for desktop and console UI in .NET-based solutions. You're at least a couple of decades late, there, and the other way around: instead of `Winuser.h`, it's `react.js`.

75dvtwin 8y ago
I do not think we had something similar prior to React Native. I programmed MFC, Delphi, YACL (if folks remember..), wxWidgets, Borland OWL, Dojo toolkits. There was never a concept of State-as-first-class citizen for UIs. And there as never a cohesive multi-screen layout engine story, like we have now with flexbox (via RN and RNW). So in my view, the data binding via explicit state-management paradigm that React introduced -- will survive for decades, and will be copied to other programming environments. Same, probably for flexbox as a layout management model... Although, there, I wish that it would be more 'typefull' where various incompatible layouts could be flagged as errors or warnings at compile time. Perhaps (and may be this is is far fetched) with the advancements in practical category theory, compute power (including at compile time) -- we should be able to do 'shape' management as algebraic concepts -- where layout engines, should be able to treat layout definitions as composeable, multi-variable functions. WRT javascript vs C#, I was just noting, that, in my view C# is just a much better language, and I wish it would have been a de-facto web-standard and not javascript. This way something like React, would not have been conceived in javascript.