Wonder if the ability to easily refresh the view will make a difference to ios dev used to the wysiwyg approach by xcode for building views.
First Impressions Using React Native
141–150 of 195 posts
Re: First Impressions Using React Native
#142Probably the most useful way to get a read on this is to compare it to Titanium, also a JS-to-native framework that runs JS on a separate thread. The biggest problems with Titanium were not performance. A couple of the most common complaints: 1) You don't have full access to native SDK functionality (e.g. all the latest cool things in iOS8). You're going through a cross-platform API wrapper and limited to the choices…
They are working on web-like APIs so you don't have to necessarily deal with the native platform for basic stuff like file/network access, etc. For more advanced stuff it's super simple to make your own wrapper. But yes, this is a constant downside to anything like this (only thing to compare is how difficult it is to wrap, and they aren't done with that part yet).
For #2, there's actually a great story. You can literally run the JavaScript inside an existing engine, like Chrome or Firefox, and serve it from there. You can use the normal devtools and set breakpoints on the JS.
Re: First Impressions Using React Native
#143Earlier quoted context omitted.
Agree that singletons for Flux are bad, but they're totally not necessary (e.g. https://github.com/acdlite/flummox ). And if you don't like Flux, don't use it. I don't see how that's can be a demerit against React, since they're completely separate things.
React doesn't have a good pattern for passing information up the tree other than Flux. Prior to Flux they told everyone to pass functions through props which is fine up until a certain point but it doesn't scale to large apps. Flux does solve it, and is a generally good idea, but the singleton pattern breaks when applied to the server.
passing functions through props scales up to large apps fantastically better than any other not-React based approach I've ever used. I've done it.
Re: First Impressions Using React Native
#144I 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…
> the languages that compile to javascript are a poor substitute (bloated code sizes, interop issues, poor runtime performance, etc)
js_of_ocaml has good code size and performance in my experience. Interop with js is variable -- some js libraries are inherently typed and are easy to bind to in a well typed way, others use very dynamic typing and those are difficult to bind.
Re: First Impressions Using React Native
#145> "This is solid engineering . And it completely reinforces the fact that React.js is the right way to build apps." This just comes off as really weird to me. Why would any sane developer make a statement like this? It sounds preachy and brainwash-y and weird. If there's anything we learn as developers it's that there never is and never will be a single "right way" to do everything. Reading stuff like this makes me d…
My take on it having used React on the web for a year: I won't go so far as to say React is THE right way to build apps, but DOM mutation is definitely the wrong way. Having opinions about data flow, application structure, etc. is not preachy and weird; it's just software engineering, though I agree this particular opinion is stated in a particularly strong way.
Re: First Impressions Using React Native
#146Earlier quoted context omitted.
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 wi…
> That immutability leads to significantly more objects being allocated
What about shared immutable data structures?
Re: First Impressions Using React Native
#147Earlier quoted context omitted.
> 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.
Well, then. What about the language should make me think "wow, this actually is a great language"? And I mean the actual language itself, not the ecosystem around it.
With the exception of the bad parts that you have to remember to stay away from, it is a very simple language.
Re: First Impressions Using React Native
#148For me the best of the web has always been HTML & CSS which I miss so often when dealing with native widgets or creating my own. The only thing that used to scare me off the web was JavaScript. Give me a HTML & CSS frontend, please. But let me keep my beloved Scala or Swift ;)
Re: First Impressions Using React Native
#149Earlier quoted context omitted.
Well, then. What about the language should make me think "wow, this actually is a great language"? And I mean the actual language itself, not the ecosystem around it.
With the exception of the bad parts that you have to remember to stay away from, it is a very simple language.
By definition, if I have to remember to stay away from the bad parts, it can't possibly be that simple.
Re: First Impressions Using React Native
#150Declarative 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…
I've been against mixing logic and views for the longest time and I still wouldn't mind if separation would have been introduced, but recently I gave up. Either I'll be unnecessary stubborn and miss this awesome new tech or I'll shovel my opinion aside and do try working with this approach.... or at least until someone else introduces new framework that comes with code separation. It's not the end of the world.
Are user triggered events for a view part of the view, or something else? I think this is where such a separation of concerns comes in... a view is more than just how it is rendered, it is also events for the view. There are also child components, and handling these events, or encapsulating them into events to be triggered by a given view.
When you think of it this way, it makes sense. From a designer perspective it doesn't, and you have to adapt designs into a view, just the same, you usually do anyway.