I sympathize with cross-platform development woes (we have this problem too) but I can't say I've ever been impressed with a cross-platform app developed using React Native (or anything else cross-platform).
A React Native app isn't horrible or bad (nothing like Java Swing) but it also isn't delightful to use. Technically you have animations and things like the cross-platform navigator. In reality, you have a lot of performance issues and strange incompatibilities due to attempting to execute animation keyframes on the JS thread (or replace the system-provided navigation bar in the case of Navigator). It isn't terribly easy on battery life either.
I'd rather write my sync and offline storage system in JS and share that across platforms while leaving the entire view layer as native code. That stuff is far harder to get right for non-trivial apps, it just isn't sexy and most web devs ignore it completely because hey - the web browser is always online!
I'm biased though. Our customers download 5-10 GB projects with millions of objects in them because when you're building a hospital the MRI room is a literal faraday cage. No such thing as internet access in there and telling the user they can't pull up plans or engineering specs because they're offline is a non-starter.
Am I the only one who see the same story repeated again ?
We have now Facebook, a major actor on the web, who is developping a cross-platform toolkit for application development, using OS native widgets. XUL, I miss you :)
And now others try support different OS.
Mozilla created everything and they just failed to "market" it. It s at the same time a pain and a joice to see real JS applications, shadow dom, custom components, CSS based styling being the core of a toolkit while we saw XUL/XBL/CSS/native calls from Mozilla be killed a few months ago. It had its flaws, but it s a serious (but really difficult) way to go : Qt did it, Gnome did it, Microsoft did it, even Adobe tried to do.
Mozilla and people involved in previous ideas and implementations deserve a special mention for their work.
We really need such technologies, and that Mozilla killed theirs was a really sad choice for me. Creating software with "simple" markup, "simple" styling rules, "simple" event/user interaction handling should be a concrete goal of decades of languages/compilers/interpreters researches.
It has a price : performance, sometimes native look&feel not perfectly accurate, supported platform must have similarities. We may hopefully reach a level where a <button> tag will cost 1% of overhead against a native call and this will be a great day. I hope these new implementations will succeed, and that the actual overcomplexity in the web developpement will not land in though.
Facebook is an application / services company, so it wants its competitors to be non-existent or expensive (luckily, so far, it's more the first than the second), and its complements to be free / cheap and ubiquitous. Hardware / software / networks are its complements so it tries to make them free (give away internet access, build open source servers and routers, make cross-platform libraries, and so on).
Google is in much the same boat, and does much the same kinds of thing.
Apple is the reverse, so it wants its platform to be anything but a commodity, but apps to be free / cheap and ubiquitous (hence the App Store). Similarly, insofar as it creates differentiating development tools, it would prefer they be platform exclusive. (Swift isn't a positive differentiator; it mostly addresses a platform disadvantage, so it's free and open source.)
Disclaimer: I didn't feel the user experience you described. (and have a lot more experience with XUL than QML)
What I experienced is that actual performances of crossplatform "runtimed" toolkits are enough for desktops and acceptable for mobile devices, but the global overhead (compared to a binary using native OS widgets) exists, beginning with startup cost, memory consumption, i/o latency. In fact, the same constraints that VM-based languages have. And even more : the underlying GUI toolkit may be used in an unexpected way, strange GPU driver behaviours may pop up, how not to be bothered by OS fragmentation.
And then an application may run flawlessly on a device with a given OS while on another it performs not that good.
While I think it's correct to say that VM-based languages does not have to blush in front of compiled programs when talking about raw computing performance, my experience (as an ex XUL-lover, I may be biased) make me think that this is still not true when UI is involved. Java has maybe the oldest (and most optimized ?) runtimed UI, and it does not convince me. OK, this may be a bad example : Java UIs are "runtimed" at a different layer. but seeing the length of the QML performance wiki page is a bit scary :)
Maybe the "1% overhead" is an unreachable dream, and maybe the native apps will become deprecated, but I think there are a place for improvements. How many attempts of crossplatform UI runtime exists ? Not that much. With hardware improvements, the overhead will be more and more acceptable.
It s a huge work, and previous errors should be looked at (rant time : Mozilla: you should not have stopped to use native widgets - Adobe: Flex - QML: mimicking web dev like XUL did is nice !).
Though, I am really impressed by Qt and .Net SDKs and I would really love to see more free software and linux surprises from Microsoft with the Xamarin acquisition.
And, let's be utopic, the future is maybe about a standard API à-la POSIX for end-user applications, where OS vendors will agree on an app, and natively implement their own <button>, their own <menu>, their own <video>. They do if for the browser, for the "webassembly", why not for the OS ?
Or the browser will be deeply integrated in OS and the "web" apps will replace all native applications. Or they'll still coexist for years.
OK, anything but embedding a webview would please me :)
"Compiled Qt Quick is an elegant solution to these problems: .qml files as well as accompanying .js files can be translated into intermediate C++ source code. After compilation with a traditional compiler, the code is linked into the application binary. This entirely eliminates the need of deploying QML source code, it reduces the application startup time and allows for a much faster execution on platforms that do not permit Just-in-time compilation."
What really bugs me is that the browser keeps failing to step up to the plate. Despite everything, browsers still don't come close to supporting a first class user interface Why can't web apps have proper (native) toolbars, menus, etc. instead of "the best half-assed simulacrum you can make out of divs, css, pngs, svg, and javascript? This was the single glaring deficiency of Hypercard back in the day, and it's been faithfully replicated by the W3C et al for over twenty years now.
Sure, this would all need to be reasoned about carefully to avoid visual security loopholes, but it's not like we didn't live through Flash and Java.
"It has a price : performance, sometimes native look&feel not perfectly accurate, supported platform must have similarities."
This is what makes the whole idea a complete non-starter. Users want apps without perceptible latency for their interactions, that look and (more importantly) work like the other apps they are used to. Hard to come up with more important criteria for a successful end user application than these.
I really agree. I described the current state.
As my next comment explain it more, there is room for improvements.
Is the "write once run everywhere" paradigm a realistic goal, would it be achieved at runtime or at code generation/compilation, without an unbearable cost for users ? I want to believe.
> Is the "write once run everywhere" paradigm a realistic goal
A part of me sees react-native adding another option here - "write once, tailor anywhere"
While it's always been possible to have common core logic and then tweak your frontend for each platform as a separate project to get a slightly closer to actual native experience, react-native makes it significantly easier to do so and I think it's that one+ standard deviation away ease that makes all the difference.
I don't think we'll see a lot of successful react-native cross platform that goes for the one-size-fits-all approach but rather, with the same (probably even less) effort, we'll see react-native apps that target the UX of a platform rather than just the UI elements.
If you look at Apple, Google, and Facebook as competitors - I think it's clear that Facebook feels vulnerable that it does not own a programming language. I see RN as their push to create a unique "language" that people build apps in.
I'm a big fan of React for frontend web work but I'm also not sold on React Native. It's a step up from web frameworks like Ionic but it's still a lowest-common-denominator experience that can easily be beaten by a real native app. And given that the competition for a spot on the user's home screen is tougher now than ever I don't think you can afford to be lowest common denominator unless the service behind your app is so essential that users will put up with a less than stellar app.
So I think RN is a reasonable option for some kind of business that needs a decent, usable app on both iOS and Android. But if your business is mobile-first then I would still recommend you take the time to do a real native implementation.
It's really odd to read your comment and the parent comment, at least regarding the iOS side of things.
I've gotten my RN app to run at the same performance level (as far as the user is concerned) as my native app and there are definitely some non-trivial animations and gesture responders for the RN version.
It did take some tuning and I had to add a couple artificial delays to wait for animations to finish, but nothing crazy.
No opinion on Android yet, but RN for iOS is definitely not negatively impacting the user experience in my case.
It's not in the store yet, but to give you an idea of the UI complexity level - see Slack and Google Chrome's UI and gestures.
It means that the transitions between RN and Native for most cases are visually indistinguishable to the end user. Of course there are potential differences "under the hood" simply b/c the animations are implemented differently.
It's possible that the OPs ran into certain issues with specific cases or weren't able to figure out a workaround even though solutions exist, but the result of their comments unintentionally create FUD.
I'll give an example. One of the most popular libraries for messenger apps to use in RN is GiftedMessenger, but it's actually doing the keyboard wrong, so people may get the misconception that ReactNative doesn't support smooth keyboard animations, which is not true. There are a lot of examples like this, not meaning to pick on anything specific.
I will say that the library ecosystem around RN doesn't feel mature yet, kind of like Node.js in the early days, but React-Native itself is not the issue.
Indistinguishable as far as the user is concerned. I'm guessing most users won't ascribe any battery or CPU degradation to a new app, unless they spend half their day on it.
I have very high doubts that they are "visually indistinguishable". Did you time animations exactly? Did you give the animations the same easing function exactly? Also, what happens when iOS 10 comes, and tweaks these values?
No, the user always feels. Even the grandmas and grandpas, that are far away from technology as possible, feel it in the back of their mind. They know something is "off".
Also, adding "artificial delays" to wait for animation end is a sign of a terrible terrible animation system.
> I have very high doubts that they are "visually indistinguishable"
It's hard to describe without showing you in person and asking you to tell me which app is a RN app vs native, but it's actually the case... There's pretty granular control over the easing functions and the default ones do match the iOS curves.
I was a designer before being an engineer, and I was immersed in Obj-C for 4 years before trying React Native. On the well-implemented React Native apps, it really truly is indistinguishable.
Perhaps the difference here is between a RN app written by someone with only a web/js background and a RN app written by someone who has a deeper understanding of the system beneath RN's abstraction layer?
That's not what I meant. It's got the right easing curves out of the box for most transitions. Sorry for the confusion. But there are definitely some things that take a little more digging around as the documentation doesn't exactly offer "best practice" recommendations in all cases.
It does help to read obj-c code in the RN repo to see what's possible and how things work so you use the right javascript parameters, but you don't normally have to do additional obj-c coding most of the time.
Yea, I'm offering a bit of a different point than you.
You're saying that that it is easy to use RN to build an app that is indistinguishable from an app written in obj-c
I'm offering the possibility that your 4 years of obj-c experience trained you to make intuitive judgements about how things should be done and that this intuition is mostly correct. Also that a person without that experience wouldn't make those same judgements and might default to doing things in a lower-fidelity way.
This suggestion is offered without experience using either react native, obj-c, or swift. So coming from ignorance, I might be entirely wrong.
>No, the user always feels. Even the grandmas and grandpas, that are far away from technology as possible, feel it in the back of their mind. They know something is "off".
If it's below a certain ms (milliseconds) threshold the user does not "feel". There's nothing more or less to it besides simple physiology.
It's not a lowest common denominator. You can have a different UI on Android and iOS, and share whatever code can be shared.
Additionally I like the React lifecycle better than Android's finite state machine where you always have to know where in the cycle you are, what's next and what's before, etc.
It's using native UI elements but they're still wrapped in a higher level abstraction, which obscures details and nuances of the UI stack on each platform. You're still giving up precision and control in exchange for a cross-platform abstraction, just not as much.
Well, you can use a common abstraction for elements that make sense on both platforms and have platform-specific components that does exactly what you want and that you will use only in one version.
If the wrapper doesn't do what you want, you can still write that portion in native or write your own wrapper with an underlying implementation that does exactly what you want.
Are you being serious? Have you seen facebook groups or discord? Both are amazing apps. Facebook groups is better than most native apps I see.
Just because the tool isn't the right tool for your job means nothing about how good it is. graph databases aren't the best at searching large singular tables, but that doesn't make them useless.
I could be wrong, but I don't think Discord uses React Native; I think it just uses Cordova or one of the web hybrid platforms. And it definitely shows: performance is less than stellar, and it definitely doesn't feel like a native app to me (on Android, at least).
Edit: It looks like the iOS version is built using React Native, but the Android one is not. I can't comment on the iOS version as I've never used it.
Do you have a source for this? Everything I'm finding suggests that the Android app is not native, and last time I used it (a couple months ago), it definitely didn't feel native, and performance was sub-par.
You know. You always know.
Do you not know Atom is web based? You always feel it, no matter how good it is. It's never as good as native. It's just a deep down, "something is not right" or "something is not 100% the same" feel that you always have, be it on mobile or desktop.
You don't always know. Instagram uses webviews everywhere, I'd bet 99% of people would never guess that. I read somewhere that even the iOS messages app uses webviews, though I haven't found a citation for it.
It's completely true that "you always know" at some level when you're dealing with a web-based "native-look" mobile app. That's why facebook ditched their effort to build their mobile apps in HTML5 a few years ago. That's why they built React Native, which, many people seem to fail to grasp, is not a web based stack. Javascript is not what's doing the hard work in a React Native app -- you can view it as a native set of UI components which are merely assembled and controlled by javascript. This is the point.
well, I've had that feeling with something is not right on native apps. Anyway you keep saying you, do you mean you or do you mean me? Because if you mean me the problem is I think I don't necessarily notice all the time, or I notice other problems. I'm guessing it's the same for other people.
Eh, Slack works pretty well, and I don't know if I would have known. It may depend on the app function/domain, a chat app is maybe one you expect to look like 'the web' in the first place. Instagram too maybe, maybe apps with network connectivity/communication as their core will deal better with being implemented on web-tech based platforms.
There are two non-native apps I use frequently on OS X, which are both rather jarring and tawdry in their deviations from the platform norms.
Slack is the second-worst offender. It feels less native than many websites do.
The other is Rubymine, which on Mac now includes its own embedded Java runtime. It's significantly worse, but they are neighbors on the spectrum. Slack suffers less because it's mostly just chat, which can be done even in a Terminal window (e.g., IRC) without suffering that badly. But when you try to do anything in Slack other than just chat, the non-native kludge factor quickly becomes obvious and irritating.
The point of React Native isn't to create a delightful product experience.
The point is to create the equivalent experience of a native app with a delightful development and organizational experience.
- Instead of having separate teams develop your iOS, Android, and now OS X apps, one product team can make all three and share the majority of the code.
- Instead of a slow frustrating compile cycle you get live reloading.
I could write a Lovecraftian short story about my experience with React Native. Trying to turn a web app into a delightful React Native app nearly sank me into depression & burnout.
[Edited to clarify that of course I can't blame my mental health problems on a UI framework... but I keep the formulation for the sake of sympathy with anyone else who may feel less than "delightful."]
It was pretty cool at first, after a couple of months of trying to get the thing working decently without crashing, lagging, or just sucking, I gave up on the whole project.
I don't doubt that many people use React Native with delight. But there are aspects of it that are likely to cause frustration. It's a mashup of two incommensurable platforms, and in the gap between them there is horror.
You understand that in realistic professional scenarios it's rather the boss (especially a technical boss), that will dictate that it's ok to have something easier to develop with.
Poor user experience doesn't mean much if you are not on the market soon enough.
Which should be obvious on HN, and it's a point PG himself has iterated several times...
There are a lot of devs on here with little to no real world experience or not enough to make sound judgements as far as I can tell anyway. I'm not sure if it's better to enlighten them or to ignore them since they are the sort of people that are willing to post their baseless opinions for the world to see.
TBH this kind of solution is more often pushed by bosses than devs.
Any management person will throw in a "you've done X on this platform, why don't you try to reuse most of your stuff on this other platform ?", just in case it's actually doable.
In my experience as a mobile app freelancer, many prospective clients(=bosses) insist on portable/JavaScript frameworks for new projects. I guess it is because native iOS/Android programmers are expensive, and a single JavaScript programmer rotating between platforms with a shared codebase is both cheaper and easier to manage than two or more native app programmers (at least in theory).
I feel bad for you if you've met such bosses. As one, and as someone who has worked under several, I've never once experienced a boss knowing or saying such things. I've only ever seen it come from developers.
Edit: Just to clarify, there may be instances where a mgmt type has asked if X on platform Y can be reused on platform Z easily. I've never seen it go beyond the ask.
React Native doesn't deliver a poor user experience though. It's not the right choice for every project, but in most cases users won't be able to discern between RN and native.
On iOS maybe, but not on Android. You have to reimplement a lot of the things you get for free when developing native apps yourself. Most animations etc, you all have to add it yourself. Problem with that is that the React Native team has some decent iOS stuff, but for Android it's all sorely lacking.
Besides Facebook's Ad Manager (which barely cuts it) I haven't seen any React Native app on Android that didn't feel horrible (and not like an Android app).
Does the Facebook app use React "Native'? Because that app is a horrible power hog and vastly glitchy and buggy. That is a poor user experience compared to what a well written native iOS app could deliver. Users might not know its a poor experience because that can't compare to how fast and responsive the app would be if it were actually written in Swift.
There are people in this world that think Olive Garden is great Italian food. There are people in this world that think React "Native' is a good user experience.
Why does Facebook absolutely insist on avoiding writing actual native apps? As in Swift for example. It seems like they are almost allergic to actual native and instead focus on this inferior cross platform stuff.
In 'most cases' users won't know the difference? sure they will; they'll notice that the app they're using sucks more than other apps on their phone. They'll tolerate the glichiness, the occasional blank data screen during a load because they care about the content more than the terrible experience. All because a developer or the CTO somehow thinks "it works well enough" is the same as "let's really give our users the best possible experience." I am amazed that Facebook has thousands of employees but can't be bothered to write a single line of code in Swift. They've been insisting on this stubborn course of action since the beginning of their mobile experience. Does Zuckerberg just hate Obj C or Swift? Why are they making the mobile experience into the lowest common denominator? Why does their Facebook app feel like some cheap PhoneGap experiment? My Facebook app on iOS performs exactly the same as it does on a years-old Android phone.. And that's ridiculous. I have superior hardware and yet I get to run an inferior app because JavaScript? It's like socialism for apps: make everyone equally miserable.
The simple fact is this: I hate cross platform systems because they end up averaging the quantity of the mobile experience with capabilities being reduced to support the lowest common denominator. If I want my apps to run as terrible as many do on Android, I will use an Android. It's lazy development. It's a means for the JavaScript crowd to avoid leaning Swift (or Java) so they can provide middling to bad mobile apps rather than actually building the absolute highest quality product they could build.
Even Facebook does it! I feel like the React Native ecosystem is doing more to reduce the quality of the mobile app experience than anything else. Apps are being turned into these average pieces of crap with only the UI being slightly different. Does anyone have any performance benchmarks on a React "Native" compared to Swift? Any data at all? Or are we just so excited to write apps in React that we fail to care? If we care about 'cross platform' development -- we can already do that; it's called 'the web.' Let stop foisting inferior mobile apps on people just because we can.
Interesting - is there an intention to rewrite the whole thing gradually and move away from native? Any reason it's not listed on the React Native site?
I left Facebook almost a year ago so I can't speak about Today.
But back then internal adoption of React Native was definitely accelerating rapidly and it was solving very real organizational and developer experience problems. The original motivation of the project internally was to solve developer experience pains, just like React but for mobile.
- With such a large app (Facebook), the compile cycle was becoming quite slow. RN has no compile cycle.
- You've got 3 teams (web, iOS, Android) per product (eg. Events, Groups, etc) and they don't really communicate or share any product code despite building effectively the same thing.
Take the Mobile Ads Manager app: Now one team (of web engineers) can ship an app on iOS and Android, while sharing 83% of the code between each app, in half the time the project had budgeted for just the iOS pure native app. Not to mention the team constantly loved their jobs because they didn't have to wait 5 minutes for the damn thing to compile every time they made a change.
JavaScript is faster in most cases than Objective-C.
(I'm not going to dispute that cross-platform toolkits can have less native fidelity than compared to coding to the native toolkit can. I just don't like the Objective-C vs. JavaScript performance myth.)
But is this even a debate? Wouldn't you expect a compiled, manual memory managed, language to be faster than an interpreted language with garbage collection?
That's an interesting benchmark, and I'd need to dive into the details to see what is going on. Perhaps there is some sort of JIT slow path. I would not expect method-heavy Objective-C to beat JavaScript. In general:
> But is this even a debate? Wouldn't you expect a compiled, manual memory managed, language to be faster than an interpreted language with garbage collection?
Objective-C is not compiled in terms of method dispatch, nor it is manually memory managed. Instead, all method dispatch happens through essentially interned string lookup at runtime, backed by a cache. Objective-C also has a slow garbage collector--atomic reference counting for all objects. (Hans Boehm has some well-known numbers showing how slow this is compared to any tracing GC, much less a good generational tracing GC like all non-Safari browsers have.)
The method lookup issue has massive consequences for optimization. Because JavaScript has a JIT, polymorphic inline caching is feasible, whereas in Objective-C it is not. It's been well known in Smalltalk research since the '80s that inline caching is essentially the only way to make dynamic method lookup acceptably fast. Moreover, JavaScript has the advantage of speculative optimization: when a particular method target has been observed, the JIT can perform speculative inlining and recompile the function. Inlining is key to all sorts of optimizations, because it converts intraprocedural optimizations to interprocedural optimizations. It can easily make 2x-10x of a difference or more in performance. This route is completely closed off to Objective-C (unless the programmer manually does imp caching or whatnot), because the compiler cannot see through method lookups.
Apple engineers know this, which is why Swift backed off to a more C++-like model for vtable dispatch and has aggressive devirtualization optimizations built on top of this model implemented in swiftc. This effort effectively makes iOS's native language catch up to what JavaScript JITs can already do through speculation.
Thanks for the detailed response, to summarize it sounds like your position is that:
1. Objective-C's compile time memory management is actually slower than JavaScript's garbage collection.
2. The performance consequences of Objective-C message sending are greater than JavaScript's JIT compilation. And furthermore, that JIT compilation is actually an advantage due to the other optimization techniques it enables.
I'd like to see a more direct comparison with benchmarks, but I can see where you're coming from.
Right. Note that this advantage pretty much goes away with Swift. Swift is very smartly designed to fix the exact problems that Apple was hitting with Objective-C performance.
I realized another issue, too: I don't think it's possible to perform scalar replacement of aggregates on Objective-C objects at all, whereas JavaScript engines are now starting to be able to escape analyze and SROA JS values. SROA is another critical optimization because it converts memory into SSA values, where instcombine and other optimizations can work on them. Again, Swift fixes this with SIL-level SROA.
I see, good point, but then I'd expect the cost of JIT compilation would still have a performance cost? As opposed to Objective-C being compiled before distribution to the client?
Source please, because unless you have anything to back this up, your claim can only be considered grade-A FUD.
Sometimes I feel like using JavaScript too much transports people to some kind of imaginary JavaScript fairy land full of rainbows and unicorns. I read the craziest things about JavaScript development even though I can't comprehend why so many people believe it has any redeeming positive qualities over other languages, besides ubiquity.
See my reply to the sibling comment for the explanation. There haven't been enough cross-language benchmarks here to say definitively, but as a compiler developer I can tell you the method lookup issue is really fundamental and in fact is most of the reason for Swift's (eventual) performance advantage over Objective-C.
I've read your explanation, but I'm not convinced they support your assumptions (which, barring any benchmarks that make them factual, is what I consider them to be).
I'm aware of the dynamic dispatch overhead of Objective-C, but first of all it's my understanding that Apple's Objective-C runtime & compiler perform all kinds of smart tricks to reduce the overhead to a minimum (caching selector lookups and such), and second, because Objective-C does not require you to use dynamic dispatch if performance is a concern. No one is preventing you from doing plain-old C-style functions for performance criticial sections.
I also don't buy the 'ARC is slower than GC' argument. ARC reference counting on 64 bit iOS, as implemented using tagged pointers, has almost zero overhead for typical workloads. Only if you would write some kind of computational kernel that operates on NSValue or whatever (which is a dumb idea in any scenario, about as dumb as writing such a thing in JavaScript) you would ever even see the difference between not having any memory management at all. Just like your other performance claims: without data, there is nothing that backs up your statement that ARC is slower than GC for typical workloads. Hans Bohm is not the most objective source for such benchmarks by the way.
Apart from that you seem to spend an awful lot of effort explaining the things that would make Objective-C slower than JIT'ed JavaScript, while completely disregarding the overhead all this JIT'ting, dynamic typing, etc has, and the fact that in JavaScript you basically have no way to optimize your code for cache friendliness or whatnot.
You may be a compiler developer, but based on your comments I'm highly doubtful you are aware of how much optimization already went into Apple's compilers, which greatly reduce the overhead of dynamic dispatch and ARC.
> second, because Objective-C does not require you to use dynamic dispatch if performance is a concern. No one is preventing you from doing plain-old C-style functions for performance criticial sections.
That's just writing C, not Objective-C. But if we're going to go there, then neither does JavaScript. You can even use a C compiler if you like (Web Assembly/asm.js).
> ARC reference counting on 64 bit iOS, as implemented using tagged pointers, has almost zero overhead for typical workloads.
No, it doesn't. I can guarantee it. The throughput is small in relative terms, I'm sure, but the throughput would be smaller if Objective-C used a good generational tracing GC.
(This is not to say Apple is wrong to use reference counting. Latency matters too.)
> Just like your other performance claims: without data, there is nothing that backs up your statement that ARC is slower than GC for typical workloads. Hans Boehm is not the most objective source for such benchmarks by the way.
Anyway, just to name one of the most famous of dozens of academic papers, here's "Down for the Count" backing up these claims: https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-... Figure 9: "Our optimized reference counting very closely matches mark-sweep, while standard reference counting performs 30% worse." (Apple's reference counting does none of the optimizations in "Down for the Count".)
memorymanagement.org (an excellent resource for this stuff, by the way) says "Reference counting is often used because it can be implemented without any support from the language or compiler...However, it would normally be more efficient to use a tracing garbage collector instead." http://www.memorymanagement.org/glossary/r.html#term-referen...
This has been measured again and again and reference counting always loses in throughput.
> You may be a compiler developer, but based on your comments I'm highly doubtful you are aware of how much optimization already went into Apple's compilers, which greatly reduce the overhead of dynamic dispatch and ARC.
I've worked with Apple's compiler technology (clang and LLVM) for years. The method caching in Objective-C is implemented with a hash table lookup. It's like 10 instructions [1] compared to 1 or 2 in C++, which is a 3x-4x difference right there. But the real problem isn't the method caching: it's the lack of devirtualization and inlining, which allows all sorts of other optimizations to kick in.
Apple did things differently in Swift for a reason, you know.
That's again a lot of information showing why Objective-C is not the most efficient language possible for all use cases, but it still does not provide any evidence why JavaScript would be faster. I'm not disputing the individual points you made, but in the context of comparing overall performance of Objective-C vs. JavaScript it doesn't say much at all. It mostly shows Objective-C will always be slower than straight C/C++, nothing about JavaScript performance. I appreciate the thorough reply though.
One thing I do want to make a last comment about is your dismissal of using C/C++ inside Objective-C programs as some kind of bait-and-switch argument. Using C/C++ for performance critical sections is IMO not the same as calling out to native code from something like JavaScript, or writing asm.js or whatever other crutch you could use to escape the performance limitations of a language. As a superset of C, mixing C/C++ with Objective-C is so ingrained in the language you have to consider it a language feature, not a 'breakout feature'. Nobody who cares about performance writes tight loops using NSValue or NSArray, or dispatches millions of messages from code on the critical path of the applications performance (which usually covers less than 10% of your codebase). As an example, I'm currently writing particle systems in Objective-C, but it wouldn't even cross my mind to use anything but straight-C arrays and for loops that operate directly on the data to store and manipulate particles. This is nothing like 'escaping from Objective-C', as all of this is still architecturally embedded transparently inside the rest of the Objective-C code, just using different data types (float * instead of NSArray) and calling conventions (direct data access instead of encapsulation). It's more like using hand-tuned data structures vs STL in C++, than like calling native code or writing ASM.js from Javascript.
I've seen cordova/phonegap being used as a MVP. Then slowly some screens got rewritten in their native platforms, starting with the most critical ones.
All by manager's and client's decision. It was a horrible experience overall.
Exactly. Except, the time to do it is before you decide on a tool, when the company is comparing time to value vs. quality.
Whether or not the experience is great isn't a deal-breaker, it's a factor in the decision making process. For plenty of companies out there, having a less-than-perfect application that they can deploy to many platforms in a month or two with a single or couple of developers is a choice that might get made, when the alternatives are either much longer timetables or many more dollars.
Using a language in which 1 + "1" == "11" instead of one of the best type and null-safe languages to be developed in the past few years is not exactly my idea of a delightful experience, but interface as a pure function of state is a good idea.
So degrade the experience just to make the product team happy? What product team worth a darn would actually be ok with that?
Did we forget the customer somewhere? What ever happened to trying to wow your customers rather than simply tolerating them?
This attitude makes me crazy angry. That one comment just revealed everything that's wrong with many product companies: just give the user a 'good enough' experience. If you aren't striving to create a delightful user experience than you're disrespecting your users. Laziness.
If Steve Jobs had heard you say that, he would have fired you in an instant -- and for good reason. We owe our users a delightful experience, giving them anything less is just unacceptable.
A product team with limited time and money. We'd all love to have best in class apps on every platform, but there's only so many hours in the day, and only so many developers on the team. At some point we have to make tradeoffs, and sometimes the right one is to deliver something imperfect now rather than perfection later.
> So degrade the experience just to make the product team happy?
Which part of "equivalent" did you miss?
You're entirely missing the point. This isn't about product experiences whatsoever. You can ship equivalently delightful experiences in React Native as you can in pure native apps. The point of React Native isn't to make your app more delightful.
The point is to develop it faster, in a more enjoyable manner, and enable one product team to develop for multiple platforms. This is an incredible win organizationally and for developer experience.
> I sympathize with cross-platform development woes (we have this problem too) but I can't say I've ever been impressed with a cross-platform app developed using React Native (or anything else cross-platform).
Do you feel the same way about Xamarin? I'm just curious as I've been considering moving to it. My company has been developing on Ionic the past year or so and it's become quite cumbersome as a platform. Basic apps look alright in Ionic, but is plagued by web view problems, making a non believer in the platform. Xamarin seems to compile better and avoid the web view. I guess I'm just looking for opinions.
Any 3rd party solution will have some issues. Whenever you see mostly positive testimonials, you should be both suspicious and scared, because it means you will be the one to find those issues in production, and you won't find any help on the internet.
That was a long time the case for Xamarin, but if you look at their customer forums, reddit, stackoverflow etc you will find the negatives too nowadays.
I am not interested in .NET, so I would not personally use Xamarin anyway, but I know that with Qt for instance you have to be careful with mobile UIs - it's best used for custom stuff and not native-looking apps.
I use Xamarin regularly, and it's true the primary downside is frequent bugs and regressions along the entire toolchain, and in the Xamarin wrappers of native APIs. That said, it's improved by leaps and bounds in since last Summer. It's gone from "I'm about to dump this platform any day now" to "minor nuisance", and most of the time you can just get on with your work.
For the record, I use Xamarin "classic" and not forms, and my comment was in reference to that. Given the age of X.Forms, what you say sounds par for the course.
If you are comfortable with C++, a good option is to place as much as possible in C++ and then use Objective-C++, JNI and C++/CX to integrate with the native UIs from iOS, Android and WP.
Although Android is going to give you most headaches of those three, as the NDK is pretty anemic and JNI is not that friendly, but with help of JUCE and Djinni the pain isn't that hard.
The advantage is that you get to write a portable application without extra third party layers and have full support of the available SDK tooling for debugging issues.
I have a question. How would you know when you're using an iOS or Android app developed with React Native? Is it possible that you're only unimpressed when you actually notice something is off?
Because, in my experience, React Native is the first framework that actually feels native, and often results in apps that behave identically to their native counterparts. One of the big reasons for this is that it actually is using native components in most places.
Facebook's philosophy isn't that you should write platform-agnostic components and use them everywhere. They actually encourage using platform features wherever possible, but at the same time the way you write the components doesn't change across platforms -- "learn once, write anywhere."
I totaly agree with you. What web-devs often forget is that native (mobile apps) have a very different runtime environments, things come and go (onCreate, onDestroy). Memory gets destroyed and reused. You need to think about background processes, multithreading. App startup is of upmost important. (starting a web page takes a lot of time, people every noticed that ios-chrome only has one page in memory at a single point ?). Its just a different mindset. The webbrowser is an abstraction on top of UI toolkits, with a very dynamic rendering engine, and simplified execution environment.
Once you have a a hammer (javascript), it doesnt mean you should apply it everywhere.
It's not clear from your comment whether you're familiar with React Native architecture or not. A React Native app works by using JS/React as the "brains" of the app (http services, state, smart components) and runs this in a separate thread to a 100% native portion of the app that uses uses platform specific native ui controls. Animation performance is pretty good because of this multithreaded approach. So in this way your JS app brain can be portable across platforms, while the nitty gritty view layer may shift to accommodate the capabilities of the native components you work with on each platform.
React Native (RN) is not for all apps, it has its uses if what your app does is mainly text delivery, example news app. One of the more complicated app that uses React Native is Discord for iOS (http://stackoverflow.com/questions/35309471/is-discord-mobil...), a Slack like chat app. That was then but I'm not sure the latest version is still RN heavy. You can actually build a native iOS app, and then add RN as part of your app. The tweet by Discord that said they are using RN is deleted.
Some reservations to choose RN: RN is possible due to the JavaScriptCore framework build by Apple. It is the bridge between JavaScript code and Cocoa API. Apple designed this so that you can use JavaScript as scripting language for Cocoa. The popular Sketch for OS X is using the precise JavaScriptCore to power its plug-in scripting feature. I guess Apple never have thought JavaScriptCore could be used the way RN does. Choosing RN means your app is relying on Apple's decision on JavaScriptCore API. Someone please enlighten me if RN is still possible or not if Apple remove JavaScriptCore.
JavaScriptCore opens up the Cocoa API, but does not give you a JavaScript ready API. So RN has to implement the bridge internally. So when iOS 10 is released, you will have some lag waiting for new features or changes to be supported by RN. I guess this is common problem to all cross-platform framework.
In order to implement RN for Android, Facebook implements its own JavaScripCore for Android. I have no Android experience, but what I read is RN app for Android is not performing as natively as its iOS counterpart.
If your business rely on all Apple's platform, then choosing RN does not help as there is no RN for watchOS and tvOS.
React Native will make app manager and web-dev team happy, but not those who treasure the last mile UX experiences. But is could also be useful for those startups creating their first MVP. Get app release fast and then change to native codes when you got the traction. Is this good or bad startup advice?
It will be a different ballgame if Facebook announce they are moving to use 100% React Native for Facebook for iOS app.
I work at discord. The app is still react native. We use component kit for chat messages view though. But this was because early react native when we built it couldn't do what we wanted to. May switch to full RN soon.
I agree that sync and offline storage is hard to get right. We developed a whole general-purpose platform to do exactly this, in a way that also supports multiple users, decentralized publishing, offline storage, synchronizing messages, optimistic updates etc.
And unlike Firebase, Parse et al it is based on posting messages to streams that people join, rather than diffing objects. This way you can have a history of changes, and just focus on implementing the front end handlers for the changes.
I can imagine there not being great internet while you're building a hospital, but you know MRI rooms aren't that large, right? If you need to leave the Faraday cage, you just walk 10 feet.
Your customers are probably downloading GBs of data in advance because their reception/speeds outside the MRI room aren't sufficient.
I was making a glib comment to sum up the entirety of the issue. I actually typed up the full pedantic explanation, then deleted it. I told myself it was superfluous prose. Guess I was wrong!
Yes, the problem is that connectivity is often absent, poor, or slow combined with the fact that the app is useless without the entire dataset available. And you're collaborating with a team, so you have 10s-1000s of disconnected clients.
> I'd rather write my sync and offline storage system in JS and share that across platforms while leaving the entire view layer as native code.
Of course, who wouldn't? The problem is resources. The alternative to not horrible/bad (React Native) for many devs is either horrible/bad (Ionic etc) or nothing.
I mentioned "reactive programming" because React is typically used in conjunction with reactive programming. Mentioning something related to something else is pretty standard communication.
To elaborate on why I made my initial comment...
Reactive programming is a paradigm, it has advantages (and disadvantages). Paradigms are higher level than implementations (libraries), or even a programming languages. When people start a new project they come up with requirements; continuous integration, easily testable etc. These requirements are mostly satisfied by a paradigm, not a implementation, nor even a programming language.
If you've decided you like React, you probably like it for various reasons, most of which are probably because you're following the reactive programming paradigm - and perhaps because you like JavaScript. Nonetheless, when you start a new project (e.g. you've decided you want a native Mac app) it's your job as a competent software developer to determine the best fit for the project. This means you should really do your best to make a well rounded assessment of the situation - that means being educated about the subject matter. My comment merely agreed with the parent comment's description of the disadvantages of a (near) pure JS solution, and proposed ReactiveCocoa as an alternative that provides many of the advantages and familiarities of React, minus the disadvantages the parent post pointed out. Of course, you can't use JS to write your app - that may well be deemed by your team as a sufficient enough disadvantage to avoid ReactiveCocoa as a solution.
React has very little to do with reactive programming.
It definitely has similarities, but in React you do not map the dataflow in the same way you would in reactive programming. Only the flow of data through components could be considered reactive.
The real dataflow in reactive programming which could be considered the 'state', is not managed by React at all. You could use Redux for that, but having a datastore with reducers which modify state, and actions which trigger reducers is not something I would consider reactive.
Funny enough we are moving to a flux-style model for our view layer and using RAC signals for async stuff. The syncing and database logic is in a separate library that the main app treats as its official "API". That makes most of the interactions akin to Async Action Creators.
Here's a bit about my experience with React Native.
I've been using React Native on iOS in production since last November for http://townske.com/app,
Over that period, I did hit some performance issues, but the vast majority of those were implementation flaws (i.e. my fault), not framework flaws. Real user feedback has been overwhelmingly positive, including being featured in the app store multiple times.
I just launched another app for iOS and Android last weekend (https://curbitapp.com) that was built with React Native in a few weeks, and shares about 80% of the codebase. I haven't spent any time optimising these apps for performance, other than following standard react best practices and see sufficient performance on both iOS and Android.
For someone who has a web background, React Native is a no brainer. 60fps native UI is generally attainable, you can use the exact same tooling (good dev tools, hot reloading), and you have the ability to pick up a large chunk of your code and put it on Android, or web, or now potentially OSX.
I have to admit it's better than most web apps I've seen. However...
After downloading Townske I get hit by three modal dialogs one after the other:
* notifications
* location access
* query about installing an update, even though I've just downloaded the app. If I select install, nothing happens, no progress bar or anything.
Developing for a platform is more than having native-looking widgets, it also means taking conventions and user expectations into consideration.
I am referring to things like the tab bar which has a back button, having a next button and also page swiping in the intro, not throwing popus at the customer, etc.
The update message I've not generally seen before, but nearly every app I've used asks for at least the first two individually. The modals to allow notifications, location access, and other granular permissions on iOS is a good-practice pattern.
Agreed, we probably need to work on offsetting those prompts til after onboarding, and preparing the user. An implementation issue though, not a react native one.
The two permissions modals are required by iOS to access those features, and RN definitely has the ability to defer when those are shown.
The update prompt is actually from http://microsoft.github.io/code-push/ which allows us to push minor updates directly to the app without going via the app store. Say goodbye to 2 week time cycles. A newer release of Code Push actually doesn't prompt the user at all, and can download an update during use and load it when the app goes inactive.
Good onboarding will however prepare the user for the appearance of those dialogs, or ideally only present them when the user performs an action that requires access to e.g. location services or push messages.
I am pretty sure these things can be obtained, and will be easier to achieve as it matures.
As well as devs following good practice with modal dialogues.
I used Titanium to build a cross-platform app, and once I understood what it is writing with my JS, I could ensure native/performant UI elements and animations were being rendered.
> I did hit some performance issues, but the vast majority of those were implementation flaws (i.e. my fault), not framework flaws.
I can't agree enough. Apps built with cross platform frameworks like Cordova and React Native will obviously be slower than their native counterparts, but I've seen the framework blamed for bad implementations many times. Once, we tracked down a horribly slow Cordova app down to too many localStorage accesses (solution: indexedDB or SQLite).
Townske looks very polished, thanks for sharing your experience. Would love to hear more about the issues you faced and the pain points.
I especially enjoyed the subtle transitions and animations. I also saw a prompt to update immediately after downloading the app, which was strange. If you're updating the layout and such directly, then that's actually pretty cool. Is that the case?
I especially like that it gave me the option to register later (also the reason why I didn't get past Curbit intro since registration was mandatory). I was able to dive right in.
It sounds like an IP issue waiting to happen if you are admitting here to sharing 80% of the codebase from Townske (employer) into your Curbit (your personal app).
As someone who quite likes Qt, why should I prefer this over Qt5+QML? This whole React Native thing just feels like "let's reinvent Qt but slower and much less mature".
Note: I really don't mean this in an inflammatory way; it just feels like people are rediscovering the cool stuff about Qt and reimplementing it but worse.
Have you drunk the react kool-aid for the browser yet? I have, and I was initially skeptical. Performance can be plenty fast but more importantly, your UI and your application as a whole is more testable, reliable, and easier to reason about if you use React (and importantly, the functional mindset that the React ecosystem comes with). I've made many desktop UIs without this sort of thing and they can be fiddly little bastards to get all of the interactions right, but React makes it effortless and reliable.
I'd love to see React and Qt talking to each other.
QML on Qt is also a declarative and reactive technology, it behaves very similarly to React for the browser, but for native widgets. I think that is what the question is about, and I'm curious too... how does React differ? Qt's QML automatically updates UI elements based on state changes. I use React for web programming and they seem like similar concepts, so I'd be curious for anyone to shed light on their differences. Qt falls more into the "reactive" domain, whereas, name aside, React is not a reactive tool, technically, but the use-case is similar for both, no?
I would disagree with this. I haven't worked with QML, but I have worked with WPF which also supports two-way data bindings in a manner that I would guess is similar to Qt. The major difference between the approaches is that React embodies the functional approach. By describing your UI as a pure* function of your application state, you get a lot of important benefits.
Several academic papers on functional reactive programming specifically discuss QML implementation, so I suspect a comparison to WPF is superficial. You may want to take a look at QML before dismissing it. I've seen react developers who have used QML say that the experience is very similar.
I used React to write an in-browser REPL with live data browsing for a programming language that I was writing and it was admittedly quite nice. It's what reminded me a bit of Qt/QML actually. But that is my only experience with React.
I have my fair share of Haskell experience so I get the benefits of statelessness. But I don't necessarily think it's a silver bullet for UI.
"App startup". I.e. loading screen after the webpage was supposedly loaded. Same for transition between states (compared to how regular web pages behave).
React is actually fairly unique among JS view libraries in allowing you to fully render the site on the server-side. If a site doesn't do this then it's a choice they have made.
Qt+QML is more like Angular. You mock up templates and bind functionality to a view_model. This gets ugly when you try to do anything complex; your template has to accommodate all possibilities and eventually looks more like a huge laundry list than a template.
With React you don't have a template. Every change generates a new virtual-HTML page, and then a diffing algorithm figures out the cheapest way to update your existing HTML with the changes. That makes things far simpler--your renderers are just HTML-generating functions, not some magical view-view_model thing that has its own syntax and workarounds for its limitations. UI is more testable because you can verify the actual HTML output, not just view_model state.
Would love to see something similar to React on other GUI platforms as well.
I don't have experience with Angular, and you haven't specified whether you're talking about Qt or Angular, so I will make some clarifications.
In QML one has QML components, which are JSON syntaxed files that can include other components and Javascript code. A component can be anything from a UI widget to a a camera object that can be used to take pictures, etc.
QML encourages model-view programming which is a proven pattern used in the best UI frameworks on pretty much every platform. Nothing magical or limiting about it.
This is the opposite of the case. Because QML is declarative, it forces the framework to be completely antifunctional. The view_model has to be mutable, so GUI updates are all about mutation. In React, the renderers are simply pure functions that take an immutable state input and spit out a view. No mutation, pure functionality that you can test.
I agree in practice QML apps are typically less functional than React apps, but QML-the-language (without connecting JS functions) is functional, like CSS.
You're conflating declarative and functional. It's declarative, yes. But it's not functional because there are no functions. No inputs, no outputs. It's not a programming language. It's just a config file.
I think functional and declarative are widely regarded as closely related paradigms, certainly you might call a FP program a declarative program. After all a declaration of a value as being derived from some inputs is very similar in concept to an immutable binding in a function or the concepts from functional reactive programming.
Yes, I'd absolutely agree that pure functions are declarative, so "functional" is a subset of "declarative".
But it's a strict subset: config files are declarative without being functional. Raw data is declarative without being functional. One could argue that imperative functions are declarative too: "This C code is the declaration of what steps to execute in what order". So the definition of declarative can be a little fuzzy around the edges, but pure functions are most certainly declarative.
Anyway, QML is most certainly declarative, however it's still not functional because there's no functions.
functional programming is about immutability and higher order functions as a base kit for building abstractions, not sure what definition you are using but it's not the one that is useful when talking about React
Maybe it's just me, but as an C++, Objective-C and Swift programmer, React Native doesn't really appeal to me that much.
At least on the iOS and Mac, I don't really want to give up on Swift in favor of Javascript.
I like React on the web. In my view, conceptually it's the most interesting framework out there and that's saying a lot, given the jungle of JS frameworks populating the web.
But I also like UIKit and the other native frameworks, now that I've spent so much time learning to use them right.
I'll give it a try anyway, I'm sure there's something to like about it and probably something to learn too..
As a Java, Kotlin & Rust programmer, React Native does not appeal to me either.
The main appeal seems to be that web devs can continue to use js for most of their work, it does not really appeal to a mobile dev..
Web developers should remain on the web, or put enough time to learn new technologies. For a good developer, moving to another language and framework is not really that difficult. Just means to a goal. If, however, the mere thought of learning Swift or Java scares the living hell out of a "developer", then that "developer" is better left outside of my ecosystem as a mobile apps user.
From what I gather this is more often a business decision than an individual developer's decision.
When a product needs to go mobile for the first time on two platforms you have to make a business decision:
1) You can grow the team to tackle both platforms in parallel.
2) You can have the team do it one platform at a time.
3) You can have the team do it one time.
Every option has big trade offs in either cost, time or user experience. There's somewhat of a gradient there as well in terms of code reuse giving the options avaiable right now.
React Native sits somewhere between 2 and 3.
It's really a matter of context for the business. How much time you have? Resources? What does your target user expect?
For a lot of B2B companies, there's just not enough value added to choose between 1 and 2 since you either take more cost or more time to market and your user just needs the feature not the best possible experience.
For a lot of B2C, your product may already be born mobile and you need the best possible experience to compete.
The thing about React Native vs other frameworks is that it is cross platform. There aren't many proper cross platform frameworks which allow for 1 app, to be web-based and have native siblings in 1 codebase.
I'm not scared of Swift or Java, But I am frigthened of their ux. Even big apps like eclipse put me off, due to their bloat.
Also frameworks like QT don't offer the same ease of development.
Remember React-Native is currently on version 0.22, and over a year old. IMO it currently offers much better ux than TK/Swing/Qt/...
I'm in love with React Native. We're delivering the Android & iOS application we've been working on for the last three months this week, and it's been a phenomenal experience. Far more stable, and far more powerful than I expected going in to it; combined with Redux (though react-redux needed npm 3 and some tweaks to get it working due to name collisions under the packager) we built out a real cross platform app faster than I ever though possible.
Applying that to native desktop application development has me so excited its not even funny!
If you implemented your "business logic" in, say, Redux or some other Flux implementation then you could share a massive amount of code between the two; however because React Native acts as a fork of React, having both in the same project (same package.json) will run into issues as far as I'm aware; so you could share code, but not have a single project that compiles to both, at this point in time
EDIT: See below, this is no longer the case as of the latest versions?
As of one or two releases ago React Native no longer ships with a forked version of React, and just depends on the upstream "React" library like any other project. So it's compatible with most things in the ecosystem now that don't depend on a DOM being available.
Oh really? What version is that at, we've been upgrading at every release, but I could've sworn we still ran into issues even with npm v3 with external libraries installing React when installed, rather than relying on the upstream that should already exist. Might need to upgrade again!
Edited to add:
We're running v0.21.0 here, and I know there were still issues with certain libraries causing conflicts even running up to v0.20.0 -- we've not had any issues since upgrading mind you.
You could use it in combination with react-native-web [1], which basically allows you to use same view layer code for native and web. Using this inside electron should be OK...
It's a "parent portal" for an existing child care centre management service. It allows the guardians to manage their child's bookings, communicate with (and from) the CCC, pay their bills and other features; so it's not crazy fancy, but does use a large amount of React Native's features!
That is a great use case. I have used React for administration and management services at my office as well. Being able to get the app working across so many platforms so quickly is a huge selling point for the library.
The biggest difference is that for real cross-platform support you need to be careful which APIs you choose to use; some have cross platform equivalents, but not all. In addition, we didn't want to just render the iOS UI on Android, so we replaced some of the components, about 10% or so to get a more native Android feel. Because the iOS version is more mature, we started with it and migrated it to Android a few weeks ago.
The biggest thing, and this is not even React Native specific, is to ensure that the components are implemented with flexbox correctly and the layout adapts properly between screen sizes. Because Android has such a disparate set of screen sizes and devices (and iOS lets you "cheat" a bit because the set is so much smaller, letting you hardcode sizes/layout that you shouldn't), some discipline is needed.
Lastly, your top-level container component will likely use padding on iOS to not overlap the status bar, don't forget to remove that on Android, because it renders it the way you'd expect: below the status bar, not underneath!
Depends highly on your use case. For e.g. a forum reader/ news app, absolutely. For a game/something that involved a lot of robust animation and fancy graphics/transitions, not really.
We've been working on a banking app, and most of the rough edges we run into are not dealbreaking (limited transition types, weak animation support, etc) and can be worked around either with native patches or are expected to be solved as the platform matures
Android: Not as mature, but with some careful choice of libraries (effectively eschewing native libraries and sticking to Javascript implementations where possible) we had basically no issues.
Tooling for Android isn't as nice as iOS in my opinion (specifically the simulator even with Intel's fancy extensions sucked compare to the iOS simulator), but because we lived mainly in Javascript-land this was rarely an issue. Debugged and tested on real Android devices (this is one thing that worked really nicely with little effort).
This is a real production app for a software-as-a-service product, though it's getting a small controlled rollout to begin with. I'll be writing up a blog post or two on our experience, so keep an eye out on my website over the next few weeks/month or two -- I'm not expecting any issues though, as our beta testing has gone brilliantly :)
The Android simulator has always sucked, so that's not a React issue. If you're going to be working on something for Android, you should have a device.
Those are not quite the same however. Those actually render the HTML / CSS / JavaScript in an web view of sorts but React Native actually uses the real, native components under the hood.
React is an abstraction on top of the underlying APIs (in the case of ReactDOM that's the JS API for the DOM, in the case of React Native that's JS wrappers around the native APIs). Cordova and Electron (and nwjs) are just ways to bundle apps running in a stripped down browser rendering HTML and CSS.
I'm a bit confused by this. I thought the entire point of making things "native" was that the app would feel like it belongs on the platform. Native interfaces have certain details that might not be immediately noticeable, but that massively improve the experience.
This... does not. The screenshots look like webapps that try hard to look native, despite actually being native.
The text in the top-left textbox in the first and second screenshots looks weird, because its baseline is too high. The box around it in the second screenshot has weird corners, etc.
Now, I'm not an OSX user, but with all the talk about OSX having the most polished interface, I highly doubt weird things like this are common.
Good point, thank you. Some things look in that weird way only because my (unfinished) implementation. You could use the exact same control as you would use in vanilla Cocoa app, you just need to write a correct wrapper (ViewManager). Most of the current controls are ported from iOS, I certainly should improve some of them. Also, UIExplorer also a ported app, and being not a great example, should be rewritten to achieve more OSX look and feel.
Because Electron provides an awful UX. It ships with an entire web stack for applications that could be 1/100th the size and 100x the performance if they used a native toolkit instead of a web view. Electron apps also get none of the native L+F that you get if you use an actual toolkit properly. Electron is to the desktop as hybrid apps are to mobile.
I don't think that's true. You can achieve a lot with just react, css, node and the electron APIs. With enough effort and attention to detail you can make an app look and feel native with css (https://www.youtube.com/watch?v=JIRXVGVPzn8), V8 is not /that/ slow, and you have the advantage of using multiple node processes inside electron to offload work. And it's cross platform.
Yes, the built apps might end up being big, but that's a trade off I'm willing to take in favor of developing cross platforms apps with a modern and familiar web stack.
The obvious advantage to native look and feel is that it will be familiar to users, and that consistency in itself might make for an overall more beautiful look.
If I use 5 applications and they all look entirely different, it will not look beautiful, and each time I swap to a different application I have to re-familiarize with whatever the UI designer thought was a good idea for that application.
Author here. In most cases, Electron is much better in many ways.
I'm working on the code editor right now, so I'd like to build something small (few megabytes), performant, but allows me to use the whole js ecosystem.
There seems to be some common misconceptions about the technology behind both React and FRP, and unfortunately this is compounded by the fact that FB called it "React" when it is not technically using reactive technology or functional reactive programming. I'd love to hear from any experts on the matter what the key technical distinctions are between React and FRP and where Qt's QML, which is declarative and reactive, fits into this picture in comparison. I've recently skimmed several papers on general reactive programming, and many of them cite QML in their examples, while none of them mentioned React -- perhaps because React is newer. In any case, these are interesting paradigms that could use some dumbed-down explanations.
Oh good, another was to half-ass port things to Mac. Lovely. There's a reason people like native interfaces.
"No it's not like Java this time!" "It's not like Carbon!" "It's not Flash!" "Don't worry, it's no X11!"
If you care about the platform, go native. Learn the rules and look and feel. If you don't care that much? Maybe you should reconsider the port. You can't "click this checkbox for OS X", it doesn't feel right.
It doesn't really look like that's what this is, it's just a different way to wire up native UI components. You're still writing Objective C and using Cocoa.
I don't think you understand what React Native is.
It's just a way to use the underlying native UI. It's not a bunch of emulated components with a pluggable "look and feel". They're the real thing, just wrapped in a JS API.
No, I understand it generates native components. But if you're writing generic UI code and deploying it on a Mac without following platform conventions (about the menus, ways of doing things, etc) it will still feel 'wrong'.
When you think about it, using react with electron is kinda like react-native for cross-browsers. It'll be hilarious when someone writes a wrapper that let's you do cross browser with react
The React Native for OSX fork is being developed by a developer outside of Facebook, and as far as I'm aware Facebook hasn't put any resources into it. I'm sure they're super pumped about it though -- the core team is very enthusiastic about efforts to apply React/RN outside of just iOS and Android, they just don't have time to work on more than that at the moment.
I don't use or develop for OS X, but I know it has a reputation for some pretty bad desktop applications. Do people think React Native might lower the barrier enough to improve on this problem? Thinking of getting a Mac soon and am curious.
This is completely the opposite of the case, in my experience. People complain about some things like Mail and iTunes, but overall software for OSX is typically head and shoulders above its Windows and/or Linux counterparts.
For a recent example, having gotten used to Transmission (BitTorrent client on Mac), I was absolutely floored at how absurdly complicated and ad-ridden Windows alternatives are.
I have to echo this. I really wonder where you got that impression because it's the opposite of both the reputation I hear and my own experience.
There are very few applications that I miss from Windows. Most big cross-platform applications like Photoshop (or even SourceTree) are almost identical, but the majority of Mac-only apps that I try are fantastic.
Reeder (RSS client), Fantastical 2 (calendar), Tower (git client), iTerm 2, 1Password, Transmit (FTP/SCP client) and TextWrangler/BBEdit are just a couple of examples of apps I use every day that I think really show off what Mac developers can do.
There are many apps that are miles ahead of Linux or Windows equivalents: OmniGraffle, OmniFocus, Acorn, Pixelmator, 1Password, iTerm, Alfred, (Git) Tower, etc.
Can't you just use Transmission on windows? It's a GTK app and they're better on Windows than MacOS. Or you can always use it's web interface on Windows.
Transmission on OS X uses native UI components[1] rather than GTK. In fact they seem to have 3 sets of UI code (AppKit, GTK+, Qt), plus the web interface, plus whatever they're using on Windows (might be GTK+ or Qt there?).
Having used Transmission on both Windows and OS X, I vastly prefer the OS X version. It never crashes, gives nice notifications, and is generally very pleasant to use.
Those are also all apps made by Apple. You might be able to reasonably argue that there has been degrading quality in Apple's own apps. Personally, I love Mail and don't use any of the other native apps.
I don't think that really says much about the quality of the ecosystem for developing native apps though. Some of my favorite apps are Notational Velocity, 1Password, and Sketch.
> reputation for some pretty bad desktop applications
Compared to what? I like native OS X desktop applications better than native Windows, Linux, iOS, Android, or Windows Phone applications, and I like them MUCH better than web apps.
The main reason OS X desktop apps tend to be so nice is (a) Apple’s first party software in the 2000–2010 timeframe was mostly quite good, setting a high standard; (b) GUI conventions are reasonably standardized and developers tend to follow them better than on other platforms, in particular using native widgets which handle edge cases better than various ad-hoc custom (i.e. buggy) widgets on other platforms; (c) the Mac app economy has been pretty good for independent developers, and there’s a cultural expectation of paying for software which is much less present on other platforms, so as a result developers can afford to invest the time necessary to add polish.
Maybe React Native will lower the barrier and we'll get some of those javascript vector graphics, publishing, video editing, and music composition apps ported to the Mac, so people won't have to suffer from pretty bad apps any longer.
The only complaint I have about native Mac applications is Finder: it's frustrating and practically useless. Fortunately, there is a rich and robust CLI ecosystem, so I can largely avoid using it.
A React Native app isn't horrible or bad (nothing like Java Swing) but it also isn't delightful to use. Technically you have animations and things like the cross-platform navigator. In reality, you have a lot of performance issues and strange incompatibilities due to attempting to execute animation keyframes on the JS thread (or replace the system-provided navigation bar in the case of Navigator). It isn't terribly easy on battery life either.
I'd rather write my sync and offline storage system in JS and share that across platforms while leaving the entire view layer as native code. That stuff is far harder to get right for non-trivial apps, it just isn't sexy and most web devs ignore it completely because hey - the web browser is always online!
I'm biased though. Our customers download 5-10 GB projects with millions of objects in them because when you're building a hospital the MRI room is a literal faraday cage. No such thing as internet access in there and telling the user they can't pull up plans or engineering specs because they're offline is a non-starter.