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

61–70 of 195 posts

Re: First Impressions Using React Native

#61

Post by jsprogrammer »

pjmlp wrote: post #56
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…

> I think this can either already, or very soon, be replicated on the web, a platform which holds tremendous advantages that native will likely never be able to catch up to. Looking at what HTML 5 offers and what any native platform from desktops to mobiles OS offers, I would rather stay with the disadvantages of native platforms. > while the real momentum is going the other way (native -> Web) Really? Is WebGL OpenG…

There will likely always be uses for the native platforms, especially on the desktop/power machines. I don't think React Native is targeting any of what you're talking about though.

What the web has going for it (and what native will never catch up to) is having solved the distribution problem. Fact is, I can deploy to more machines, faster, and more securely than native (at least if there remain fragmented vendors) ever will be able to. I can already access most sensors and can run shaders. It's not like it's difficult to get what's missing into the browsers either and all the native vendors are also spending the resources to develop the browsers.

Re: First Impressions Using React Native

#62

Post by untog »

malandrew wrote: post #59

This is yet another reason why you shouldn't use animations in CSS3 and should do them in JavaScript. I honestly don't understand how behavior (which is what animations are) got baked into a declarative style language. Layout (which is also behavior if the layout changes with the dimensions of the viewport) and animations are two things that need to be removed from CSS and implemented in JavaScript.

Well, "should" isn't a great word in this context.

Yes, animations probably should be in JavaScript, but you probably shouldn't do them in JavaScript right now as they won't be hardware accelerated. The reason it works well in CSS is that you're setting a property and letting native code do the rest, whereas in JS you need to set a property in each requestAnimationFrame() call. Not good.

Re: First Impressions Using React Native

#63

Post by untog »

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…

IIRC, Web Workers have a really limited subset of functionality available to them, which adds a whole load of gotchas to anything like this.

Re: First Impressions Using React Native

#64

Post by malandrew »

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.

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 the same layout. So much better than the react approach. Furthermore, the complete decoupling from the rendering functions and the reliance on using bijective lenses with shallow copying means you get time travel debugging for free (i.e. undo redo is available right out of the box)

https://github.com/Raynos/mercury

Re: First Impressions Using React Native

#65

Post by danabramov »

Touche wrote: post #47
danabramov wrote: post #30

Earlier quoted context omitted.

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…

The other libraries intentionally left out shouldComponentUpdate because they don't think it's something a developer should have to worry about. I don't know of any evidence to suggest that React is faster because of this feature. And declarative nesting is a feature of all of the frameworks I've come across, I'm not sure why you think that's unique to React. The advantage feature I would credit React for is the size…

>declarative nesting is a feature of all of the frameworks I've come across, I'm not sure why you think that's unique to React

Declarative nesting of lifecycle-ful and stateful components without going full FRP.

I'm actually excited to learn about other frameworks that do this! Which do you have in mind?

Re: First Impressions Using React Native

#66

Post by danabramov »

vog wrote: post #51
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.

I believe Riot.js provides a lightweight alternative: https://muut.com/riotjs/

Riot.js claims to use virtual DOM whereas, if you look into its source, it doesn't[1] and works with DOM directly.

It really has nothing to do with React's approach, at all.

[1]: https://github.com/muut/riotjs/blob/master/lib/view.js#L75

Re: First Impressions Using React Native

#67

Post by aikah »

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…

Is playcanvas using emscriptem or is it written directly in js? nice project by the way. Also what does the worker do? does it have access to the canvas context or it just does some calculations and communicate with the main thread via serialized data.

Re: First Impressions Using React Native

#68

Post by danabramov »

jordanlev wrote: post #52
danabramov wrote: post #23

Earlier quoted context omitted.

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

I can't seem to find it now, but I remember seeing something a few months back about support for some HTML tag being added to react. I could be wrong about that, though (which would be great). I guess my question is this: can React/JSX render any kind of well-formed arbitrary markup? Like if next week there is a html tag I want to use, will it work? Or would react have to be updated to "support it" somehow?

>I remember seeing something a few months back about support for some HTML tag being added to react.

It's just due to React https://github.com/facebook/react/pull/2830

There's still an attribute whitelist, and that's a trickier problem to solve: https://github.com/facebook/react/issues/140

Re: First Impressions Using React Native

#69

Post by pothibo »

I'm assuming React Native can load external JS files over the network? If that's the case, then I understand why Facebook is building this.

They could have control of their application and behavior and make even more changes than before without re-submitting to the App Store.

Re: First Impressions Using React Native

#70

Post by azakai »

untog wrote: post #63
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…

IIRC, Web Workers have a really limited subset of functionality available to them, which adds a whole load of gotchas to anything like this.

It is somewhat limited, but using message passing to the main thread, you can render a UI or even use WebGL or Web Audio or anything else. See the link for an example with WebGL.
Post reply on HN