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

21–30 of 195 posts

Re: First Impressions Using React Native

#21

Post by Touche »

danabramov wrote: post #18
Touche wrote: post #16

Earlier quoted context omitted.

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...

I don't know what you mean by "declarative component model", can you explain?

Re: First Impressions Using React Native

#22

Post by rattray »

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.

You can: https://www.npmjs.com/package/virtual-dom

You should also check out Mithril: https://www.npmjs.com/package/mithril

Re: First Impressions Using React Native

#23

Post by danabramov »

jordanlev wrote: post #19

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

>one can't dictate the markup exactly the way one wants because it has to be recognizable to the virtual dom as well

I'm not sure what you mean. On the opposite, with React, you specify exactly the DOM (or UIView) tree you want to get.

You will build different components for React web and React Native, there's no common ground between them. The platforms are too different.

Re: First Impressions Using React Native

#24

Post by Touche »

rattray wrote: post #22
Touche wrote: post #16

Earlier quoted context omitted.

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.

You can: https://www.npmjs.com/package/virtual-dom You should also check out Mithril: https://www.npmjs.com/package/mithril

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

Re: First Impressions Using React Native

#25

Post by danabramov »

Touche wrote: post #21
danabramov wrote: post #18

Earlier quoted context omitted.

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...

I don't know what you mean by "declarative component model", can you explain?

The mental model is much simpler because your `render` method describes UI at any point of time. Not just the DOM, but your own components too. On the inside, any component can have its own state, but from the outside, it's not visible, and components using it don't care or know about it.

Separating `props` and `state`, component boundaries, lack of two-way binding and predictable top-down data flow make it easy to reason about where any data comes from, and how UI will change over time.

Read this:

http://jlongster.com/Removing-User-Interface-Complexity,-or-...

Re: First Impressions Using React Native

#26

Post by api »

I'm looking forward to desktop UIs also being supported by something like this -- e.g. native Windows, GTK+, and Cocoa widgets. Then we'd have a true framework for writing GUI apps that can share most of their code across the whole range of platforms, which would make me literally stand up and start singing right now. Lalalalalalala!

If you coupled this with conditional stuff around what kind of form factor you're on (screen size, etc.) you could design mobile first UIs that gracefully enriched on a larger form factor. Lalalalalala!

I don't know of Facebook cares, but I WILL PAY FOR THIS! For a well-engineered modern platform that did all of the above I would pay thousands of dollars. So if the choice comes down to staying free and abandoning this effort vs. making it a profit center, please for the love of all that is holy take my money.

Really when you look at the labor costs of developing parallel UI efforts on many platforms, a cross-platform dev system that delivered a high quality native-feeling experience across every major platform could be worth at least tens of thousands of dollars to millions of people.

Re: First Impressions Using React Native

#28

Post by danabramov »

Touche wrote: post #24
rattray wrote: post #22

Earlier quoted context omitted.

You can: https://www.npmjs.com/package/virtual-dom You should also check out Mithril: https://www.npmjs.com/package/mithril

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

You can use Om if you like, right? Or Omniscient. Or Morearty.

Not everyone is ready to go into FP-land right now.

React lets you take these decisions yourself.

Whether local state is practical for your team or not.

You must be living in a very different world than mine if you think that compared to its rivals (Angular, Ember, etc), React is somehow “encouraging” local state. Sure you could go more functional than that, but take a look at the mainstream frameworks and you'll see it's such a long way to go, that had React not allowed local state, it would not have gotten adoption at all.

Re: First Impressions Using React Native

#29

Post by Touche »

danabramov wrote: post #25
Touche wrote: post #21

Earlier quoted context omitted.

I don't know what you mean by "declarative component model", can you explain?

The mental model is much simpler because your `render` method describes UI at any point of time . Not just the DOM, but your own components too. On the inside, any component can have its own state, but from the outside, it's not visible, and components using it don't care or know about it. Separating `props` and `state`, component boundaries, lack of two-way binding and predictable top-down data flow make it easy to…

This is true of all virtual dom libraries. There is no point of two-way binding when you have a virtual dom, and I'm not sure it even makes sense since you have to rerender the tree anyways.

So we agree, you're just separating the concept from the implementation and I'm talking about them as one.

Re: First Impressions Using React Native

#30

Post by danabramov »

Touche wrote: post #29
danabramov wrote: post #25

Earlier quoted context omitted.

The mental model is much simpler because your `render` method describes UI at any point of time . Not just the DOM, but your own components too. On the inside, any component can have its own state, but from the outside, it's not visible, and components using it don't care or know about it. Separating `props` and `state`, component boundaries, lack of two-way binding and predictable top-down data flow make it easy to…

This is true of all virtual dom libraries. There is no point of two-way binding when you have a virtual dom, and I'm not sure it even makes sense since you have to rerender the tree anyways. So we agree, you're just separating the concept from the implementation and I'm talking about them as one.

There's a difference between “virtual DOM” and components.

In React, components are not just functions that return their own virtual DOM. AFAIK for many vdom-based libraries this statement wouldn't be true.

React components may have local state (as much as some people hate it, some find it useful), they have a lifecycle, can react to receiving new props with side effects, can implement diff bail-out hook. And you can nest such components declaratively.

Post reply on HN