ReactXP – A library for building cross-platform apps(microsoft.github.io)
microsoft.github.io
ReactXP – A library for building cross-platform apps
https://microsoft.github.io/reactxp/
123 comments
Totally agree with them on that. I love observable-style code vs the full Flux. Especially when I want a small, self-contained component. Redux in particular sort of asks you to not make your components self-contained, since you've got a single global state store. There are apps where it makes sense, but anything not full-blown-SPA-to-the-max can be really cumbersome with the flux pattern.
I find error-handling to be particularly awkward in the Flux flow. You've got the option of adding in callbacks (goodbye unidirectional data flow) or storing errors in global state which makes tracking down errors properly a right pain. Do you have to generate a nonce for every action that could fail and look for that in errors later? That isn't particularly reactive. Are you making data types polymorphic so they're either the thing I actually want or some error class? That doesn't mesh well with collection objects and is kind of gross in general.
I've had trouble finding/figuring out a clean solution for error handling. The flux patterns I've seen feel lacking with regards to error ergonomics.
I find error-handling to be particularly awkward in the Flux flow. You've got the option of adding in callbacks (goodbye unidirectional data flow) or storing errors in global state which makes tracking down errors properly a right pain. Do you have to generate a nonce for every action that could fail and look for that in errors later? That isn't particularly reactive. Are you making data types polymorphic so they're either the thing I actually want or some error class? That doesn't mesh well with collection objects and is kind of gross in general.
I've had trouble finding/figuring out a clean solution for error handling. The flux patterns I've seen feel lacking with regards to error ergonomics.
I was curious too, so:
https://github.com/Microsoft/ReSub
Looks similar to rxjs or mobx based state stores.
Looks similar to rxjs or mobx based state stores.
I've very successfully used the observable pattern since backbone/knockout days with Spine, on web, node, and Titanium. It is easy to create reusable components and follow the data flow, regardless of data source or view implementation.
These days I use virtual DOM for performance but the architecture hasn't changed in years. The observable pattern with viewmodels is very efficient.
These days I use virtual DOM for performance but the architecture hasn't changed in years. The observable pattern with viewmodels is very efficient.
More like vanilla flux and sugar around `store.subscribe`.
> to automatically create subscriptions between components and stores
Looks like someone rediscovered/reinvented dataflow constraints, in a slightly hacky way.
See also: The Siren Call of KVO and (Cocoa) Bindings (http://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and...)
Looks like someone rediscovered/reinvented dataflow constraints, in a slightly hacky way.
See also: The Siren Call of KVO and (Cocoa) Bindings (http://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and...)
That's also how I perceive flux/redux. It's promise is to make it easier to"reason about your application". But it's basically a glorified event model, which does have some nice properties, but you end up with one function bring scattered throughout your entire application as side effects (which you need anyway, be it as sagas, thunks or whatever). Now as your application grows out becomes really hard to follow the flow and if you dispatch an action, it's not clear what will happen because of this. Am I just not getting it right?
Isn't this basically like mobx with it's observables?
https://mobx.js.org/getting-started.html
https://mobx.js.org/getting-started.html
[deleted]
Despite explaining that XP stands for "cross platform", I still think that this is mis-named and many will assume it relates to one of Microsoft's biggest ever brand names with global recognition.
At first glance I decided not to read the article because I thought it irrelevant due to the XP.
At first glance I decided not to read the article because I thought it irrelevant due to the XP.
>I still think that this is mis-named and many will assume it relates to one of Microsoft's biggest ever brand names with global recognition.
Don't worry, most of the target audience of devs wasn't even 10 when Windows XP was a thing that mattered...
Don't worry, most of the target audience of devs wasn't even 10 when Windows XP was a thing that mattered...
End of Support for Windows XP was 2014, and still had a large home/enterprise install base at that time.
"React" part is also used by windows clone. React should be completely renamed today for reader's convenience.
Just like Visual Studio Code :)
I would really love if MS brought out some kind of .net core electron alternative. Xaml is nice enough to build UI with, .net core works across macOS and Linux, and the whole package wouldn't need an entire copy of chromium for each install
React-native is different from electron apps, though. I don't think they need chromium, just the Javascript portion of it.
XAML is an abandoned platform. I've been with WPF for maybe 8 years. Haven't enjoyed coding like i do now. If you have ever worked with React, it will change you. It is something else to be able to make a UI with ease, to be absolutely confident about state, and to tap into the biggest community on earth (npm) to import whatever you want. Also tooling, the ability to edit modules live while the rest of the application just stays put.
XAML is an abandoned platform. I've been with WPF for maybe 8 years. Haven't enjoyed coding like i do now. If you have ever worked with React, it will change you. It is something else to be able to make a UI with ease, to be absolutely confident about state, and to tap into the biggest community on earth (npm) to import whatever you want. Also tooling, the ability to edit modules live while the rest of the application just stays put.
I've heard react native is not very performant because it essentially operates through a webview?
No... :D Why would anyone use it then, you could just as well wrap a regular webview. RN's gui elements are native, it taps into native animations, schedulers, openGL and so on. But driven by Javascript running in a separate thread. RN produces real mobile apps, RN-windows real UWP applications, RN-macos real mac apps, and so on.
You heard the opposite of reality. Here are the key facts:
- React Native is faster than apps using a webview because it uses native UI components for their OS targets (e.g. Android and iOS). They also look more native.
- React Native runs the JS code in a separate thread from the native UI components rendering. Webview apps will use the same thread for their app code and the DOM rendering.
- React Native is faster than apps using a webview because it uses native UI components for their OS targets (e.g. Android and iOS). They also look more native.
- React Native runs the JS code in a separate thread from the native UI components rendering. Webview apps will use the same thread for their app code and the DOM rendering.
Ok, that makes more sense
would be interesting to port wpf widgets to .net core and expose those through some sort of electron alternative.
Yes, a cross platform WPF. UPF I guess
Like Xamarin for .NET Core?
Does Xamarian provide desktop widgets?
There is Xamarin.Forms, which is essentially cross platform XAML with a base set of widgets. It supports Android, iOS, UWP, and they are working on MacOS. No Linux yet.
I wouldn't recommend Forms, I worked with it for about 4-5 months full time last summer and it was unstable and unperformant.
Last summer was a long time ago in Xamarin world. Works pretty well now.
Maybe it was Visual Studio Community that was making it worse, that thing was unstable as hell as well. So much time spent fixing project files...
Forms is the only real selling point for Xamarin. Too bad it doesn't have a good reputation.
The OS API integration, C# and F# are also selling points.
Qt doesn't support even half of the OS APIs that Xamarin does.
As for JavaScript based solutions, I don't intend to ever use it outside the browser.
Qt doesn't support even half of the OS APIs that Xamarin does.
As for JavaScript based solutions, I don't intend to ever use it outside the browser.
I have same feelings for js in general, but I suggest you to try React Native. Just follow their official docs/tutorial. I was pleasantly surprised how straightforward it is. I believe you can as well use TypeScript.
I don't see a value for TypeScript outside the browser when I can use C# and F# instead of it.
As for ReactNative, give it two or three years and maybe then I will bother learning it.
As an old dog I have already seen too many carriages pass by, very few of them come back.
As for ReactNative, give it two or three years and maybe then I will bother learning it.
As an old dog I have already seen too many carriages pass by, very few of them come back.
You should bother with React Native. It game changer in the mobile world, not a trendy thing that will pass away. Senior iOS devs are going the RN route. Companies all over the places use it for their mobile clients. A little company named WIX recreated its entire mobile front with React Native.
https://www.youtube.com/watch?v=abSNo2P9mMM
https://www.youtube.com/watch?v=abSNo2P9mMM
I beg to differ. The xamarin stack on Android without forms is much preferable to whatever confused iteration of java+toolchain Google is currently offering.
I'd like to see some benchmark comparisons with electron
Is xamarin free?
I'm a bit skeptical this is needed at all. I would've much preferred if Microsoft contributed to the already popular React Native for Web [1].
React Native already supports iOS, Android, and UWP. To add browser support all you need is something like React Native for Web. I made a small presentation a few months ago that shows this. Here's the source code: [2]. Take a look at the web folder.
Libraries like React Navigation [3] have also been built to support any platform that runs React code. It looks like Microsoft built yet another navigation library [4].
Also, check out React Primitives [5]. It aims to define a set of primitives that work on any platform that can be used to build more complex components. This is highly experimental, but I'm liking the direction where it's going, a unified React interface for any platform.
In addition, ReactVR is a great example of how React Native primitives can be extended to new emerging platforms [6].
Finally, React Native for macOS [7] answers the question that many have here about building native apps for macOS without relying on Electron.
[1] https://github.com/necolas/react-native-web
[2] https://github.com/migueloller/HelloWorldApp
[3] https://github.com/react-community/react-navigation
[4] https://microsoft.github.io/reactxp/docs/components/navigato...
[5] https://github.com/lelandrichardson/react-primitives
[6] https://github.com/facebook/react-vr
[7] https://github.com/ptmt/react-native-macos
React Native already supports iOS, Android, and UWP. To add browser support all you need is something like React Native for Web. I made a small presentation a few months ago that shows this. Here's the source code: [2]. Take a look at the web folder.
Libraries like React Navigation [3] have also been built to support any platform that runs React code. It looks like Microsoft built yet another navigation library [4].
Also, check out React Primitives [5]. It aims to define a set of primitives that work on any platform that can be used to build more complex components. This is highly experimental, but I'm liking the direction where it's going, a unified React interface for any platform.
In addition, ReactVR is a great example of how React Native primitives can be extended to new emerging platforms [6].
Finally, React Native for macOS [7] answers the question that many have here about building native apps for macOS without relying on Electron.
[1] https://github.com/necolas/react-native-web
[2] https://github.com/migueloller/HelloWorldApp
[3] https://github.com/react-community/react-navigation
[4] https://microsoft.github.io/reactxp/docs/components/navigato...
[5] https://github.com/lelandrichardson/react-primitives
[6] https://github.com/facebook/react-vr
[7] https://github.com/ptmt/react-native-macos
I've been developing a cross-platform app with React Native, and react-native-web has been working really well. It took almost no effort to get my React Native app working in a browser. I might be wrong, but it looks like ReactXP is just an alternative to react-native-web, with some additional abstractions and conventions for stores, etc.
I'm not sure I want to switch to ReactXP. I really like being able to use the React Native Animated API on the web, and I can also use wrapper libraries such as react-native-animatable.
I'm not sure I want to switch to ReactXP. I really like being able to use the React Native Animated API on the web, and I can also use wrapper libraries such as react-native-animatable.
A simple app protoype for Windows though, would be interesting.
I should have mentioned, there is also `react-native-windows` [1]. I haven't tried it yet, but I think it should also be pretty easy to get running.
[1] https://github.com/Microsoft/react-native-windows
[1] https://github.com/Microsoft/react-native-windows
We need a comparison / review.
Am I the only one who thinks this is a big deal? This basically means you can finally share your React code across platforms. It has always felt off that React and React Native are so similar, yet you can't use the same code for web and apps.
Like Java? Or QT? React Native being different for different platforms was kind of the point. "Learn once, write anywhere." This meant they could focus on wrapping the features of each unique platform without having to worry about how that affects supporting all of them simultaneously. Otherwise you get the lowest-common-denominator effect of supporting only the available APIs common between all platforms. And all of the painful effort of making sure everything works consistently and predictably across all platforms.
It fits some kind of apps. I've built one React Native app where the "lowest-common-denominator" was more than good enough (no special code for different platforms) and would have worked just as well as a web app but wasn't possible due to the nature of React/React Native. If I would have used ReactXP I could have published it on the web as well and used just one React code base so this is good news for me.
I don't understand what you're trying to argue about. If you don't like it, don't use it.
I don't understand what you're trying to argue about. If you don't like it, don't use it.
> I don't understand what you're trying to argue about. If you don't like it, don't use it.
I'm not arguing for or against ReactXP. Although if others start pushing the default to using ReactXP over React/React Native, that will be a disappointing repeat of history. My comment was addressing your statement:
> It has always felt off that React and React Native are so similar, yet you can't use the same code for web and apps.
I'm not arguing for or against ReactXP. Although if others start pushing the default to using ReactXP over React/React Native, that will be a disappointing repeat of history. My comment was addressing your statement:
> It has always felt off that React and React Native are so similar, yet you can't use the same code for web and apps.
This has been possible for a while now. See my comment here: [1]
[1] https://news.ycombinator.com/item?id=14068400
[1] https://news.ycombinator.com/item?id=14068400
That's really cool. I had no idea. Thanks!
>With React and React Native, your web app can share most its logic with your iOS and Android apps, but the view layer needs to be implemented separately for each platform.
As far as I understand, you don't need to do this in react-native. Only when you want to use some special features. Or am I missing something?
As far as I understand, you don't need to do this in react-native. Only when you want to use some special features. Or am I missing something?
It depends. In our current app, all we needed to implement separately was the margin for the status bar, literally two lines of code.
But as we move further, we'll be looking into making the versions for both platform feel truly native, and that will require some changes to navigation components and the overall navigation paradigm (tabs vs. drawer, screens vs. cards etc.).
The platform differences are as much about design as about code, and I don't see how you can escape that work with any cross-platform framework. But React Native makes it very easy to implement in a way that lets us share all but a few components.
But as we move further, we'll be looking into making the versions for both platform feel truly native, and that will require some changes to navigation components and the overall navigation paradigm (tabs vs. drawer, screens vs. cards etc.).
The platform differences are as much about design as about code, and I don't see how you can escape that work with any cross-platform framework. But React Native makes it very easy to implement in a way that lets us share all but a few components.
With RN, if you want your app to look like a real native app, you have to implement things separately for iOS and Android. Eg the default navigation component animates differently than native iOS, and there is an extra component that uses the native UINavigationBar, but with that you need to manage the iOS navigation stack separately.
The description is obtuse, but I think they mean separately between web and mobile, not iOS and Android.
It'd mean this framework is supposed to be a higher level React Native implementation: that you can use everywhere you want to use React, not just mobile.
It'd mean this framework is supposed to be a higher level React Native implementation: that you can use everywhere you want to use React, not just mobile.
> Or am I missing something?
Yes, it's not possible. You can't just use your React code as React Native. There are many small API differences.
Yes, it's not possible. You can't just use your React code as React Native. There are many small API differences.
Parent is not saying (or asking whether) you can "use your React code as React Native".
They are saying that from what they know, if you use React Native, you shouldn't have to recode your UI layer for different platforms.
Which is true, but the point parent misses, is that it might not be necessary if you just want a cross platform app, but it is needed if you also want it to behave more like each platform users are used to.
They are saying that from what they know, if you use React Native, you shouldn't have to recode your UI layer for different platforms.
Which is true, but the point parent misses, is that it might not be necessary if you just want a cross platform app, but it is needed if you also want it to behave more like each platform users are used to.
What are different platforms referring to here? The quoted sentence sounds like it means web vs apps but you (and the parent?) make it seem like we're talking about Android vs iOS.
And Windows vs OS X vs Linux.
Parent was saying "you don't need to do this in react-native" regarding the following sentence:
> With React and React Native, your web app can share most its logic with your iOS and Android apps, but the view layer needs to be implemented separately for each platform.
This is referring to web vs apps, in other words React vs React Native. That's the context of my reply. They are not talking about the (optional) differences within a React Native app to fit different platforms.
> With React and React Native, your web app can share most its logic with your iOS and Android apps, but the view layer needs to be implemented separately for each platform.
This is referring to web vs apps, in other words React vs React Native. That's the context of my reply. They are not talking about the (optional) differences within a React Native app to fit different platforms.
Ahem. I nearly thought Microsoft had partnered with ReactOS for a minute there :)
But XP is EOL, so "XP" is never going to be used in anything now, thinking about it.
I can wish...
But XP is EOL, so "XP" is never going to be used in anything now, thinking about it.
I can wish...
So Microsoft now have -2- cross-platform application-frameworks they offer:
- Xamarin with .NET. Mobile apps only.
- ReactXP. Which also supports regular web-applications
It will be interesting to see if these two end up competing, or if one will be ditched in favour of the other.
- Xamarin with .NET. Mobile apps only.
- ReactXP. Which also supports regular web-applications
It will be interesting to see if these two end up competing, or if one will be ditched in favour of the other.
Also http://reactiveui.net/ which looks quite good, but doesn't have good enough documentation for me to commit a project to it yet.
AS a C# programmer, I hope MS can be more focused on Xamarin. Have tried react kind of staff, just can't get into javascript.
As a previous c# programmer, the language is pretty powerful now, it has things now that can make c# look poor in some aspects, but, you get there only through a setup. If you have tried JS with node being installed, npm, webpack, babel and all this stuff, the experience will be poor. Though with these things in check, there's nothing that will pull me back.
Why?
Is there a screenshot somewhere to see how it looks like our am I missing something?
indeed a set of cross-platform samples would have been nice
There's a hello world in the samples directory https://github.com/microsoft/reactxp
[deleted]
I really want React for desktop apps. Currently we are running into some performance issues with large datasets and spreadsheets, and being able to offer a performant desktop app would be ideal.
Right now we're considering using .NET and ReoGrid, since Qt is too expensive and we only target Windows anyways.
Right now we're considering using .NET and ReoGrid, since Qt is too expensive and we only target Windows anyways.
You can use Electron and do that. Not a ton of love for it around here because omg a web page as a desktop app the horror but I've had good experiences with it. (And if you e ever used Slack or Atom, you've used Electron)
>You can use Electron and do that. Not a ton of love for it around here because omg a web page as a desktop app the horror but I've had good experiences with it.
Parent specifically mentions they want to get away from the performance issues of web apps [1] -- and you suggest they use Electron -- and even bring up Atom and Slack as examples, the worst CPU/slowness offenders of all time?
[1] "Currently we are running into some performance issues with large datasets and spreadsheets, and being able to offer a performant desktop app would be ideal"
Parent specifically mentions they want to get away from the performance issues of web apps [1] -- and you suggest they use Electron -- and even bring up Atom and Slack as examples, the worst CPU/slowness offenders of all time?
[1] "Currently we are running into some performance issues with large datasets and spreadsheets, and being able to offer a performant desktop app would be ideal"
"I really want React for desktop apps". There's currently one way to achieve that, was simply suggesting it.
They didn't mention web apps at all.
They didn't mention web apps at all.
You can use Electron to handle performance-sensitive large datasets and spreadsheets for a desktop app. But I think there is an even better solution for this: you could program it in DOS 5.0 batch and ship it with a Windows 3.1 VM to really juice out that last bit of performance and efficiency.
Check out React Virtualized. I have used it with great success and large datasets.
https://bvaughn.github.io/react-virtualized/#/components/Lis...
https://github.com/bvaughn/react-virtualized
https://bvaughn.github.io/react-virtualized/#/components/Lis...
https://github.com/bvaughn/react-virtualized
Take a look at React Native for macOS [1].
[1] https://github.com/ptmt/react-native-macos
[1] https://github.com/ptmt/react-native-macos
.NET and WPF is a great choice for desktop applications. I have been creating desktop applications with WPF for the better part of a year, I find it very nice.
If you have a performance problem and you only target one OS, using React seems more like a band-aid than a real solution. I assume your app is currently written in javascript, because I don't see any other reason to use React for performance.
I think you should consider moving away from JS, it will probably save you from future problems.
I think you should consider moving away from JS, it will probably save you from future problems.
It was originally supposed to be (and built as) a web app, but it's only being used inside a corporate network (yay requirements). So that defeats the original purpose. Might as well make a desktop app.
I'm missing something. How is this different to react native, which is already supported on ios, android, web and UWP?
>With React and React Native, your web app can share most its logic with your iOS and Android apps, but the view layer needs to be implemented separately for each platform. We have taken this a step further and developed a thin cross-platform layer we call ReactXP. If you write your app to this abstraction, you can share your view definitions, styles and animations across multiple target platforms.
That's interesting. But I wonder if many product developers will be ok with a common view layer -- Android and iOS's UX and design language are different (Icon sizes, tab bar, back button... all that).
How do you use React Native on the web?
You can use React Native for Web [1].
[1] https://github.com/necolas/react-native-web
[1] https://github.com/necolas/react-native-web
There are several React Native web players. One is used in their documentation site.
Well, in case of the web I meant react
And that's the thing. You need to reimplement your UI code separately for react and react-native. react-xp abstracts all that away.
That's something different though. It looks similar, but there are differences - and this library is solving them.
> ReactXP currently supports the following platforms: web (React JS), iOS (React Native), Android (React Native) and Windows UWP (React Native). Windows UWP is still a work in progress, and some components and APIs are not yet complete.
Seems interesting. Hope they add linux support.
Seems interesting. Hope they add linux support.
Interesting to see if this will co-exist with xamarin or will target different type of apps.
See also https://microsoft.github.io/reactxp/blog/2017/04/06/introduc...
It came out of the Skype team. But it doesn't look like they're currently using it in their universal Windows app, which is built directly on XAML.
It came out of the Skype team. But it doesn't look like they're currently using it in their universal Windows app, which is built directly on XAML.
And I believe the desktop (Win) version of Skype is still in Delphi, right?
The latest Skype is UWP
I don't think so. Just checked with Spy++, I can see a lot of TControl-s (Delphi/VCL controls).
I can't find any instructions on how to try any of the samples: supported host platforms, prerequisites, downloading the toolkit, building the samples, etc.
This name is _really_ confusing in the presence of ReactOS
At first when I landed, I thought this was another Facebook tech site since the template was reused from the old site of Jest and React Native.
Having macOS in there would have made it perfect.
You can address MacOS and Linux with current support. Just pack web app in Electron.
Then why would Windows need explicit support?
Don't forget that UWP targets only Windows 10 and moreover it unifies development cross Desktop and Mobile. So we can read React UWP as small support of easy deployment to Windows 10.
There is no support of ReactXP for Window 7/8 so there is again Electron+Web as only viable option when using ReactXP.
There is no support of ReactXP for Window 7/8 so there is again Electron+Web as only viable option when using ReactXP.
Please see my comment here: [1]
[1] https://news.ycombinator.com/item?id=14068458
[1] https://news.ycombinator.com/item?id=14068458
This is simply awesome. Nothing more to add.
At first I thought this was somehow related to the ReactOS project...
With RN's and Expo's out of the box support for Android/iOS, I find the missing piece is native support for Responsive Grid layout. Till then, I've derived one based on the new support in RN v0.42 for relative dimensions. I've taken the liberty of correcting the mental model for Grid to eliminate the decoherence that results from using both an absolute column count together with relative sizing (!) by letting the developer specify grid column width as a percentage of screen size and allowing the specifying of the width of a given column in the layout as a multiple of that percentage. This way the developer doesn't have to divide the screen size in pixels (assuming they know that for the screen they're testing on, which is not always the case) by some arbitrary number of grid columns in order to get the width they desire per grid column (indirect route.) They can instead use visual intuition about relative sizes to define the column width directly as a percentage of screen width. I also found RTL support (for Hebrew/Arabic apps) generally lacking in RN, so I added RTL layout support to it.
https://github.com/idibidiart/react-native-responsive-grid
https://github.com/idibidiart/react-native-responsive-grid
It's not just different platforms but different screen sizes (and RTL layouts) that's the biggest challenge I found in developing React Native apps. To solves those challenges, I'd like to share something I've been working on: a responsive grid for RN with RTL layout support. It has reduced the time it takes to build relative size and responsive layouts by a factor of 10, easily. It's based on previous similar work but with some radical changes and a few functional and usability enhancements. Looking for testers!
https://github.com/idibidiart/react-native-responsive-grid
https://github.com/idibidiart/react-native-responsive-grid
microsoft owns 5% of facebook
[deleted]
Embrace.... extend.... extinguish.
Be very careful when an OS vendor makes a move like this.
Be very careful when an OS vendor makes a move like this.
> The Skype team initially adopted the Flux principles, but we found it to be cumbersome. It requires the introduction of a bunch of new classes (dispatchers, action creators, and dispatch events), and program flow becomes difficult to follow and debug. Over time, we abandoned Flux and created a simpler model for stores. It leverages a new language feature in TypeScript (annotations) to automatically create subscriptions between components and stores. This eliminates most of the code involved in subscribing and unsubscribing. This pattern, which we refer to as ReSub, is independent of ReactXP, but they work well together.
That's interesting, I wonder how this differ from redux and others
I wonder also how is navigation is handled, is it easy to add react navigation in the mix?
Clicking on Next while on https://microsoft.github.io/reactxp/docs/animations navigates to a 404