First Impressions Using React Native
jlongster.com
First Impressions Using React Native
1–10 of 195 posts
Re: First Impressions Using React Native
#2Declarative UI is boss.
I know Andy (former UIKit team) was quoted in the intro thread but I'll do it again:
>I say with confidence as a former UIKit author: React's model for the UI layer is vastly better than UIKit's. React Native is a huge deal.
https://twitter.com/andy_matuschak/status/560511204867575808
If you're averse to React because of JSX, “mixing templates and views” and similar superficial “best practices”, you're missing out. Engineers embracing React are not dumb. You should consider a possibility that they think it's good for a reason, and that reason is something you should learn about instead of armchair-rejecting it.
Try tuning out your inner rule-of-thumb linter for a weekend and really give it a try.
Re: First Impressions Using React Native
#3I love the concepts behind React, and I agree this is a huge deal...I just wish it weren't javascript. It is a terrible language, and the languages that compile to javascript are a poor substitute (bloated code sizes, interop issues, poor runtime performance, etc). For a framework that is all about state machines (a good thing! All UIs are state machines), I hate that there aren't better ways to model them in the language. I would kill to be able to do React in F# or OCaml.
Re: First Impressions Using React Native
#4I love the concepts behind React, and I agree this is a huge deal...I just wish it weren't javascript. It is a terrible language, and the languages that compile to javascript are a poor substitute (bloated code sizes, interop issues, poor runtime performance, etc). For a framework that is all about state machines (a good thing! All UIs are state machines), I hate that there aren't better ways to model them in the lan…
Pretty sure Om[1] for React Native is coming.
>bloated code sizes, interop issues, poor runtime performance, etc
I've heard about no such problems about ClojureScript. In fact there's less code size than you'd usually have because Google Closure Compiler advanced more works with it out of the box[2]. It's also fast because immutability.
[1]: https://github.com/omcljs/om
[2]: http://swannodette.github.io/2015/01/06/the-false-promise-of...
Re: First Impressions Using React Native
#5Sounds amazing... What are the challenges, limitations, and tradeoffs for using React Native? There have been similar initial reviews of Titanium, Phonegap, and Xamarin, but in my experience they all have serious issues that make native development a better option in most cases.
Re: First Impressions Using React Native
#6Sounds amazing... What are the challenges, limitations, and tradeoffs for using React Native? There have been similar initial reviews of Titanium, Phonegap, and Xamarin, but in my experience they all have serious issues that make native development a better option in most cases.
There's always going to be the big drawback of working in a separate VM (JavaScript) rather than directly accessing native APIs. But React is taking advantage of that as much as possible, making it easy to refresh everything and allowing you bring everything you knew about React.js over.
But if you want to access an API, you still need to wrap it. Depending on the API, you need to be careful performance-wise. Native React avoids a ton of problems that other frameworks have though because they provide a solid mechanism for dynamically working with UIs, and it's very efficient because they only send minimal diffs across the bridge.
Re: First Impressions Using React Native
#7Will React's concepts every make it as truly native code I wonder?
Re: First Impressions Using React Native
#8I love the concepts behind React, and I agree this is a huge deal...I just wish it weren't javascript. It is a terrible language, and the languages that compile to javascript are a poor substitute (bloated code sizes, interop issues, poor runtime performance, etc). For a framework that is all about state machines (a good thing! All UIs are state machines), I hate that there aren't better ways to model them in the lan…
Pretty sure Om[1] for React Native is coming. >bloated code sizes, interop issues, poor runtime performance, etc I've heard about no such problems about ClojureScript. In fact there's less code size than you'd usually have because Google Closure Compiler advanced more works with it out of the box[2]. It's also fast because immutability. [1]: https://github.com/omcljs/om [2]: http://swannodette.github.io/2015/01/06/th…
I like Clojurescript in general, but the code bloat problems and runtime speed problems still exist even with advanced optimizations. The big problem is that you have to use code that is Closure-compatible. If it isn't, there are hacks to make it work, but you end up killing the ability to remove dead code. And no matter what, you are going to end up shipping portions of the Clojure code as a runtime within the javascript runtime.
I have used cljs for non-mobile web interfaces, but the performance of Om in Phonegap on mobile hardware was terrible enough that I scrapped it for Xamarin.
Re: First Impressions Using React Native
#9I love the concepts behind React, and I agree this is a huge deal...I just wish it weren't javascript. It is a terrible language, and the languages that compile to javascript are a poor substitute (bloated code sizes, interop issues, poor runtime performance, etc). For a framework that is all about state machines (a good thing! All UIs are state machines), I hate that there aren't better ways to model them in the lan…
Pretty sure Om[1] for React Native is coming. >bloated code sizes, interop issues, poor runtime performance, etc I've heard about no such problems about ClojureScript. In fact there's less code size than you'd usually have because Google Closure Compiler advanced more works with it out of the box[2]. It's also fast because immutability. [1]: https://github.com/omcljs/om [2]: http://swannodette.github.io/2015/01/06/th…
Om is fast at checking if a component's state has changed because you can do a very fast identity comparison on the persistent hash map holding state, but persistent data structures are not faster than their mutable cousins simply because of immutability. That immutability leads to significantly more objects being allocated, which means to really take advantage of these features in a managed language you need a VM with a very high performance garbage collector. This is partly why Clojure on the JVM works so well. That being said, non JIT compiled JavaScript VMs generally provide terrible performance for ClojureScript. I do not believe JavaScriptCore JITs anything, so I don't know how immediately useful ClojureScript with React Native will be outside of toy examples.
Re: First Impressions Using React Native
#10I love the concepts behind React, and I agree this is a huge deal...I just wish it weren't javascript. It is a terrible language, and the languages that compile to javascript are a poor substitute (bloated code sizes, interop issues, poor runtime performance, etc). For a framework that is all about state machines (a good thing! All UIs are state machines), I hate that there aren't better ways to model them in the lan…
> It is a terrible language
As Douglass Crockford says, JS is a great language with some terrible parts. I don't understand why some people can't get past that.