ReactXP – A library for building cross-platform apps
microsoft.github.io
microsoft.github.io
Example of native modules with React Native wrappers: https://facebook.github.io/react-native/docs/components-and-...
NativeModules API: https://facebook.github.io/react-native/docs/native-modules-...
Although much as it pains me, I think that is a lost cause. And it was lost through attrition - devs kept throwing non-native (often, JS-based) apps at users, and users got conditioned to each app having its own look, much like websites.
Fortunately, it does seem like these platforms are beginning to converge on a set of common UI patterns, e.g. Android adopting the tab bar, and iOS apps beginning to adopt Android's horizontal-paging navigation. The colors, iconography, and typography shifting can disorient somewhat, but I'd argue it's the navigation model that's most disruptive when using different apps.
Also, the security and performance implications of the Javascript dependency ecosystem should not be ignored.
Small greenfield app on a shoestring budget? It's perfect for that.
My comment was that it doesn't preclude it, addressing the parent's conflation of language and view layer.
Yes, you might have to do more work in React Native. But similar frameworks[1] appear to do this out of the box, if that helps.
In Qt (QML), I couldn't quite find something like this and I had the feeling I needed to create my own framework from scratch, which is hard when, at the same time, you need to learn a new technology. There were some random ideas in various blogs and articles but nothing major or at least no officially supported one.
...note how I’ve said nothing to refute your comment because what you wrote it in responds to none of the historical empirical problems with this approach and just asserts “let’s make this not suck” glossing over the reasons why it sucks.
Apps do the same things everywhere. Why do we still need completely different languages, codebases, etc (not to mention teams of experienced hires) to deploy any little CRUD app?
Maybe we aren’t interested in fixing this because it means there’s less engineering to be done.
“It is difficult to get a man to understand something, when his salary depends on his not understanding it.”
I think it's less about engineering costs and more about dislike of javascript. Maybe even specifically javascript tooling and electron.
A big reason people want to standardize on javascript is because it is the runtime of the Web - I can't wait for Web assembly to get even better so we can standardize on something else.
You are writing code that runs nowhere, unless you can afford to shell out $1000 a year to keep your hardware current and $50 a month for the bandwidth to keep your software current. That's totally unsustainable from a global perspective.
In my view, the big issue right now is Electron, and developers who are comfortable developing for 1 Google browser per application. There's enough wrong with the current browser ecosystem that we don't need to make up numbers.
That sounds like incredible hyperbole considering all the major browsers are evergreen now.
Unfortunately, there is an almost religious devotion to it so it ends up used for many things it is actually terrible at (large teams, integration with large existing native apps, performance critical and highly interactive apps, apps that would be better off serving one platform, etc).
Good news is they have invented a better programming language called ReasonML for React.
But seriously, if you're concerned about the quality of software, build better tools that guide new developers into best practices. Remove needless abstractions, replace others, and optimize the rest.
A couple of projects to watch out for:
Each of those issues likely wasted hours, days or weeks of time for many, many people.
- As another commenter mentioned, they ignore and close legitimate issues on a regular basis
- Breaking changes are a way of life and extremely frequent
- They ignore native warnings: our project had zero before introducing RN, now has hundreds
- Navigation is a mess
- Integration with existing native apps works for tiny features but falls apart in larger teams
- Debugging issues that cross the JS <> Native boundary is a nightmare
- Keeping pace with native updates is made much more difficult by the API churn- want to update to Xcode 10? First you have to update RN, which will break all your features
- Poor maintenance of views meant to mimic native views
- If you have a hybrid native/RN app, instead of reducing the platforms you have to support from 2 to 1, you've effectively increased it from 2 to 3
While React Native is open source, Facebook does not prioritize needs that are outside of its core use cases. So many frustrating aspects of RN go unfixed by FB, and issues and PRs about them get ignored by the arrogant guy who closes issues without any explanation. Not sure how he thinks he's helping anyone by doing that.
Now that I think about it, I think I would actually enjoy being employed to help maintain the React Native project. I really had a lot of fun building a React Native app, but there were so many issues that didn't get any attention. It would be quite fun to spend all day helping people with issues, fixing bugs, writing tests, and merging PRs. That probably sounds like a terrible job to some other developers, but I really enjoy it, and it would be great to get paid for it.
[1] https://github.com/necolas/react-native-web [2] https://github.com/Microsoft/react-native-windows
> And here's ReactXP which is baked in to Skype (consumer) to make it possible to ship cross plat and single code base native applications with consistent UI
[0]: https://twitter.com/TheLarkInn/status/1006857447364063232
Everyone knows Office is C/C++. Ported to iOS and Android thanks to that.
> All of Office 365 is (almost finished) being completely rewritten in this little scripting language called #JavaScript.
[0]: https://twitter.com/TheLarkInn/status/1006746626617008128
https://twitter.com/TheLarkInn/status/1006762319790125057
It's not clear to me that maintaining multiple forks of react native per environment is so much easier. And that still doesn't buy you native performance & controls. I don't really get it to be honest.
I see Atom called lightweight all the time. I remember when my PC had a 5MEG HDD and exactly 640k of RAM, so...
I'm curious what amount of resources (disk, runtime memory etc) is used for something like a small CRUD app (think simple phonebook or CD library)
If you know the answer for proton native, please post that too!
As a very adopter of react, flutter tickles me the same way.
I have a proof of concept already, but it's not cross-platform so that's a major downside, and I don't think many people need the combination of (1) Mac-only, (2) lightweight, (3) using JS for the core logic, (4) using web views for the GUI. I just don't think there's a market for that.
https://github.com/zserge/webview
https://github.com/Boscop/web-view
and so on
If people are willing to download that much for an entertainment product, then it should be no surprise they are willing to put up with javascript in their work and personal productivity apps.
https://github.com/Microsoft/reactxp/issues/19#issuecomment-...
So cross platform minus Linux then?
Xamarin: Deliver native Android, iOS, and Windows apps with a single shared .NET code base.
ReactXP: Share most of your code between the web, iOS, Android, and Windows.
Microsoft wants people who would otherwise only have written iOS and Android apps to also write Windows apps.
How does ReactXP differ from Xamarin?
Xamarin is a cross-platform solution that allows developers to create apps on iOS, Android and Windows Phone using a single code base. Xamarin apps are written in C# and XAML, allowing .NET developers to leverage their skills and experience. Xamarin apps can be more efficient than React Native apps, which are limited by JavaScript performance and the overhead of the React Native bridge. Xamarin was acquired by Microsoft in early 2016 and is supported by a dedicated team of engineers. It offers a comprehensive development solution including tools for coding, debugging, performance analysis, builds, automated testing, and distribution.
ReactXP, unlike Xamarin, provides a way to create mobile apps and web apps using the same source base. ReactXP (like React and React Native) allow experienced web developers to make use of their existing skills and knowledge. ReactXP was developed by the Skype team at Microsoft in support of their development needs. ReactXP builds upon the work of Facebook and the broader React open source community.
Both Xamarin and ReactXP are great solutions, but they solve somewhat different problems.
So, not exactly cross-platform.
Quick search of the project issues shows that macOS is already mostly supported: https://github.com/Microsoft/reactxp/issues/19
It looks the project leads want more consensus on Linux React Native (ie, something actively maintained and preferably merged to mainline React Native support): https://github.com/Microsoft/reactxp/issues/41
How is it better than React and React Native if it still is web+mobile+Windows and doesn't offer Linux and macOS support? Also doesn't the fact React is by Facebook and ReactXP is by Microsoft and introduces Windows support look suspicious like if they were building an incompatible version of React like they've done with Java in the past?
We just built a ground-up PWA and users LOVE it (Android/iOS, tablet/phone/PC).
Why complicate and slow your programming + production software down by trying to XP?
Remember 2001, when everything was named XP - WindowsXP, AthlonXP, etc? The name is almost nostalgic.
And being Microsoft, I'm surprised it's not "ReactXP.NET for Windows Server by Cortana".
It's React, it supports iOS, Android, Windows and web...
What was the point of your comment?