121–130 of 135 posts
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.
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…
You also appear to not know how it works. React Native doesn't use a web view at all. It uses JavaScriptCore to process UI updates to native views.
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.
Earlier quoted context omitted.
You also appear to not know how it works. React Native doesn't use a web view at all. It uses JavaScriptCore to process UI updates to native views.
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.
Earlier quoted context omitted.
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).
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 trivial…
> 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.
These things are quite different from having pervasive laziness, though.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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 po…
Facebook is rewriting the News Feed in RN. That's not a trivial example.
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 ke…
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.
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.
Earlier quoted context omitted.
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 po…
> 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.
Earlier quoted context omitted.
> 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.
Correct, it's not a trivial app by a long shot. Also, a validation for React Native.
"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.
[0] https://twitter.com/andy_matuschak/status/560511204867575808
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…
React-Native isn't just a JS-wrapper, you're trading away language safety features (e.g Swift) with features to help with transient state (React). Of course you can mitigate that with RxSwift, but it only goes so far.