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).
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.
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.
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.
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.
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.
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.
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?
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.
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
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.
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 :/
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.
[+] [-] warcher|10 years ago|reply
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.)
[+] [-] ghrifter|10 years ago|reply
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
[+] [-] guelo|10 years ago|reply
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.
[+] [-] tiglionabbit|10 years ago|reply
We should graph every programming language on a radar chart using those axes.
[+] [-] Swizec|10 years ago|reply
[+] [-] outworlder|10 years ago|reply
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.
[+] [-] tomjen3|10 years ago|reply
[+] [-] seivan|10 years ago|reply
Of course you can mitigate that with RxSwift, but it only goes so far.
[+] [-] misiti3780|10 years ago|reply
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.
[+] [-] mruniverse|10 years ago|reply
As far as React Native, I can't see it being used seriously. I think teams are going to have to know native iOS and/or Android programming anyway.
But seeing the mass of apps that never live beyond a year, maybe React Native is just the thing.
[+] [-] cbhl|10 years ago|reply
[+] [-] minionslave|10 years ago|reply
[+] [-] jhgg|10 years ago|reply
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.
Here's the app if anyone wants to try it: https://itunes.apple.com/us/app/discord-chat-for-gamers/id98...
[+] [-] leosantos|10 years ago|reply
Did you encounter any such problems?
[+] [-] alexashka|10 years ago|reply
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.
[+] [-] jordwalke|10 years ago|reply
[+] [-] Smudge|10 years ago|reply
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.
[+] [-] estreeper|10 years ago|reply
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.
https://code.facebook.com/posts/1189117404435352/react-nativ...
[+] [-] marknutter|10 years ago|reply
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.
[+] [-] EvanPlaice|10 years ago|reply
[+] [-] Apocryphon|10 years ago|reply
[+] [-] iheart2code|10 years ago|reply
[+] [-] user8341116|10 years ago|reply
Every cross platform mobile framework in a nutshell.
[+] [-] epberry|10 years ago|reply
I think this is a key phrase here. I'm writing a RN Android app without knowing much about Java.
[+] [-] incepted|10 years ago|reply
[+] [-] mostafaberg|10 years ago|reply
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
[+] [-] raspasov|10 years ago|reply
[+] [-] dj_doh|10 years ago|reply
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.
[+] [-] haberman|10 years ago|reply
Bonus if they are free.
[+] [-] n0us|10 years ago|reply
[+] [-] jkmcf|10 years ago|reply
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.
[+] [-] supercoder|10 years ago|reply
[+] [-] SonicSoul|10 years ago|reply
[+] [-] jrbapna|10 years ago|reply
[+] [-] sjclemmy|10 years ago|reply