Truthfully, the language barriers are nothing next to the API barriers dealing with your platform of choice. I am probably giving away my age here, but there's very little that's new under the sun after you've tussled with... say one each of the big three language families. These being: Nasty old C (not going anywhere, ever. Deal with it.), modern scripting languages (Ruby, Python, et al) and the real deal functional languages (lisp, ml, haskell, etc). It just turns into "Oh, this is how they handle an array. Do I have any functional plumbing? Ok, great. How do I dispatch a thread? Ok, let's go." It's just not that interesting after a while.
Objective-c is quirkier than most, swift is nice but still baking, but it really all boils down to the platform APIs. And you're gonna have to get wet at a platform level if you want to provide functionality beyond a mobile web page. (Albeit one with improved load times since it's coming from disk, at the cost of dynamic updates since it's coming from the app store.)
Yep this is what I'm realizing after a few years of programming. I can pick up a language easily, however learning it's APIs is almost as hard as learning the syntax for the language itself.
Like how do I open a file? Ok cool. How do I close it? Do I need to explicitly close it? Ok.
Also, learning APIs for other peoples codebases/software is task of learning that isn't trivial too
I agree. Keeping up with the giant, buggy, constantly changing, platform API, as well as the whole ecosystem, from build tools to the app distribution and analytics, is by far the hardest part.
These abstractions on top of the platform might make it easier for quick prototypes if you don't have time to learn the language. But you'll lose some flexibility, power, visibility and community. After a while the initial speed benefits wear off since the language is a small part of the things you have to stay on top of, especially if the app takes off.
Those are the extremes, so once you know those you can handle most things. Some modern languages seem to have a foot in each camp, like Rust for example.
We should graph every programming language on a radar chart using those axes.
Yeah, I find the learning experience of any language to be like that, once you have a few under your belt.
Except Haskell. I can do the trivial stuff, but anything non-trivial is a chore to learn. It is not as if it has a learning curve, it has a learning brick wall that hits you very early on.
That is one way to write the code, but if you do it that way you will never get the benefits of each language. Haskell and Lisp are both functional, but they way they are intended to be used are very different (example: if you don't use macros with lisp you are probably missing something. If you don't take advantage of lazy evaluation in Haskell you are also missing something).
Uhhh, I never suggested writing lisp in a C style, or ruby in a functional style (well, more so than it encourages at least). That would be crazy. My point is that there aren't that many ideas under the sun. Lazy evaluation, super. Monads, ok. Real-deal, no playing memory allocation and management? Where's that union stashing variables again? Are you sure? Uhhh, fine I guess. (Although I'd rather take the monads.)
Lazy evaluation is no longer exclusive to Haskell and other functional languages.
C# has had Linq for lazy evaluation of data collections for many years.
Javascript supports observables now and ot's only a matter of time before they're included in the official spec.
Reactive Extensions has been extended to many different languages now.
Lisp macros are essentially higher order function definitions. They can be trivially applied using decorators in Python and closures in Javascript (JS decorators will be supported in ES7).
Concurrency is a real bear on mobile, and it isn't something that can be ignored (a la the web) when you're that close to the metal. I'm an explicit js chauvinist, so maybe they've gotten something together on that front, I wouldn't know, but that's a very serious concern of mine with js-outside-its-proper-place-within-the-DOM.
i agree with you, although i think you are forgetting to add (and maybe it is implied here and i missed it) that learning mobile development requires you to not only learn new language APIs in objC/swift, but you also have to learn some new design patterns (delegation, etc.) and most importantly the SDKs (CocoaTouch)
if you can use react native and avoid learning a lot of this it is a big win - I havnt used it yet, and I have a hard time believing it a mobile only company would use it to build their mobile app, but i am excited where it is going.
>learning mobile development requires you to not only learn new language APIs in objC/swift, but you also have to learn some new design patterns (delegation, etc.)
Delegation has been a standard feature of desktop APIs for decades. Not just on things like Smalltalk and ObjC -- it has been the standard .NET model for UI events since C# 1.0.
Going to need a source on that 'majority' of which you speak of as if its a fact. Sure, web development is popular, but there are a _lot_ of developers working on other things (which potentially include delegation). Also, I'm sure you'll many web frameworks that use the delegation pattern.
So here's the real bear of it, and the crux of my argument.
The delegate thing is an iOS thing. Android uses a totally different pattern. I mean, there are delegates, to be sure, but android loves their anonymous inner classes in many of those cases. (Which is closer to idiomatic js IMHO.)
So on a language level sure, easy peasy, you could delegate in javascript all day long (and you do). But on a platform level, nuh-uh. One is going left and the other is going right. How do you meet in the middle? What fine line gets scrubbed in between?
React-Native pattern with delegates is passing down functionHandlers to childComponents that would trigger them.
Except Objective-C (and Swift) had protocol conformance.
Though come to think of it TypeScript allows you define an interface for a Component, one of those attributes could be a function.
Basically yeah. An object can have one delegate object, which implements a set of required and optional methods defined in a protocol. So the delegate can add customized behavior to an object without subclassing.
No one is doubting that you'll need people who know iOS and Android ecosystem. But React isn't just a wrapper over native views. It's a fundamentally different way to write up applications compared to the way you work your way around states and UI.
I guess I see it as a form of technical debt-- you move faster, but past a certain level of performance it's all gotta go native. There are a lot of places it would be a decisive win. There are a lot of mobile websites that are great. But there's a ceiling, and once you hit it, all that javascript is gonna get rewritten.
Agree 110% on the blurring, and maybe a 5th category too - 4GL, for SQL and its ilk.
Obj-C, Obj-C++, C++, and C can all co-exist in the same codebase and be complied into 1 output (if you are insane enough to try), similar to CUDA or Fortran with C/C++. That's not really possible with JVM or CLR languages, but not impossible either. Which makes them more like 3GL/OOP while sharing more similarities with smalltalk than 2GL/C.
Py, Lua, GLSL/HLSL, and many others can "mix" or be called by C/C++ similar to CUDA, and Lua is definitely in the interpreted "script stuff" bucket, not statically compiled like Java, C#.
The shader languages like GLSL/HLSL are really confusing to categorize, especially when used with C#, because they can exhibit characteristics of 1GL thru 4GL.
Can't forget the declarative regular and context-free languages.
XLST and other template syntaxes are another interesting case. They look mysteriously like a declarative context-free language but have imperative characteristics of a turing complete syntax.
JVM may not be able to be combined with compiled languages but there are a number of languages that, at a bytecode level are compatible with Java. For example IronPython, Rhino, etc. The same can be said for the .NET environment and languages like VB.NET, managed C++, C#, F#, etc.
Don't even get me started on languages that can output output Javascript. Last I heard, there's over 100 of them now and the list keeps growing.
I'm not sure about GLSL/HLSL because I haven't used them but they sound like they're declarative DSLs (Domain Specific Languages).
Maybe it's about time somebody created an update to the Chomsky hierarchy. Instead of the traditional subset-superset classifications, some other system is used to compose the characteristics of languages.
In the bigger picture of things, it's all very incestuous. Like every language is trying to be like every other language. The winners of the pack are those that everything else compiles/transpiles down to.
I feel like C# (and C++, and Java) would all be basically in the C camp. C# and Java could be arguably somewhere on a spectrum between C and the scripty stuff.
React Native is pretty awesome - especially if you've got a web version of your app. At work, we use React Native for our iOS application - and are able to share pretty much all the store & action creators logic for our web (and desktop) app. It's been pretty huge as all our iOS engineer (we only have one!) really has to do is do the view specific stuff for iOS, the rest being shared with the web/desktop version. Also, our engineers that work on the web application can contribute to the iOS app with ease too.
Our general product iteration strategy involves building it on the web version and then porting it to iOS fairly quickly. For a chat application, our stores handle a lot of data, so it's been awesome to have that code shared.
React Native's bridge is also alright. We bridge with Component Kit for the chat messages view & WebRTC for the voice side of things fairly easy from JS.
Also, being able to update the bundle w/o doing an App Store update is pretty big too.
I didn't play on-line for years, last time I did regularly, the standard for voice communication was Ventrilo/Teamspeak. When I first used Discord a couple of months ago, I was just shocked. It has a decent webapp. I can create my own server for free. It takes less than a minute to get going. It just works.
On a more technical note - I'm exploring React Native (having significant experience shipping native iOS Apps) and while on the face of it React Native looks amazing, as I go deeper into building something production quality, I've hit roadblocks with doing simple (natively) things like scrolling a scroll view to focus on a text field that's partially visible and changing the offsets of a scroll view to prevent the keyboard from masking the focused text field in a way that doesn't appear glitchy.
What are you hoping to get out of using react native?
This write once, use everywhere is such a strange desire.
If you're a serious company, develop on iOS/Android first, then hire a dev or two to make an exact copy for the remaining platform. It's really not that hard.
The hard part is doing something the first time and iterating. Copying is not rocket science - look at the Russian facebook clone - it's actually better because of copyright laws, you can do more on their version.
There are two fundamental issues with the mobile first approach.
Duplicate effort does incur a real cost in terms of time to delivery. Duplication is a clear sign of inefficiency. A platform that provides native support for multiple platforms reduces such duplication.
The maintainance cost of providing multiple platform-specific implementations compounds over time. For every feature added there's a chance that subtle differences will be introduced. In a perfect world one platform developer will have an equal level of skill and understanding as a developer for another platform. In practice, there's no guarantees that both versions will be kept in sync. The differences and abstraction leaks become technical debt and accumulate as the platform grows/changes over time.
Now, lets say you want to provide a web, iOS, Android, and Desktop interface for a platform. Would you choose to do 4 independent implementations in 4 different languages. Or 1 in a single language with platform-soecific differences?
Platform duplication is a violation of DRY at the system level and incurs the same problems of diplicating code, at a much larger scale.
The Russian Facebook is basically a independent fork. It's not required to remain feature-complete and in sync with the official Facebook platform.
I understand the theoretical upsides to one platform/language to rule them all, absolutely.
I am saying that trying to re-write the layout engine, data layer and all the rest to make it work the same on both platforms is not only a massive undertaking - it is ignoring the reason the platforms diverge to begin with.
iOS has features Android doesn't and vice versa. Something that works on both platforms is always going to be a second-class citizen - it's the lowest common denominator.
I don't want the lowest common denominator because it's 'easier for developers'. I want the best stuff.
The theoretical technical debt due to writing on different platforms is why we have software architects and senior developers.
Really, I've been part of a dev shop that does ios/android - the biggest hurdle is people problems, not code. People who don't know what a good app is or have any taste so they say first show me, then I will start asking for changes at random while insisting on a tight deadline.
As for web/ios/android/desktop - this is a rare bird, if you need to support that many platforms, you can afford an architect and some smart people.
The application layer is decoupled from the rendering layer specifically for reuse across multiple platforms. That means the data layer that handles data fetching and change propagation works everywhere.
The view rendering layer is the part that is specific to each platform and the React community provides web components that work natively on each platform making the development process between mobile/web more consistent. Mobile provides an escape hatch to write platform specific code in the native language.
"As for web/ios/android/desktop - this is a rare bird"
Targeting all, will remain very unlikely. Targeting more than one is pretty common. React and Angular2 are pushing hard to enter the mobile development ecosystem. Microsoft has been pushing for Typescript usage on the desktop and just picked up Xamarin so we'll likely see desktop or web or mobile hybrid applications at some point in the future.
If the barrier-of-entry to support another platform is low enough, it'll make sense to do so. In the current ecosystem, supporting even 2 platforms is a massive undertaking.
I just spent 5 minutes looking at React Native and my first and final impression is that this is a complete waste of time.
I am so flabbergasted that I took the idea seriously, looking at what it actually is, it is so clear to me that this is not going anywhere.
For starters - using Javascript when you could be using Swift/Objective-C is laughable. That's a non-starter. Then, there is no real data layer at all! You have to interface with Objective-C!
So what is the point of using this at all? To have shared view layer logic? Facepalms
> I am so flabbergasted that I took the idea seriously, looking at what it actually is, it is so clear to me that this is not going anywhere.
Facebook is using RN in production. So I doubt it.
> Then, there is no real data layer at all! You have to interface with Objective-C!
I don't get what you mean. You don't have to interface with any native code if you don't have a very specific need to use a platform specific feature which is not available in RN.
> I just spent 5 minutes looking at React Native and my first and final impression is that this is a complete waste of time.
If you spent just 5 minutes, it clearly means that you don't have enough experience with React Native, and I don't think you should give opinion on anything without at least being familiar with it. I've been working with React Native for months, and yeah, there are technical hurdles. But I'd say the same for Android, or web (I don't have any experience with iOS dev).
There are parts of React Native that suck. But there parts which are amazing. Amazing enough that I'll choose React Native over Java/Obj-C any day. The development speed with React Native is much faster than native Android dev. The DX is getting better day by day.
I get to share code isn't the primary reason why I love React Native, but it's an important thing for companies which want to support multiple platforms.
I'd say let's focus on fixing the parts that suck in React Native, rather than discarding a new tech without even trying it.
Ok hold on, you've been working with it for months? To what end?
Please tell me you're not using a library that's at 0.20 for production.
So you're using ReactNative for pet projects right?
As soon as you get to writing a real app that's beyond a to-do list, you'll be in a world of pain. Just start with having no support for a sqlite/database or an orm layer on top of it, only a key-value store as your first massive and insurmountable stumbling block.
I've implemented one solution to this in FB's Groups App. Try that experience out and let me know what you think. Also, Nick Lockwood should comment here.
We should hopefully be able to open source a cleaned up version of the solution that Jordan alluded to, but we have a long list of components we'd like to work on, and only a finite in-house development resource.
I think it's important to understand that React Native is not an attempt to replicate the entire iOS native framework - it's a set of UI components that aim to provide a better developer experience for the common app development challenges we face at FB, combined with a framework for building new components.
When we encounter an uncommon challenge (i.e. something that we haven't already had to solve and build a reusable JS component for), we simply drop down to the layer underneath and create a new native component.
That's why I struggle to understand the argument that "React Native doesn't do this one thing I need, so I can't use it" - we put a lot of thought into the plugin architecture of RN, and making native plugins is trivial for anyone familiar with iOS or Android development.
If there is something you already know how to do natively, you can leverage that knowledge to build an RN plugin and then get the best of both worlds. If you don't already know how to do it natively, there's a good chance that someone else already made a plugin that will do what you want.
It's not incredibly advanced: It mostly just consists of measuring where exactly the current text box is in the scroll view, how high the text box is, and then having the scroll view scroll to that location, followed by fading in a docked text input right on top of the underlying one. It's pretty slick, but I'd encourage the community to recreate it in a reusable component and open source it.
What's most amazing to me about React Native was how quickly we were able to go from idea to product (~3 months working only part-time) using our existing knowledge as web developers. We did have to write a few lines of Objective-C here and there, but for the most part all of the views and interactions fell together the same way a webapp would.
As someone who is about to embark on a similar route, that's interesting and exciting to hear. Was it both Android and iOS? If so, how much of the codebase/time was spent on shared code versus needing to write platform-specific portions?
I've seen the Facebook post about developing Ads Manager (though it glosses over some details), but it would be interesting to hear other people's experiences.
We built it for iOS, but I expect Android would have been a similar experience (albeit with much more cross-device testing required).
Hard to say how much of it was platform-specific, since we only targeted 1 platform (for now). But the large majority of the code we wrote exists in React components or in related JS files, so porting it over to Android should be a matter of decoupling the parts of the code that rely on native features (i.e. camera, navigation, etc).
A lot of that work is already happening in the React Native community so I expect the cross-platform support will keep getting easier.
What I'm curious to know is, outside of the arguments about React being the superior pattern for developing UI's, how is this fundamentally better than or different from other hybrid libraries like Appcellerator Titanium or Xamarin?
In my experience they all fall short when you try to get the last 20% of your app written. Because you're not writing in the native language, directly accessing native API's, you're always going to be limited to the abstractions that the hybrid framework has (or hasn't) defined.
I much prefer either going full native or full HTML5 because I never hit a wall when I try to do something that hasn't been covered well by the hybrid framework yet.
That's no different than appcellerator or xamarin though. And in the case where you are just using embedded webviews you can easily write native code alongside them. Cordova is written in objective-c and is easy to understand.
I'm sure this observation was probably made tens of thousands of times before, but- is the React Native and frameworks like it the beginning of the end of the "native vs. mobile web" debate? A synthesis of both approaches?
What I'm betting on is the mobile web browser. I know going HTML5 on mobile has failed in the past, but the future can still come. On desktops, desktop apps ruled until web apps became super powerful. I'm betting on the same fate for mobile web apps.
On my mobile I absolutely use and prefer native applications. I only use my mobile web browser for web browsing tasks. On my desktop, I only use my web browser for web browsing (searches, news, content, etc) and I hardly use any web applications.
I don't feel like I'm unique in this.
I think this "synthesis of both approaches" has merits.
There are times when the native app is great, but all the permissions that you have to give up have me fallback to the web version. There is a native phone app for a popular online course that has recently started asking for access to 'Phone Id/what not' on Android. Why? Just show me the videos of the courses I paid for. I refused to update and these days I just log in via Chrome and play the video on there. Not the best UX but that is what I will associate with that product going forward.
I wish Android would make something granular (and understandable) or at least let me disable permissions after the fact.
But native applications use webviews more than you might expect. I've heard that the conversation view in the Messages app is a webview, and I know from first-hand experience (CSS not loading) the Instagram feed is one too.
I think that webviews get a bad rap because you only notice then when they're done badly.
"The general distinction between an interactive web site of any kind and a 'web application' is unclear. Web sites most likely to be referred to as 'web applications' are those which have similar functionality to a desktop software application, or to a mobile app."
I'm the opposite of you. I'd much prefer to do everything in a browser. I hate downloading new apps for every little link. I was really hoping the Firefox OS worked out.
Now that Chrome supports notifications (on Android) I was able to uninstall the native Facebook app and rely exclusively on the web version (which actually loads faster for my anyway).
Still have the icon on my homescreen, still get the same notifications -- the main difference is how much better my battery life is now!
I think so. Reducing the language/framework barrier to mobile development definitely makes makes arguments for mobile web weaker. If you have a lot of mobile users and you want them to have a really good experience, going the React Native route makes a lot of sense.
I don't think so. I've participated in enough native / mobile web flamewars to last a lifetime, but the main argument this doesn't resolve in any way is the question of freedom. A react native app is still subject to Apple's App Review, or can be removed on a whim by Google (remember the ad blockers recently?). Some people have a real problem with that.
I am particularly interested in hearing about view transitions. I know JavaScript, Android, and iOS development and found that, while I could easily make a React Native app work on iOS and Android, it was lacking the polish that modular view transitions could provide.
You can write a CRUD like app without any hardware/native code required. However, even when you do need that code - for example I'm building an app that records and plays audio - react native still gives you an advantage in the sense that you only need to expose a hardware API but all the logic still stays in javascript. I've managed to write just enough Objective C and Java to expose some APIs I need, and no more.
There is also a lot of react-native npm packages that abstract away the hardware issues, quality & completeness varies however.
There were definitely some head scratchers along the way, I think I address a few of them in this post but I plan to write a few more posts that show how we tackled some issues in more detail so keep an eye out for that.
Why is this on the top of HN ?
Honestly, this is a bad thing, not a thing to show off.
To quote the author: "We're web developers, not iOS developers."
EXACTLY, don't bring your web tech into native platforms, learn to do it the
right way or just hire someone who knows how to do it.
Seeing things like that creeping into becoming a norm makes me cringe
This is on the top of HN because people, like me, are interested in it. You say learn to do it the "right way", by that logic we should have stuck to making desktop only apps instead of browser based web apps. I'm not saying this is better or worse. But I certainly think it's an approach worth considering.
It's a great piece of tech, I'm not saying anything against that, I'm saying that it shouldn't be used as a replacement for native programming because you don't want to learn a new language. react will come with huge limitations and deps that you don't want to even think about, it's never easy as "code once, deploy everywhere", this is usually a bad decision any company makes, engineering wise.. same reason as adobe air never took off, it's a bad idea, the only reason this is taking off is because people already know JS and don't want to learn something else.
By the "right way" I mean use every language for its intended purpose, you can't build desktop apps in browsers, that's why we have Javascript. and i'm saying we should keep it that way
React Native doesn't claim "code once, deploy everywhere", and in fact embraces native APIs where appropriate. As a reference, their slogan is "learn once, write anywhere". In other words, learn React Native, and write native apps wherever you want. Indeed one of the opening talks about React Native at React Conf specifically mentions that React Native is a leaky abstraction, and embraces that by allowing multiple escape hatches so that the native APIs are always available.
Railing against React Native seems like railing against Unity3d, or saying that abstracting the common parts of mobile development (while leaving the non-common parts 100% available) is a bad thing.
By the "right way" I mean use every language for its intended purpose, you can't build desktop apps in browsers
You can build desktop apps in browsers (ie emscripten). Additionally, can you explain why a "language" (as compared to platform specific APIs) has any relevance to what can or can't be built for a mobile device? For JavaScript specifically, if Apple didn't think that it was a language for building applications on iOS, then why would they ever have release JavascriptCore (which is what React Native uses)?
React is native.
It's a JS interpreter on a separate queue rendering native UILabels and UIViews.
I'd say the concept is far more superior to UIKit which disgusts me, and I've worked with for almost seven years now. I honestly think React is the future, but for now we can try to stick with MVVM and RxSwift ;-).
I think you're fundamentally not understanding how React (not just React-native) works.
This is mainly taking off because native developers want a fast build-run loop, hot code reloading, the ability to update code on the device without pushing a new App Store release, and a shared technology and mental model for writing apps across web, iOS and Android.
No, it is not. "I don't know what I am doing" mentality already hurts the web, where hordes of developers without understanding of the strengths and limitations of the platform are making angular monstrosities, now the same is being pushed to mobile.
Luckily it does not have much chances there.
It is on the top of HN because people find it interesting.
People are interested in bringing different tech into native platforms to decrease how much it will cost them to develop the product and I for one don't really care if it is not how you are supposed to do "proper development". Once upon a time you weren't supposed to build servers out of commodity components, but it worked alright for google.
The biggest barrier to high fidelity ECMAScript apps on native platform is simple economics. Apple is guaranteed a $99 bounty when you push something on the appstore. Making Safari or WebView compatible with their native APIs and performance is a risk for AppStore.
Having built 3 non-trivial iOS apps using phonegap and JavaScript. I have come to the conclusion that I'm never going to build native apps using web stack. I have struggled with API support, DOM limitations and performance.
Disclaimer: I have not tried react native.
I think it'll fail for mission critical and non-trivial apps. If you just want an AppStore presence for your browser app or your app is trivial like one in the post. You are probably going to be fine.
Good luck sir getting web stack to work with native that's at par with Swift/Obj-C perf. Also, do share some non-trivial apps that you/your team has built using web stack on iOS.
p.s. I've explored JavaScriptCore the first day it was available to developers.
p.p.s. I noticed you are a "React fanboy," so that's normal.
What exactly do you think is "web stack" about React Native? The fact that there's javascript involved in the high level UI state code? I really don't think you grasp the difference between React Native and the various "wrap a web app" approaches.
I've dabbled with this JavaScript for native code since 2010-11. Appcelerator Titanium SDK (now Appcelerator), Telerik, RubyMotion, Xamarin and of course PhoneGap (including PhoneGap Build). I've not used Xamarin, but putting it there to give a broader picture.
Please don't get me wrong, I'd love to use ECMAScript(, CSS and markup) to do all web, native and server side development. Unfortunately they are marred by poor API support, performance and customization. Last two are extremely critical for non-trivial apps.
If you are building run of the mill simple apps like - news feed, photo, video and reading etc. You'll be okay with anyone of the above 'web stack'.
Here's the litmus test. Ask the Reactive Native team to port their non-trivial paper app or mission critical messenger app or main app to Reactive Native. They are using Reactive Native for a lame duck Groups and some ad manager app.
JavaScriptCore is one layer deeper than wrapping a UIWebView, but it's several layers from true native.
> Here's the litmus test. Ask the Reactive Native team to port their non-trivial paper app or mission critical messenger app or main app to Reactive Native.
Facebook is rewriting the News Feed in RN. That's not a trivial example.
> They are using Reactive Native for a lame duck Groups and some ad manager app.
"Some ad manager app" which happens to be the ad manager for one of the largest advertising platforms on the planet right now. It's also composed of non-trivial UI, you should try it before blindly bashing it. I've used both Cordova, and Titanium, too, by the way - Cordova was relatively painless but lacked the native feel. Titanium sort of had the native feel but it was slow. The Titanium community also felt very hostile towards competition and they didn't promote FOSS. Maybe you're a Titanium developer?
> Unfortunately they are marred by poor API support, performance and customization.
Web apps can hit 60fps these days (again, using React (Canvas)).
> Here's the litmus test. Ask the Reactive Native team to port their non-trivial paper app or mission critical messenger app or main app to Reactive Native.
That's a really lame litmus test considering they've got a massive code base in native languages with no reason to throw them away since they're working perfectly and they have a ton of developers to throw at the problem.
> They are using Reactive Native for a lame duck Groups and some ad manager app.
They appear to be using React Native for most new apps that they develop. I would assume it would be up to the discretion of the team to choose whether or not to use React Native. Most do because React Native is way better than plain old native. Even the author of UIKit thinks so.[0]
I'd be interested if you could provide a common real world example where React Native wouldn't be a good fit.
Furthermore, React Native never claims to be a total replacement for native. We openly acknowledge that some problems are best solved in native code. That's why React Native has excellent support for 3rd party modules.
Okay how about one very, very simple question - Can I replace my all of my Swift and iOS+tvOS+watchOS APIs with React Native? To make it easy for you. Can I do that within next 1 year? What will happen when Apple will introduce a slew of new APIs will be introduced in Sept?
As for the styling part, This is actually a relief to see since I am using Radium and it looks like some of the styles I have will work without any modification. Any other styles I would have to rewrite anyway.
Does anyone remember Sun's DevGuide app development platform?
I used this in the 90s, and it was ridiculously easy to get write an application. You visually designed your UI, generated code, and then added your actions/event code. It was straight forward. I haven't seen anything come close. Sure it was limited, but for the small apps I want to write for Mac and iOS, it would be perfect.
this is great and timely! I was planning to do my first proof of concept in RN this weekend in hopes to maybe use it in a hackathon next weekend. If anyone has any other beginner resources that would be great, I've yet to even use XCode :/
Yes. Since the release of Swift, Xcode has Ben notoriously crash-prone and buggy. It is getting better slowly, but that was a pretty terrible first six months.
For a startup still trying to find product-market fit and not building anything intensive (ie mobile games), webview apps are the way to go. Build, test, iterate quickly and fix bugs on the fly.
I'm writing mobile apps using angular / Cordova and ionic. When they are running on a device I can't tell the difference between a native app and a JS Cordova one.
I think JS is the future of mobile apps.
> I can't tell the difference between a native app and a JS Cordova one
Sure, what kind of app are you writing ? games ? a video player ? a messaging app like Telegram ? a background activity on Android ? of course if it's a basic CRUD app, you're not going to notice the difference. try to make a 2D or 3D game with Cordova and see how it runs. The question you should ask yourself is, do you need a webpage in a native-shell at first place when you could just develop a website.
I can tell you from experience that making a robust Ionic 1 app with Cordova that is performant is difficult. Cordova is not good at all.
We did not have chump change for developers either - I've numerous contributions to Angular and Ionic, and one of my former co-workers when I was there is now on the Angular team.
React Native is a superior abstraction, since it allows you to hook directly into native components very easily (try writing custom Cordova plugins), and keeps high level logic in JS.
Wait, but what about designing the chips to run your CPU? Or synthesizing the silicon to print your chip onto? You surely know how to mine for the precursor elements for solder, too, right?
The world is changing. Our industry is changing every day, week, and year. Developers before you laughed at your high level C while they were using punch cards.
You judge, yet I've spent the last few days doing some amazing things with d3.js and I'm all over modern web dev. Being able and not liking the state of it are completely different.
NPM is a wonderful thing. Sure it has some perf. issues, but JS is growing faster than ever because of it.
And RN is awesome as well. RN for front-end devs is kinda what Bootstrap is for back-end devs (or any dev that doesn't like to touch HTML/CSS). Let's just be happy that we are making progress as a community and be a bit more open-minded.
No. You still need to teach the fundamentals or you'll run out of people to do everything low level. It's no longer a science when it's wishy washy high level
Objective-c is quirkier than most, swift is nice but still baking, but it really all boils down to the platform APIs. And you're gonna have to get wet at a platform level if you want to provide functionality beyond a mobile web page. (Albeit one with improved load times since it's coming from disk, at the cost of dynamic updates since it's coming from the app store.)