Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

First Impressions Using React Native

jlongster.com

Post reply on HN
Print view View original

11–20 of 195 posts

Re: First Impressions Using React Native

#11

Post by yuchi »

Seriously please stop making assumptions on Titanium without knowing a thing about it.

> With the latter, you're also interfacing directly with native objects all the time, which is doomed to fail performance-wise. React Native actually performs the layout on a separate thread [...]

Wrong. With Titanium you work with proxies. And JS is in a separate thread. The only actual difference between ReactNative and Titanium on this side is the functional/fully-declarative/almost-stateless vs imperative DOM-like philosophy.

Let me slip this through: «if you don’t know something then don’t make it look like you do».

Sorry for the rant. I’m just very upset from yet another post like this.

Re: First Impressions Using React Native

#12

Post by tel »

saosebastiao wrote: post #3

I 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…

There's js_of_ocaml?

Re: First Impressions Using React Native

#13

Post by andyl »

saosebastiao wrote: post #3

I 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…

I write React components in Coffeescript - no JSX. Concise, easy to read and write - just works beautifully.

Re: First Impressions Using React Native

#14

Post by Touche »

saosebastiao wrote: post #8
danabramov wrote: post #4

Earlier 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…

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 javas…

First, all ClojureScript code is Closure compatible, you don't have to worry about that.

Secondly, Om in a Webview and Xamarin are not fair comparisons.

Re: First Impressions Using React Native

#16

Post by Touche »

danabramov wrote: post #2

Declarative 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…

It's too bad that you can't separate virtual dom, the innovative part of React, from the rest of React which has its warts. They should receive credit for coming up with the idea, but there are better, more reactive frameworks using virtual doms now. React shouldn't win simply because they were first and have a big company behind them.

Re: First Impressions Using React Native

#17

Post by rattray »

saosebastiao wrote: post #3

I 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…

Start shooting: http://funscript.info/

Have you given CoffeeScript a try? Bloated code size and interop issues are essentially nonexistent. Poor runtime performance is a non-issue with most C2JS languages because, well, they're compiled.

Re: First Impressions Using React Native

#18

Post by danabramov »

Touche wrote: post #16
danabramov wrote: post #2

Declarative 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…

It's too bad that you can't separate virtual dom, the innovative part of React, from the rest of React which has its warts. They should receive credit for coming up with the idea, but there are better, more reactive frameworks using virtual doms now. React shouldn't win simply because they were first and have a big company behind them.

Virtual DOM is an implementation detail of React for web.

Its true innovation is its declarative component model.

You are missing the point of React.

https://medium.com/@dan_abramov/youre-missing-the-point-of-r...

Re: First Impressions Using React Native

#19

Post by jordanlev »

> the mess of HTML and CSS get in the way of frameworks instead of helping them

I totally understand where the author is coming from, and do agree... BUT there is a flip side to this, which is that HTML and CSS enable us to come up with and implement totally unique designs and interfaces. The lack of standard layout and complex "widgets" is definitely a pain in the ass, but it also enables a lot of unique-looking websites and designs. It's kind of a pet peeve of mine when platforms/CMS's try to output markup instead of just providing data to the view layer... they are always outputting the "best practice" (if lucky) at the time they were built, and then a year or two later you want to do things a different way and you're stuck.

So I'm super excited about React.js and love the simple mental model with flux etc., but another part of me also worries that one can't dictate the markup exactly the way one wants because it has to be recognizable to the virtual dom as well (or the iOS view in native, or whatever other front-end React will output to). Maybe someone with more React.js experience can enlighten me about this though? (I've only dabbled).

Re: First Impressions Using React Native

#20

Post by jlongster »

yuchi wrote: post #11

Seriously please stop making assumptions on Titanium without knowing a thing about it. > With the latter, you're also interfacing directly with native objects all the time, which is doomed to fail performance-wise. React Native actually performs the layout on a separate thread [...] Wrong. With Titanium you work with proxies. And JS is in a separate thread. The only actual difference between ReactNative and Titanium…

I have a friend that uses Titanium a lot, so yes, I only know of it second hand.

The lack of a function/reactive componentized UI paradigm forces you to work with native objects (the views) a lot. React can optimize how much it touches the bridge because you don't interface directly with the UI. From what I've seen, Titanium can't do nearly as good of a job as that because it's like the DOM. You touch the UI in several places and it needs to always talk across the bridge.

I never said it doesn't run JS on a separate thread. React performs layout on a separate thread, providing the flexbox layout algorithm.

EDIT: It's all of these little details that can make or break something like this.

Post reply on HN