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

181–190 of 195 posts

Re: First Impressions Using React Native

#181

Post by seanmcdirmid »

aboodman wrote: post #170
seanmcdirmid wrote: post #157

Earlier quoted context omitted.

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

If I understand correctly, the DOM is retained, and React brings abstracts it efficiently back to a immediate mode API with some state retention, which has benefits since things stay consistent automatically.

In contrast, a UI model like WPF uses (declarative) data binding to achieve something similar, but without as much flexibility and with more verbosity.

I'm working on a system that allows for state retention in an immediate mode model, though wrapping WPF rather than HTML:

http://research.microsoft.com/en-us/people/smcdirm/managedti...

Re: First Impressions Using React Native

#182

Post by akrymski »

peterhunt wrote: post #159
akrymski wrote: post #153

Earlier quoted context omitted.

what's wrong with -webkit-overflow-scrolling: touch? doing scrolling in js is so last year.

You can't build the equivalent of UITableView (which is a very important component in almost any iOS app) without frame-by-frame scroll events.

How so? Which feature of the UITableView can not be replicated in JS? I'm struggle to think of one. Swipe left/right to remove rows in a table can be done with touch events.

What am I missing?

Re: First Impressions Using React Native

#183

Post by akrymski »

jordwalke wrote: post #179
peterhunt wrote: post #159

Earlier quoted context omitted.

You can't build the equivalent of UITableView (which is a very important component in almost any iOS app) without frame-by-frame scroll events.

Exactly. Customizing exactly how a header bar "sticks" to the top when it hits a certain point, cannot be done with any built in browser scroller. The same is true of any animation that should happen in sync with the scrolling itself (think like a parallax fade/scale animation etc).

What most apps need can be done by listening to touch events instead of scroll events. Eg hiding the top bar when user started scrolling down and so on.

I can't even think of an app that has a parallax effect. If your app is required to have complex animations then web tech is not the right tech choice in general imo

Re: First Impressions Using React Native

#184

Post by on_and_off »

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…

That's my concern as well. ObjC and Java both have weaknesses. I routinely think about what is wrong in the mobile frameworks (Activity is a god object, null is a pain in the ass in Java, the various lifecycles you have to constantly worry about...) but if anything JavaScript looks like a big step back.

Re: First Impressions Using React Native

#185

Post by i_s »

jenius wrote: post #120
serve_yay wrote: post #118

Earlier quoted context omitted.

I like having opinions. People can disagree with them, of course, as has always been the case.

Look up the definition of the word "opinion" on google or a dictionary. Then look up the word "dogma". Then re-read my comment. Fair? It's not the opinion I'm objected to, it's the way of stating it.

Your grounds for disagreeing are bogus. Check out "How to Disagree" [0] by Paul Graham. You are at one of the lowest levels: "DH2. Responding to Tone."

[0] http://www.paulgraham.com/disagree.html

Re: First Impressions Using React Native

#186

Post by jordwalke »

akrymski wrote: post #182
peterhunt wrote: post #159

Earlier quoted context omitted.

You can't build the equivalent of UITableView (which is a very important component in almost any iOS app) without frame-by-frame scroll events.

How so? Which feature of the UITableView can not be replicated in JS? I'm struggle to think of one. Swipe left/right to remove rows in a table can be done with touch events. What am I missing?

I think you're not being specific enough. I am claiming they can perfectly be recreated in JS, just not within a mobile browser at the moment.

Re: First Impressions Using React Native

#187

Post by TheAceOfHearts »

jordwalke wrote: post #73
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…

We did a bunch of experiments with running React in a web worker. Maybe we should revive them. Because it's React, it ends up being easy and is basically the same setup (serialized events etc) as what React Native does.

Do you have any public examples? I have a use-case where I think this might make a lot of sense, so I've been toying with the idea.

Re: First Impressions Using React Native

#188

Post by akrymski »

jordwalke wrote: post #186
akrymski wrote: post #182

Earlier quoted context omitted.

How so? Which feature of the UITableView can not be replicated in JS? I'm struggle to think of one. Swipe left/right to remove rows in a table can be done with touch events. What am I missing?

I think you're not being specific enough. I am claiming they can perfectly be recreated in JS, just not within a mobile browser at the moment.

I do mean within a mobile browser. We have a pretty large app inside Cordova, and I've yet to get stuck where there's something I can't recreate. Would be interesting to see an example where a mobile browser falls short.

Re: First Impressions Using React Native

#189

Post by rnbwd »

jenius wrote: post #135
serve_yay wrote: post #122

Earlier quoted context omitted.

You're really just complaining about the phrasing of it and saying that it should have been worded in a mealy-mouthed way. That's silly, it's just an expression of an opinion.

This is absurd. Are you serious? The way you express your opinions is enormously important. It could easily be the difference between getting a raise and getting fired. Expressing your opinions in a way makes sense to other people and they take well to is the farthest thing from silly ever, it's like a #1 essential skill for life. On top of that, phrasing informs the message, and in this case I was not just complaini…

> The way you express your opinions is enormously important. It could easily be the difference between getting a raise and getting fired.

How is this relevant to the conversation? This isn't a letter to his boss, it's a blog post. Even so personality types differ vastly between individuals and your argument appears to be culturally conditioned in a different cultural. In other words, we live completely different worlds due to our cultural conditioning (or lack of - by that I mean our association with our inner voice).

> The first one is an absurd overarching dogma declaring every other app-building technology to be inferior to react with no backing whatsoever

It's just a matter of using the word 'a' vs. 'the'. We actually get it wrong MOST of the time. Replacing 'the' with 'a' provides much more clarity. For example, you could say 'Please bring me the green chair in the closet', but if there's more than one green chair? Well there's more than one 'right' way to build apps. React is 'a' right way to build an app. There are MANY wrong ways to build apps, and most web frameworks (in my opinion) build apps a wrong way. React is one of the few. That's how I feel.

I think you either have an ulterior motive for criticizing React itself (money, company), or you're just closed minded.

Re: First Impressions Using React Native

#190

Post by rnbwd »

malandrew wrote: post #64
Touche wrote: post #24

Earlier quoted context omitted.

I'm aware of these. But React gets all of the attention despite its warts like local component state or encouraging singletons for Flux.

And those singletons will bite you hard the moment you try to do server-side rendering because you will now have state shared across sessions. The approach that raynos/mercury takes where state is fully decoupled from layout/rendering is the way to go. In mercury, all the render functions are composed together to make one large pure function. You give it the current state and it deterministically will always render t…

I discovered React after using Om, and I believe that Mercury comes with a lot of good practices enabled by default. But it's technically possible to achieve the exact same 'decoupled-state-pure-shallow-etc' using React. It's just not turned on by default and some additional boilerplate is needed, so it's harder to achieve this in React. The only reason I use React instead of Mercury is that React is battle-tested. No amount of testing can replace the real-world situations.I choose a path of higher resistance because I trust React most (due to it's popularity and usage), even though Mercury is better in theory. Ultimately it's a pattern, and that pattern is associated with a level of abstraction over the DOM as well as the way we write code. Mercury and React are two examples of this. I would like to see more competition and libraries to choose from, modular DOM abstractions, with declarative UI's and alternative API's and jsx-esc transforms. That'd be awesome IMO.
Post reply on HN