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

161–170 of 195 posts

Re: First Impressions Using React Native

#161

Post by nkohari »

tootie wrote: post #152
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…

JSX mixing presentation logic and views seems to me like they have reinvented PHP. PHP is derided for this, but also for it's shaky implementation and semantics. JSX seems like Good PHP and that's a big deal because PHP is wildly successful despite being awful.

JSX isn't really HTML, though. It's a way to describe React components in a familiar syntax that resembles HTML. It's a far cry from concatenating strings of HTML like you do in PHP.

Re: First Impressions Using React Native

#162

Post by sanatgersappa »

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…

You're probably looking for Elm - http://elm-lang.org/

Re: First Impressions Using React Native

#163

Post by datashovel »

I get this weird feeling that React Native has been created as a stand-in until webview is truly ready to take over mobile. I can't imagine a scenario where by end of 2015 (or early 2016) mobile webview technology won't be sufficient for 99% of mobile apps.

Re: First Impressions Using React Native

#164

Post by haberman »

azakai wrote: post #60

I think it's a very strong point that moving script code off the main thread can help achieve smooth UIs. No more GC pauses, no more slowdowns if the JS engine hits a snag, etc. I think this is actually possible on the web as well. Someone could write a UI framework which runs JS in a Worker, and sends messages to the main thread, on which there is HTML and minimal JS to receive the messages and handle them. I'm surp…

> I think it's a very strong point that moving script code off the main thread can help achieve smooth UIs. No more GC pauses, no more slowdowns if the JS engine hits a snag, etc.

BeOS took UI multithreading farther than any other environment I've ever used. And it paid off: I still think it might be the case that BeOS on circa 2000 hardware was more consistently responsive than any environment I have used before or since.

More technical detail about BeOS's multithreaded UI design: http://arstechnica.com/civis/viewtopic.php?p=17348543&sid=e2...

Re: First Impressions Using React Native

#165

Post by underwater »

Touche wrote: post #140
jordwalke wrote: post #112

Earlier quoted context omitted.

Trust me, we tried. But as long as image decoding blocks the main thread (Webkit), you are helpless to update the UI thread at a fast pace. We even tried decoding images in a web worker and sending the result back to the main thread - but decoding in JS is very slow so general application throughput suffers (not through fault of JS itself, but because JS lacks SIMD which image decoding algorithms use in order to deco…

As for events, have the worker send which events it is interested in rather than the reverse as you suggest.

Event handlers are synchronous, and web workers are asynchronous. This means you have to decide whether you will prevent native behaviors before you have a chance to communicate with the web worker.

It's easy to be too aggressive. For example registering a `touchstart` on a DOM node would kill the native behavior and prevent scrolling, even if that's what you wanted. Of course, you could implement scrolling in JavaScript. That's a lot of work and you have to make sure the web worker doesn't block for more than 16ms so that the effect is smooth.

In my experience it's best to use native browser behaviors where possible. You get all sorts of benefits, like scrolling being executed on a separate thread, and don't have to rely on reimplementing everything from the ground up.

Re: First Impressions Using React Native

#166

Post by [deleted] »

Touche wrote: post #140
jordwalke wrote: post #112

Earlier quoted context omitted.

Trust me, we tried. But as long as image decoding blocks the main thread (Webkit), you are helpless to update the UI thread at a fast pace. We even tried decoding images in a web worker and sending the result back to the main thread - but decoding in JS is very slow so general application throughput suffers (not through fault of JS itself, but because JS lacks SIMD which image decoding algorithms use in order to deco…

As for events, have the worker send which events it is interested in rather than the reverse as you suggest.

[deleted]

Re: First Impressions Using React Native

#167

Post by grennis »

jenius wrote: post #113

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

I agree, this post seemed like an awkward sales pitch to me. Not even a single mention of any possible downsides to this approach. Just unicorns and rainbows.

Re: First Impressions Using React Native

#168

Post by arxii »

sounds interesting. not a fan on reacts workflow because i use jade templates w/ backbone that get compiled to html for me and its much less code, but separating javascript and native components into different threads is a great idea.

i believe we should be able to see javascript being used as a responsive language portable across all devices and being used to control native components as a separate layer.

im actually working with a flexbox xml/html wrapper framework for iscroll that i might use to build a responsive app that not only does pc animations but performs alot of nice mobile slider animations that seem to go at 60 fps on modern handhelds, but its up to emerging gapping technologies like cordova and this to make the use of future "responsive ui kits" which i believe should be emerging soon.

Re: First Impressions Using React Native

#169

Post by arxii »

jsprogrammer wrote: post #34

The code style really reminds me of ExtJS circa 2.x (not sure what it's like now), which was pretty good at what it set out to do. However, React Native requires compiling down to various different platforms which means having to maintain multiple compatibility layers to continually shift to keep up with the native vendors. You're also pretty much stuck with proprietary distributors as well. Fun. Fun. This does look…

this. i think the future is all about code flexibility. if your code is responsive and performs via stable hardware accelerated animations it will win because you only have to write it once. web will take over the mobile industry eventually, i can feel it.

Re: First Impressions Using React Native

#170

Post by aboodman »

seanmcdirmid wrote: post #157
aboodman wrote: post #139

Earlier quoted context omitted.

That isn't declarative in the same way... that's markup. The kind of declarative that is used in React is more like functional programs. You write programs, using actual code, that compute ("declare") exactly what the UI should look like from top to bottom, given each possible input. This is in contrast to a model where you mutate an existing UI model each time something interesting happens.

Declarative is a vacuous word that means anything you want it to depending on context. We used to call functional programming "functional" and logic programming languages like Prolog "declarative." Then declarative started meaning markup, then declarative started meaning...immutable functional code? In PL, we mostly just avoid the word altogether these days since everyone has a different idea about what it means. Rea…

I think that the reason people started calling React 'declarative' was because 'functional' was interpreted to mean (purely) functional, with no side effects.

But yes, exactly. React is similar to an immediate mode graphics API. Except that also has weird connotations, because people think of things like canvas that are very low-level: all you get are lines, arcs, and fills. React's primitives are at the same level of abstraction as the DOM, you just work with them in immediate mode, not retained mode.

Post reply on HN