React Native for Windows and Mac
microsoft.github.io
microsoft.github.io
http://npm.anvaka.com/#/view/2d/react-native
From my experience, it's really great to work with and definitely saves a ton of work, but the depgraph above fills me with doubt for use in sensitive applications such as in finance or healthcare. For this reason, I've been trying out Flutter or even considering to go back to native apps. Perhaps there's some kind of middle ground where we can create a tight microkernel-like thing natively using secure enclaves and key managers, but expose an API to the "untrusted" parts of the program. This approach is not without its own downsides, such as dark patterns in a compromised UI. However, as one friend pointed out, a lot of those deps are indeed for build time only, which have different risk profiles.
The depgraph of reactjs is far simpler and easier for me to understand and therefore feel trust:
http://npm.anvaka.com/#/view/2d/react
Does anyone know if there has been reliable research towards the security of the entire RN dependency tree? Seeing a stray dep there that has 1 maintainer on npm/GitHub who has been inactive for over a year makes me nervous. Any one of those JavaScript projects could do something nefarious deep under the hood, and this to me seems to expose a huge surface area for attackers.
Here's a classic throwback to keep us on our toes :)
But as I browse it, most of the dependencies seem to be build-time, not runtime dependencies (i.e. it seems like most of them are related to Babel). The React comparison doesn't include dev dependencies.
While react-native does have more dependencies than vanilla react, on first glance the list doesn't seem too crazy https://github.com/facebook/react-native/blob/master/package...
Plus I forgot to address this in my earlier comment: that visualizer only shows dependencies. By default it doesn't load any dev dependencies. You can confirm that for yourself by checking out https://npm.anvaka.com/#/view/2d/rollup for example - only the single runtime dependency on fsevents shows up, the dozens of dev dependencies Rollup has don't.
So yes, React Native does ship that overcomplicated graph of dependencies to all its users. I'll grant that at least _some_ of the code in those dependencies gets tree-shaken out.
EDIT: To be clear - maybe I am REALLY old-school, but every time we did a release, we archived our tool-chain (GCC blah blah, Make blah blah, bash blah blah), our depencies, our vendor libraries and our code, so that IF in 20 years, if we had to rebuild a particular release (12.x) for a particular client (Chase) on a particular platform (AIX), we could do so de novo. Maybe that was overkill, but in a world where everything changes, why wouldn't you snapshot everything for every release?
A fine grained capability system for packages would dramatically improve the safety profile, and if this were built into package.json and the lockfile we could do the following:
1. Packages advertise what their default capabilities should be limited to 2. Changes in those capabilities are encoded in the package lock file, and can't be changed without the user explicitly affirming them
¹ and other langs with extensive use of package managers and micro-packages
I think Deno does that (the new project by Node's original creator):
With tighter snyk integration into npm and the acquisition of npm through ms one could argue that security bar may have risen/will rise but I (speaking as a js/ts dev) am still sceptical. I haven't really looked to deep into stuff like selinux/apparmor/firejail [3] maybe someone can give an opinion on this. I'd wish for something that would be codeified on package level to make review easier and give me some peace of mind.
For now my plan is to dockerize most of my projects and it's dependencies. It should give a little more protection against malicious postinstall scripts.
Unfortunately, I depend more and more on npm modules outside of projects (coc-vim comes to mind/for others it may be vscode etc.).
[1] https://medium.com/hackernoon/npm-package-permissions-an-ide... (2018) [2] https://medium.com/hackernoon/im-harvesting-credit-card-numb... (2018) [3] https://github.com/netblue30/firejail/blob/master/README.md
Maybe it could be solved by type checking during dependency resolution time: instead of just checking version numbers, also check capabilities that transitive dependencies declare.
Maybe you could slowly boil the ocean by assuming that everything that doesn't declare required capabilities implicitly requires the "ALL" capability, and triage+prioritize a growing core of packages that have explicit capability requirements. In my mind it's kind of like purifying functions in a library: you start at the lowest level / leaves of the call graph and make sure they don't do any I/O, and then the things that call them can be made pure and so on up the chain.
That sounds like it would be working. If you declare that your package doesn't need network, and it fails because it used the network, that sounds like a bug was caught.
But npm-snark aside, maybe some lack of trust must come from a highly modular open source ecosystem.
If a library I ship could abstain from unneeded platform capabilities, that would certainly reduce catastrophic bug/attack surface, and I'd sleep better.
https://www.npmjs.com/package/number-is-nan
Want Array#filter/map/reduce? Why that'll be three separate packages:
https://www.npmjs.com/package/array-filter https://www.npmjs.com/package/array-map https://www.npmjs.com/package/array-reduce
It just seems to be the culture of the Node.js crowd to take a library, break it up into functions, and publish every. single. one. as a separate package.
To criticize this organization, you would need to understand why people find that to be valuable and show a better approach.
You’re attributing it to “culture” but there may be deeper, less arbitrary reasons. Look up “ponyfill” if you are interested in learning about it.
I’d rather trust a fairly big library with an organized open source group behind it than thousands of small libraries by unknown developers.
Also the legal team likes this a lot more too. If a data leak occurs due to some library that Microsoft wrote, we have one company to sue. If it's a react package, who the hell do we go after? Most of these are "at will" / MIT license style things, so we are more or less SOL anyways, but legal teams don't like hearing that.
You also get at a more fundamental question. What is trust? Why can we trust a larger organization over a collection of individuals? Are they not the same thing? What social structures make one more trustworthy over another?
There's a great book on this by Bruce Schneier called Liars and Outliers. I highly recommend you read it.
isNaN() has been in the language forever. And in case you really need Number.isNaN() (because it's weird for isNaN('foo') to be true), it's been there for quite a long time too. Not enough to be on IE, sadly, but certainly more than enough to be on the modern JS engines React Native runs on.
So, at least for React Native, the package number-is-nan shouldn't be necessary at all. But it's probably a transitive dependency, and that's basically the problem with all these sort of polyfill packages: you might not need them, but a library that runs on older engines on which you depend (directly or transitively) does need them, so you end up paying the price anyway.
which actually if I look at number-is-nan it returns
return typeof value === 'number' && value !== value;
I never use the typeof value === 'number' myself because I always know if what I'm checking is NaN should be a number of not, but probably that's a bad habit to get into.
Polyfills and single-function libraries are just two different problems with the NPM ecosystem.
KPIs are always the driver. Also for programmers.
This says so much about the sad state of modern software development...
When native development is a last resort.
As an end user why do I care about "openness"? If I pay a premium for my platform, why would I want second rate cross platform software?
Falsehoods HNers believe about how people buy/use software. Didn't stop Slack/Discord from become ubiquitous.
"But native tho" just becomes a circlejerk. Talking about what users care about, most people don't know what native means nor if a given app is it. They don't know if Zoom is using more memory or CPU than it "should".
Are you paying for your software or getting whatever you can find for free? If you are paying, is the software's leanness something you value - that is, will you buy some software because it is leaner over some other software that is heavier? Would that be even if the heavier software has more features?
What sort of software have you bought? I'm asking seriously, not trolling - i've bought Total Commander myself exactly because it was lean (check: windows calculator vs one of the most feature packed file managers[0]) but i do not think there are many that value things like that.
this is something that you might value but I think it's fair to say it is already a minority position.
phones and the web have become the primary platform for software delivery, and people do not treat their desktop if they even have one as some sort of premium platform, it's a terminal for the internet.
at this point, people are probably more familiar with the look and feel of web applications than they are with native applications and value similarity across platforms over features of individual platforms. The operating system and the hardware are increasingly becoming irrelevant and a detail compared to the web on top.
More developers, more applications of software.
At the same time, performance has a tangential relationship with computer code being interpreted or compiled to native.
After all, Java is compiled to byte code and powers plenty of high traffic servers efficiently.
Many AAA games use ActionScript, Python, Lua, etc for their UIs and scripting for mods.
While it's true that there is no substitute for code compiled to native when high performance is called for, I think it's justified for native development to be last resort.
This is coming from someone who codes primarily in C++, where high performance is important. I wish I didn't have to.
How well has Java done on the client in the last two decades?
Many AAA games use ActionScript, Python, Lua, etc for their UIs and scripting for mods.
What's the actual performance sensitive parts written in?
So I am not sure what you are saying. Everyone that is able to is compiling their stuff to try to regain some efficiency.
The reason is that people wants to do more complex things with their software nowadays, and hardware can't keep up with the trend. There is also battery life, smartphones, tablets...
Those are the reasons we are seeing a resurgence of native development.
This isn’t just me being a Mac snob. I found Apple’s few Windows apps over the years to be just as bad.
Yes and a long time ago Sun came out with Swing. How did that work out?
Even before that MS came out with P-Code and the abomination that was Word 6 for the Mac.
I think it clearly shows that complex UI apps require cross platform UI, or will remain single platform (Xcode, Visual Studio).
Why would you think React Native would be less bloated than native apps?
If you want to know what it's like to have everything break LITERALLY every few days, use react native.
The update wasn't terrible.
My favourite is the factorio research tree. It gives you a sense of depth and you can select dependencies.
Maybe I'll implement it one day when I have the time.
Fortunately, in such industries you don't have to worry about being cross platform particularly. Go write C# and WinForms (or whatever it is these days). Or use Lazarus/FreePascal if you do need to be cross platform.
This also voids the argument "we need Electron, because it reduces development costs, and we can get truly cross-platform apps". Ripcord is written by a single indie developer and runs on Windows, Mac, and Linux. Imagine what could be done if Slack employed a team with 10 Qt developers.
Most web apps are egregious. The problem is that there is a whole generation that is not exposed to Delphi or Qt Designer and have the false believe that developing web apps is an order of magnitude easier. It's only an order or magnitude easier for them, because web tech is the only thing they know. Heck, I was writing GUI apps as a 12y/o with Delphi.
That might still be better (I'm undecided, personally), but it's worth recognizing that heavy native app is still there, just shared with a lot of other JS apps.
Imagine how much more enjoyable npm would've been if prominent JS devs took a sane approach to dependencies, like the TypeScript team who have no runtime deps.
The resulting npm deps of hell [1] means they need to rely on complex build solutions like Webpack to manage it all. My preference these days is to avoid npm/yarn all together and just use TypeScript watch (tsc -w) for incremental updates which lets you develop modern JS using modern fx's (e.g. Vue/React) without any of the npm/Webpack complexity & only requires a vastly simpler build solution to minify/bundle all UMD deps together.
[1] https://www.reddit.com/r/ProgrammerHumor/comments/6s0wov/hea...
I'm actually surprised, I thought React had many more dependencies.
Edit: Removed comment related to typo, no longer relevant.
The core library deps isn't relevant, it's how many deps the smallest starting Create React App has that matters [1]. As mentioned by OP react-native is far worse.
Also, with TypeScript, Babel becomes completely unnecessary. I haven't used it in any of my React projects for years. Many templates still include it by default to match the JS version, but if you create the project from scratch without any scaffolding, there is no reason to do so.
https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al...
It really doesn't bode well for microservices of any large scale complexity, unless there are concentrated meganodes with limited interconnects like cities and superhighways.
Bloat though ... I mean, if every npm module was simply a directory with a package.json file and a couple js files I'd be happy. But thats almost never true, and usually for bad reasons. I'm not sure how to fix the problem. A few years ago I worked with a guy who maintained a popular little 200 line react image component on npm. The project website was great - with example images and whatnot. Some software we worked on used his library. Our node_modules was huge, and one day I took a look to try and figure out why. It turned out his tiny module was bundling all ~10mb of example images in the package itself.
He was shocked and embarrassed when I pointed it out to him. The library had thousands of stars on github at the time. Lots of people were using it but nobody had noticed and mentioned it to him.
10mb isn't that big, but this is the sort of sloppiness that really adds up over time & thousands of transitive dependancies. Would tooling fix the problem? Maybe a little, but I suspect the problem its partially cultural. A lot of the web development community suffers from a lack of ... thoroughness. Like, the expectation is if the website works and looks pretty, you've done a good job. And invisible bugs and issues get overlooked consistently. Like app bundles which silently include multiple copies of the (200k) moment timezone database. Or obvious security issues that web devs just don't know to look for. I suppose this is how juniors learn - but it feels like a very lonely place sometimes when you have skills and experience.
Meanwhile WinAmp was sooooo tiny.
It would be a huge quality-of-life improvement for React developers, not to mention the improved security and reliability.
I wonder if React Native can do all of this officially, but I suppose that's not their prerogative, given that RN is mostly used by Facebook for apps and these other platform efforts are by third parties, like Microsoft here.
What dependencies are you using that continuously broke? Did you track your package lock file on Git?
EDIT: Ive also tried React Native Web and it pretty much worked OOTB. Alerts were the only thing I found that weren't implemented, but they didn't show any runtime errors or instability
Expo is wonderful for prototyping and quick iteration. The ability to use Snacks online and see them working on the phone is great.
But beyond that everything in RN feels hacky and unfinished. While working with it I had some silly issues with Metro, and found some subtle bugs in Text and Button components.
About the "Native" part. I think that a lot of people have the expectation that doing RN apps will be the same as building a iOS or Android native app. But RN+Expo is not that different from frameworks like Ionic. Is really hard to do an app that follows the Apple HIG or Material Guidelines, you end with something in the middle that doesn't look or feels truly native (at least not without tons of extra work to imitate things that you get for free in the native UI kit) .
RN without Expo is not so nice, lots of rough edges and sooner or later you'll need to write interop code in Objective-C or Android Java to take advantage of the native platform.
As of RN 0.60 it has been completely smooth sailing developing a react native app sans expo IMO
If this happens over a weekend, expect your phone to blow up every three hours until it gets republished and fixed.
It’s nothing like ionic. When is the last time you used RN? RN apps are hard to tell from native.
The RN's core Button it’s a Text composed with a Touchable (https://github.com/facebook/react-native/blob/master/Librari...). It behaves in the same way but there are subtle differences in text rendering: the font size and letter spacing is not exactly the same, so when you create a native looking iOS view it doesn’t look the same unless to fine tune the font settings (and of course that will break when iOS decides to change it). This is just one small example, another one in iOS is “routing”. With the RN Router you don’t get the native components but a simulation of it. But Apple HIG doesn’t document many details of the animations and behavior of headings and nav bar (they assume that you use the native component). So if you want to have a native look and feel your options are: try an alternative router built for iOS, try to build your own adapter (hard unless you have tons of native dev experience), or try to imitate the native platform. All the options have pros and cons, and require more extra work over a small UI detail that you get for free using native tools. At least Flutter took the effort to make it look native by default.
In the end is similar to the desktop: if you want cross platform code is easier to not follow the platform rules. The differentiator of RN is that you have the option to embed the native widgets, which is not always easy. (The last time I used RN was mid-2019, I didn’t see substantial changes since then)
"Native" doesn't describe the programming language, but the GUI layer. Native == non-web-browser.
You can choose one of two things:
1) Run a single precomputed action or animation in native-land when receiving an event from JS. No interaction is possible.
2) Run a requestAnimationFrame loop in JS which is passing the bridge (6 API calls on Android - 3 layers per direction) 60-120 times per second in async mode. Enjoy the jank.
I'm quite sure and aware of people that love it, but just from my personal development background, it just never really seemed appealing to me. Definitely not a fan of how state is handled. I've rolled my own system, Redux, and a host of other solutions as well. It just all seemed unnecessarily complex.
As you said, to me it just felt like hacks on top of hacks. I'll take vanilla iOS and Android development any day of the week, and twice on Sunday.
With that said, and from what I've seen of Dart/Flutter, I really hope it takes off.
I guess the first is not backed by a big company and the second still has the Cordova stigma.
I'm sure every React developer has at some point found themselves banging their head on the wall trying to figure out why some child component isn't updating.
And yes, it's a personal preference, but I'm also not a fan of Javascript. If another client wants a single codebase app, I'm really gonna give Flutter a nice long look. I've read the docs, and it looks quite appealing.
For Redux with React, you could check out Redux Toolkit (https://redux-toolkit.js.org/). It solves a lot of the boilerplate issues with Redux. createSlice is especially valuable.
Did you know that Redux is now basically built into React?
https://medium.com/simply/state-management-with-react-hooks-...
https://blog.logrocket.com/use-hooks-and-context-not-react-a...
I also couldn't find ways to easily implement things I want, e.g. native Mac MenuBar bindings/Mac App Store payment library etc.
Eventually I ended up using Quasar https://quasar.dev/, which allows you to use one Vue.js codebase but deploy to Cordova on mobile and Electron on desktop. Vue is definitely not the prettiest solution out there, but I had to be practical and actually get the app out.
Maybe I'm just one year too early for React Native/Flutter ecosystem to be developed enough for my app. The landscape is certainly changing rapidly, which is good.
Regarding Windows and Linux, I too was surprised at how well everything worked. You can't build to production yet for these two platforms (officially at least, see flutter-rs for unofficial implementations), but the debug builds still work as well as the Android and iOS emulators. I used them on a lower powered machine to run my Flutter apps and it was great that they worked well.
Except hot reload
I prefer solutions like Xamarin / Mono where you can have a Cocoa UI coupled with C# or F# based dll's. Let's be honest, as long as you have a good way of maintaining a good state in your app for example by already using ViewModels that did most of the heavy lifting like formatting strings, having the state in a state machine and so on, getting the UI to work as required is just an exercise of filling in the colors between the lines.
Barely anyone would notice they were using a Xamarin based solution on a Mac, while the JS based applications are immediately really obvious to the trained eye.
I seriously hope that Flutter fades. It's very dangerous in many ways. Even ignoring the huge downsides of basically having a new Flash, consider this: the massive Flutter layer is, surprise surprise, yet another Google project that is magically _significantly_ slower in Firefox. I don't mean a small difference here, I mean that on a brand new fancy flagship I tested on, Flutter in Chrome is buttery smooth and Flutter in Firefox is a miserable, laggy experience. If it gets popular, this will become yet another reason pushing people off Firefox and cementing Google's dominance of the web.
Flutter is a very, very dangerous thing.
My personal hope is that Flutter gains traction and the web can move beyond current web/native technology. Postscript / PDFs aren't suitable for game experiences...and to my mind web standards have been shoehorned into supporting web apps, where there is a mismatch with native technologies. I'd like to think that Flutter can help bridge that gap.
This is not to say that accessibility etc. should be ignored...nor better support in Firefox...but even Brendan Eich is using Blink/V8 with Brave.
Anyhow, thoughts of one.
I loved what Flex brought to the table. Too bad Adobe didn’t open source flash and let it die.
Having worked with/on React Native for ~3 years I am definitely not a fan but at least React Native enables using native components directly even if this happens too rarely.
You lose all advantages that HTML and CSS gives you, links, styling, accessibility, text selection! ... It's basically a flash website... Which admittedly is okay for some applications
Flutter for Web is still on Beta, so lets see where it lands. Today, it seems to implement some PWA practices and lazyloading to try and get some performance.
Checkout the official [1] Flutter web demos. Even the simplest [2] example renders basically every part of the UI (including text!!) within canvas elements, which is a bit crazy to me... but yes it's still Beta, so we'll see what they can improve
Admittedly I need to go back and check but it was confusing and worrisome.
How did you query this? I want to have a look, but the fact "flutter" shows data since 2004 means the terms I'm using are inflated [1]. Flutter is a dictionary word after all.
[1]: https://trends.google.com/trends/explore?date=all&geo=US&q=r...
https://trends.google.com/trends/explore?date=all&q=react%20...
The biggest gripe I have with React-Native is the many JS packages on npm that we can't use due to how the code is exported. It's a huge hack job, which Flutter absolutely destroyed by having everything I needed as a package that just worked.
One thing I'm looking at on Flutter, is how their public packages age. If I can't use a 3 year old package on modern day Flutter, there will be some big problems coming soon.
That said, there's an effort in the community to find maintainers for older packages that people find useful. If you come across something that you need, post back, or shoot me an email.
I am curious about how often this sentiment gets brought up about Go or Kubernetes.
- consistent rendering/support across multiple platforms and versions
- multiple windows
- rendering to a window that isn't owned by the UI being rendered or created by the framework
Can I do that all in React native? Edit: don't need to bring up electron.
- multiple platforms...
Yes: Windows (x32,x64, ARM64), from XP to 10, MacOS, Linux/GTK, IoT and mobiles.
- multiple windows -
Yes. Multiple desktop windows and you can even render separate DOM elements in popup windows.
- rendering to a window that isn't owned by the UI being rendered
Yes, you can render it on top DirectX, OpenGL, Vulkan (coming) or in child window/nsview/gtkwidget. There is also Sciter.Lite that allows to render UI without any DWM - on frame buffer / video memory directly. Check : https://sciter.com/sciter-and-directx/
- don't need to bring up electron.
Not Electron. All this in monolithic dll/so (5..9mb) that even can be linked in statically.
- consistent rendering across multiple platforms.
Check screenshots of https://notes.sciter.com/ , are they consistent enough?
- ... for React
React (Reactor in Sciter terms) is implemented natively. JSX (SSX in Sciter) is a part of language/runtime - no need for additional compilers, etc.
- I'd love to abandon my C/C++ ...
No need to. You can still manage (update, handle events) UI directly from C++ if needed. You can even create custom native DOM elements that can even draw themselves by native code.
I can't really commit to sciter and your flavor of JS until it has a larger community, more docs, and more onboarding materials so I can get teams up to speed and working quickly, reinventing fewer wheels, and have more discoverability in your docs and community so I can even know how to do things and what I don't need to rewrite.
Some bencharks comparing engine performance to V8 would also be much appreciated.
I see someone actually submitted the homepage 40 mins ago so I upvoted it for awareness. This is so feature complete I'm frankly surprised it hasn't hit the front page before.
Can the native UI framework do multiple windows? - Then React-Native can do multiple windows.
Rendering to a windows that isn't owned by the framework is what React-Native refers to as Brownfield apps. This is absolutely supported. For instance, Microsoft Office is using React-Native for some parts of their UI in Android, iOS, Windows and macOS. And the Office window is not created or owned by react-native.
I once used a native library I installed with iOS' native package manager, Cocoapods. I rendered a React Native view inside the native view, which was contained inside a react native view. The only limitation is that the two react native views used separate bundlers i.e. the two react native views can only communicate through the native platform, they couldn't communicate to each other via JavaScript.
It's a hairier problem than you'd expect it to be. I'm not an expert but my understanding is that it's tricky to deal with the event loops when you're not the master of your domain, at least in a platform agnostic way. The workaround is usually to spawn multiple processes, but then the management of app state has to have an IPC layer underneath the internal APIs and there needs to be a master daemon running somewhere.
In keeping with front page posts, the plugin API for Apple's Logic Pro (audio units) is an example of that. You are handed an NSView* and need to render on it, but you don't create it.
Legit question, I just started using Electron, hadn't heard of the former and thought the latter was a selling point because all platforms wrapped Electron's Chrome.
Rendering consistency is generally pretty good; I haven't run into any issues with that.
STMicroelectronics uses it for almost all of their applications, which ship in one zip file with binaries for Win/Mac/Linux.
It ticks #1 and #2, but I don't know about #3.
Of course, I'm not sure if having web-like programming is your implicit #4?
Or you can build native WASM apps?
If electron is Chrome and Edge is Chrome and Microsoft uses Edge for this - then its all chrome in all directions. Native is much faster and more powerful - WE MUST RESIST!
React scripts native widgets, not HTML.
My own experience with React Native has been nothing but terrible, but it will be interesting to see how all of this will play out in the long run.
My unconventional take is the real gains from react-native come from converting existing native projects, while leaving as much native code intact as possible.
If Google went away tomorrow, V8, Chromium and Blink would still exist, and Microsoft would be able to use all projects.
The only cross-platform alternatives that I've seen in the ecosystem use either web or Gtk in the frontend, and both of these have a distinctly non-native feel to them.
QT Widgets, in contrast, do have native-looking widgets for Mac and Windows. You can use it with Python instead of C++, but it's a bit of a pain, and most of the Qt community seems to be moving towards QML, which is a far better developer experience.
Most cross-platform solutions are awful in at least one of those three, usually all of them.
https://github.com/wix/react-native-navigation is beautiful, it uses iOS' own navigation APIs, but it's a pain.
> We are actively developing React Native for Windows...
> Mac
> Coming soon
So React Native for Windows.
I’m skeptical (though certainly willing to be convinced) because RN runs your JS application in a separate thread from the UI, with a rather expensive bridge sending JSON messages back and forth. That seems to me a poor design choice.
Browsers have the downside of working with the complex DOM that doesn’t map as well to native widgets. But browsers are mature and highly optimized. So I would guess that performance might be a wash.
But if you overload the bridge, you not only hit a bottleneck, you hit an async bottleneck between your UI code and native. Very rare for that to happen in my experience, and well worth the trade-off.
* I think this is more of a selling point than a reality. I think in practice, to make a React Native feel and work well requires native platform knowledge.
Worth it for some. Personally, I refuse to use any Electron apps because they have a highly non-native-feeling UX and because they're resource hogs.
This announcement excites me, because React Native is likely to be an improvement on both counts.
The UX still won't be quite as native-feeling as a single-platform app designed for that platform's unique idioms – but as long as it uses native controls under the hood, that's still 10x better than Electron in my book.
And even without the bloat of Chromium, an app written in JS is still likely to be slower than one written in, say, C++ or Rust – but most GUIs don't really need that level of performance. And at least on macOS, the competition is not C++ or Rust but Objective-C and Swift, which are both slower, more on par with JS in terms of performance.
You can customize per-platform to provide a better experience than the web can offer.
It’s different in that it doesn’t use HTML or CSS (which is a major difference, sure).
I mean, say what you will about the quality of even Apple's own Catalyst apps, but at least they eat their own dogfood (although with the unfortunate consequence of making us eat it, too).
There are so many different competing projects at MS to do practically the same thing, it'd be great to see RN for Windows and macOS used for something major from MS.
Flutter left me a similar impression.
I eventually ended up using Quasar https://quasar.dev/, which allows you to use one Vue.js codebase but deploy to Cordova on mobile and Electron on desktop. Vue is definitely not the prettiest solution out there, but I had to be practical and actually get the app out.
Maybe if I started the project one year in the future, the landscape would be totally different already. It's definitely changing rapidly.
We do pretty complex stuff with RN as does Facebook and it's been serving us well. I don't know why someone would want to use it with Windows, but this tells how far the project has gotten.
I would love to developed native, but you just save a lot (maybe half) time using RN if you need the app for both platforms.
I can copy couple of dlls in a project folder, and run npm / yarn install, but that is the most I am willing to do.
So, my question is: is there a VS Code / npm only demo?
As an ex-windows developer, turned react dev - I am excited.
> This repository is a working fork of facebook/react-native that adds support for the official React Native for macOS implementation from Microsoft.
Does anyone know when these changes are planning to be upstreamed?
1. the recent FB messenger desktop apps are RN.
2. they leverage work done in forks (like this one from MS) to achieve that.
(I mean, sure, it "just" runs Windows, but...)
> Mac: Coming Soon
You know what, I think I'll wait for Flutter Desktop, or see who wins true cross-desktop compatibilty since Flutter already has Mac support but no Windows.
Too bad Rust does not have something similar.
I'm really not sure what's relevant now and what was relevant 6 months ago. I'm genuinely curious, but it's pretty difficult to grasp and no framework homepage is going to tell you "Don't use me, I'm about to be a dead project!" and every developer will tell you their preferred framework is the best framework.
React has been a core part of the front end ecosystem for almost 10 years. Angular is more than 10 years old. Vue is the "new kid" on the block at about six years old.
React is roughly 10x more popular than Vue or Angular according to npm usage, has been far more popular in usage terms for many years, and continues to be growing faster than either Vue or Angular.
Complaining you can't figure out if React or Angular or Vue will be relevant in six months is a bit like complaining you can't figure out if C++ or Java will be relevant in six months. Yes, there is lots of advancement happening in the front end space. Yes, that's a good thing. No, it's not an excuse to act like you're paralyzed to understand the current state.
I was around in 2014, when angular 1 was starting to be a big thing.
If you look at reactjs on google trends, react gets its first bump in 2014-15, and then another one around 2017.
VueJs gets a huge jump in 2016-2017.
---
Java has been around for decades, has had much fewer changes, and is entrenched in a lot of code. In comparison, react has gone through some big changes in a very short amount of time, and most people use it to build SPAs that aren't usually mission critical.
There are a bunch of others that are less popular such as Ember, Svelte, and Inferno which are also decent in their own right, but the ecosystem of libraries around them is smaller.
The most important libraries to know about in the React ecosystem are React-Router for routing, and either Redux or MobX for state management. There are other options, and for small apps you could get away without a state management library, but these are the mainstream options. I'm not super-up on the Angular/Vue ecosystems, but I believe they're more integrated (e.g. they provide more first-party libraries).
Almost everyone who is using these frameworks is also using either Babel or TypeScript together with Webpack for bundling. There are other options for bundling such as Parcel and Rollup, and again it is possible to get away without bundling or transpiling if you really want to, but Webpack is still the mainstream option for applications (Rollup is well-suited to libraries).
React-native is a different beast. It's a cross-platform mobile (and now desktop) framework rather than a web-based one. It uses React executed in a JavaScript VM to control rendering, but it renders native mobile UI toolkits. There are similar projects for Vue and Angular, but unlike the web versions which are competitive with React, they are nowhere near as mature. React-native's real competition for cross-platform mobile development is Flutter. Flutter is written using that Dart language, and takes a different to React-Native. Rather than compiling down to native UI widgets, it custom-renders everything. This makes it more reliable and consistent across platforms, but also more limited in what you can because you can't hook into the existing ecosystem of native ios/android libraries nearly so easily.
My subjective view on this is that React-Native is just about on the cusp of reaching maturity, while Flutter doesn't quite seem to have enough momentum to reach the mainstream. Although I'd love to be proven wrong on that one.
Microsoft and Facebook attacking Apple and Google basically.
IMHO it's not a sincere effort to make a nice platform. It moves fast and breaks things in major ways with each minor point release, with the current excuse being that it's not at 1.0 yet. But it offers just enough to introduce FUD into the competitors' ecosystems. And that's the entire goal as far as I can tell.
If you value getting useful deep knowledge, stay away. If you want to play in the shallows and be patching stuff up all the time with JavaScript/TypeScript, React Native is an option.
Also Discord's iOS app is built with ReactNative, and it is a pretty feature rich application, seems like it works for those use it.