First Impressions Using React Native | Hacker News Reader

First Impressions Using React Native

jlongster.com

539 pointsjlongster191 comments

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 surprised this hasn't been done, or has it and I just haven't heard about it?

If you're worried about the overhead of transferring lots of messages from the Worker to the main thread, I think it can be pretty fast actually. I did an experiment with proxying WebGL that way, which is a fairly high-traffic API, with nice results,

https://blog.mozilla.org/research/2014/07/22/webgl-in-web-wo...

For something rendering a UI, message passing overhead should be reasonable, especially if the framework is smart enough to only send over what changes (like React Native does).

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.

Oh, I know. But it's rare that a webapp does things computational enough that it's worth the extra overhead - most lagginess is actually at the UI level, in my experience (and why virtual DOMs are so popular now).

I've seen Web Workers used in things like graphing libraries, though.

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.

Playcanvas is written directly in JS, but does use an emscripten-compiled physics engine (bullet/ammo).

Serialized data. Workers currently can't have access to canvas contexts.

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.

Why wasn't this explored more before going full out with React Native? I feel like this would be smart to compare the two: web + webworkers vs native.

There was a lot of hype about hybrid apps "sucking", but I bet it doesn't once you get off the thread.

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 decode images quickly).

But running React in a web worker is still a really great idea. There would just be a lot of little edge cases to handle (like when you click a link - you need to prevent default of navigation, then send that link click to the web worker to see if your app wants to prevent default, if not, force the redirect back on the main thread). Having tight control over text editing might be challenging as well. These are difficulties, but I suspect they are a fixed set of challenges that are worth the increased parallelism in an increasingly multicore world.

But are web workers currently The Solution To All Our Mobile App Needs? No, but they're a great tool that are highly underutilized by JS developers, and that React is uniquely positioned to take advantage of.

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.

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.

You are speaking my language! I would love to see a prototype of this. I've been thinking about it since I saw React Native.

I wonder if there's even value in something like an asm.js-compiled layout system, which absolutely positions elements. One of the insights of React Native is that to build apps, we really only need a small subset of the web's layout algorithms. Only flexbox, really. So if we recognize this subset, and remove everything else, there main thread can focus on really smooth performance.

React Native even performs the flexbox layout on a 3rd thread, and tells the main thread where to absolutely position stuff.

Obviously we want to re-use as much of HTML as we can, but there might be some crazy ways to remove stuff from the main thread.

EDIT: It should be noted that Mercury, a React-inspired library (https://github.com/Raynos/mercury), has examples of running in a web worker. It is pretty cool, but I think it needs to be fleshed out more.

Me me! I'll be exploring this soon and I'm sure I'll reach out for help before I get too far. Could do a lot of stuff off thread, from data to layout calcs. My profile should have some info related to the hybrid stuff.

Very cool! I'll keep an eye on your work!

Me too.

I'd love to chat more about this with both of you, this seems like a direction definitely worth exploring.

Maybe we could set up a github project for it? Or talk in an issue on your existing repo, nwienert?

I'd like to see a github repo. You can hit me up on twitter, info in my profile. I think even just finding the right library to make using webworkers + npm + webpack would be great to start, because honestly its all the other stuff that slows down the thread. React can run on the main thread for the most part.

Some reading:

https://news.ycombinator.com/item?id=6982485 http://stackoverflow.com/questions/18056922/is-there-a-way-t...

Edit: webpack + webwoker: https://github.com/webpack/webpack/tree/master/examples/web-...

Cool, I set up a repo and started a wiki on it,

https://github.com/kripken/worker-ui/wiki

Not familiar with webpack, will take a look.

If you're interested in doing it with React, here's a video explaining how to do a custom backend: https://www.youtube.com/watch?v=eNC0mRYGWgc

You basically need to change BackendIDOperations and ReactEventListener to send/receive messages vs talking to the real APIs. It's already set up in the codebase to do this (because it actually worked at one time).

Webpack, per usual, already thought of this and has an answer for you :) https://github.com/webpack/worker-loader

Sweet. I'll watch out for wherever you guys end up.

Might be worth reading one of the react native devs about why animations might still be hard: http://jlongster.com/First-Impressions-using-React-Native#co...

This idea is also why I hooked up the css-layout project (https://github.com/facebook/css-layout) to a live demo to play around with: http://layout.jlongster.com/

Yes, in browsers, JS animations are still hard (I might even say impossible to do well for large apps with a lot going on). One anecdote: I spent a month trying to build a 60fps scrolling list view in JS from scratch (JS driving all the animations). No matter how hard I tried, I couldn't make it work on the web. I believe it was image decoding interfering but it's difficult to say why. Then I took that same example, which by that point was optimized, and ported it to React Native in a few hours(where we have off-thread image decoding and timers I can trust) and the example was like butter.

Now of course, I had hand optimized the performance, but my point is that on the web, there was nothing I could do, and with React Native, there was something I could do to make animations smooth. This is not to say you should be doing animations in JS, but if you want highly customizable interactions that can be immediately stopped by a touch processed in JS, you should try it out and see how it feels. For things that are "fire and forget", or platform specific, you should try using CoreAnimation/keyframes etc which protects the animation from your business logic.

Interestingly, this comment, while probably being of the most technical detail / value in the thread, was downvoted by someone :)

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.

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

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.

Right, but then you're susceptible to animation stutter and you have to reinvent the look-and-feel of the platform, which is extremely difficult.

Also worth looking at some ideas we have for doing cross-thread component hierarchies in React:

https://github.com/reactjs/react-future/tree/master/05%20-%2...

oh nice, thanks for mentioning this.

We explored this at a previous company I worked at. The conclusion at the time was that the message passing model was not yet efficient enough at the time because of serialization/deserialization which nullified any performance gains. Transferrable objects at the time were really new. If the support for shared memory has improved, it might now make sense.

The biggest problems with performance are:

- GC pauses

- triggering reflow

- marshalling data across interfaces (serialization/deserialization of native types into strings and back again).

That last one is an absolute killer when it comes to applying 3D matrix transforms. Basically, you're taking an array of floats, serializing them into a string to do an element.style property assignment, so that the browser can then take that stringified representation and convert it back into an array of floats that it can apply. Huge perf hit here.

You can now transfer typed array data using the newest postMessage API. http://updates.html5rocks.com/2011/12/Transferable-Objects-L...

I haven't found serialization to be anywhere near the bottleneck. How long does it take to serialize/deserialize a 16 element array? I could see how this would be an issue if you had hundreds of them per frame. But for most purposes an entire 16 element array is overkill and you could probably come up with a more compressed description of the transforms (scale, rotate, translate) and consider adding a pooling layer.

People attribute pauses to GC, when it's sometimes just the browser container environment acting up and there's nothing we can do about it - so it's easy to write it off as GC. Not sure about today, but 1.5 years ago (i = new Image(), i.src="http...") could block the JS thread for as much as 19ms. In a larger app, it's easy to write that off as GC, but (at least on iOS) the performance tooling is really lacking and it's tough to find the culprit.

Reflowing is a big deal, I agree.

Blowing out texture memory accidentally was also a big deal when I was measuring this stuff.

Basically if you want to prevent reflowing you end up making everything a texture and that leads you to making many many CSS transform changes on every frame. 60fps is easy to hit on a modern desktop, but mobile performance requires more effort to achieve an effect that feels natural. The problem with the marshalling is that it is comparatively expensive and a blocking operation, which is not conducive to buttery smooth graphics performance on all platforms.

I am not a maintainer and I just tried it briefly so I am not 100% sure of the allegations they make on their front-page, but it seems like http://gridstylesheets.org are using Workers to run their layout algorithm (Cassowary Constraint Solver) and absolute-position elements (using 3D transforms).

EDIT: Searching for "Worker" right now didn't bring any mention, but it seems it is a very recent edit (cf https://github.com/gss/gss.github.io/commit/d6a931e3629d4b5d...).

Regarding moving script code off the main thread: I wrote a cooperative FRP engine that multiplexes signal graph update recalculation onto Web Workers. UI updates like virtual DOM would live on the main thread.

https://github.com/Johnpmayer/liquid-thorium

> I'm surprised this hasn't been done, or has it and I just haven't heard about it?

N2O framework might do that.

https://github.com/5HT/n2o

Book:

https://synrc.com/apps/n2o/doc/book.pdf

One pattern you can do is send events to the server, server renders data asynchronously (maintains state for each client in a lightweight process), then ships result back to client via websocket binary frames.

You also decide how much rendering happens where. Can even do whole HTML elements on the server if you want.

I've been thinking about this as well yesterday, but to be honest I'm not sure where the benefits are. In theory the browser is doing the rendering in a separate thread anyway, i.e. CSS layout and things like scrolling are handled by the browser. If you're doing a long algorithmic (CPU-intensive) computation in JS then you should probably do that in a WebWorker anyway. Otherwise I'm not sure the overhead is worth it, for example the dragging / touch events should be invoking such a tiny amount of javascript that you shouldn't see much benefit in moving that logic to a separate thread.

Would be interested to see real examples of where this is makes sense.

Disclosure: we're developing an email client using Cordova and purely web tech using our own framework: https://github.com/techlayer/espresso.js

Exactly. I think moving everything but React into the web worker is enough. But that itself isn't easy as far as my limited knowledge, you need to have separate script files. Perhaps a webpack plugin that manages that for you?

I think simply moving any function that takes more than 10ms to a web worker is enough frankly.

> I think it's a very strong point that moving script code off the main thread can help achieve smooth UIs.

What, you mean like we do in Servo? https://github.com/servo/servo :-)

Our main thread (if you can call it that) just does compositing and handles dispatching UI events. Script, layout, resource loading, and the rest run concurrently in background threads.

That's amazing. I hadn't even though about Servo in light of all of this.

In current browsers, JavaScript runs in the same thread as the UI, right? In Servo, how do you do interaction with the DOM like `clientHeight`? It just pauses the entire JS engine while it goes and talks to the UI thread?

Maybe we should be thinking of all of this in terms that map well to Servo's current architecture.

EDIT: What's really exciting about Servo is that hopefully the architecture's parallelism is really sound, even if certain properties of the current web restrain it. Then we can work on ways to remove those properties, and in Servo it's a simple switch to turn on more and more parallelism.

> In Servo, how do you do interaction with the DOM like `clientHeight`? It just pauses the entire JS engine while it goes and talks to the UI thread?

Yes, but we'd like to experiment with new APIs in the future like `getBoundingClientRectAsync()` that will allow pages to do that kind of thing asynchronously.

I'm also interested in Servo as well. With React Native, we had the liberty to restrict certain paradigms that don't map well to building a parallelizable pipeline of operations. So the JS thread can't synchronously query for layout, which happens in the next stage, and the layout stage can't synchronously block on reading main thread (UIKit etc) values.

By restricting what the programmer can do, it naturally formed a pipeline where layout can be performed in the second stage while JS is determining the next UI update and so on. I'm not sure the extent to which this benefits us right now, but even mobile devices are beginning to have four cores so it seems like a nice property to maintain as long as it doesn't cause problems.

Servo sounds cool, and I'm curious how it takes advantage of a similar architecture but while the programmer has free reign to "clog the pipeline" by synchronous queries on layout etc. I'm sure they've thought of it, I'd just like to hear what they came up with.

I just asked pcwalton in #servo on mozilla and he said they want to introduce async versions of all of the DOM APIs like getBoundingClientRectAsync()

Awesome. That's exactly what we have on React Native :D We want to make sure that when possible, we choose APIs compatible with the future of the web.

Pedestal Client from Cognitect did this - see https://github.com/pedestal/app-tutorial/wiki/Parallel-Proce... and my notes at http://pchristensen.com/blog/articles/pedestal-tutorial-part... (under "Parallel Processing").

Too bad they stopped working on it.

Someday you'd think they might just go ahead and add multi-threading, shared memory to Javascript? It is definitely a can of worms, but the current web worker situation is just not workable for many use cases.

WPF has a UI and a separate closed off rendering thread, which works quite well performance wise.

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

> "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 doubt the entire article.

There's a difference between writing objectively about something that's interesting that you enjoyed, and trying to lay down a dogma. TBH, the more of this article I read, the more my view of it's goals swayed towards the latter.

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.

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.

> You're really just complaining about the phrasing of it

So far correct.

> and saying that it should have been worded in a mealy-mouthed way. That's silly, it's just an expression of an opinion.

Don't act like something is decided when it's not. Don't say something is 0.0 mm when you measure using using a ruler. Basics in politeness and engineering, isn't it?

Some might find it really annoying to discuss with people who use very strong statements after so short time.

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 complaining about the phrasing, I was also complaining about the outrageous statement being made.

For example, saying "React is the best way to build all apps no matter what" vs. saying "Compared to building native UIs with objective C, react-native made for a much smoother experience for me because of X Y and Z" are not only phrased differently, they are communicating different things. The first one is an absurd overarching dogma declaring every other app-building technology to be inferior to react with no backing whatsoever, and the second one is a useful and specific analysis of react in one situation compared to an alternative.

I can't figure out if you're trolling or not, honestly.

> React is the best way to build all apps no matter what

When you alter a quote, you're only illustrating your own bias, not that of the author.

Is your reply a good example of how to a express an opinion?

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

I think we would do well to apply the principle of charity here instead of having an (frankly boring) argument about semantics. Surely the author does not plan to use React forever and just meant that it's the best way to write web apps right now (which is a defensible opinion).

https://en.wikipedia.org/wiki/Principle_of_charity

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

My take on it having used React on the web for a year: I won't go so far as to say React is THE right way to build apps, but DOM mutation is definitely the wrong way. Having opinions about data flow, application structure, etc. is not preachy and weird; it's just software engineering, though I agree this particular opinion is stated in a particularly strong way.

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.

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”, you're missing out. Engineers embracing React are not dumb. You should consider a possibility that they think it's good for a reason, and that reason is something you should learn about instead of armchair-rejecting it.

Try tuning out your inner rule-of-thumb linter for a weekend and really give it a try.

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?

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

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.

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 of its community and influential advocates like you.

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

WPF (even completely ignoring XAML), JavaFX both support declarative nesting with interesting databinding features to support it. They are based on retained scene graphs, however.

If you are interested in academics, I published such a system at ECOOP in 2006:

http://research.microsoft.com/pubs/179366/mcdirmid06superglu...

The "declarative component model" is not an innovation, it's an obvious approach that has been used for ages when prototyping. You can achieve the same conceptual model of your interface by just generating the entire HTML of the page and rerendering it whenever something changes. This obviously doesn't perform and has some edge cases where it breaks things (textboxes, for example), but the idea is the same as react's components.

FRP is based around the idea of declarative components, but a lot of developers have an aversion to it because of the academic aura around it.

React's innovation is using virtual DOM to make declarative components usable without delving into FRP.

>FRP is based around the idea of declarative components, but a lot of developers have an aversion to it because of the academic aura around it.

Not just that. I may be stupid but personally I find it mentally simpler to `setState` than to `flatMapLatest`. To each their own I suppose.

>React's innovation is using virtual DOM to make declarative components usable without delving into FRP.

Precisely.

>The "declarative component model" is not an innovation, it's an obvious approach [..] can achieve the same [..] by [..] obviously doesn't perform and has some edge cases where it breaks things (textboxes, for example), but the idea is the same

React is not an academic paper, it's a tool. It doesn't need to have new ideas, it needs to execute on them in a practical way. Which it does.

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.

There are going to be lots of different types of frameworks that encourage different patterns all backed by this concept. I'm not saying React is the worst of the bunch but I also don't think it's clearly the best.

All I'm saying is that when people praise React I wish they were really praising what you call "declarative component model".

React is receiving 100% of the attention in this space when imo it should be receiving about 75%.

>All I'm saying is that when people praise React I wish they were really praising what you call "declarative component model".

I long for time when these concepts are boring enough no one thinks of React anymore. Sadly we're not there yet.

Yeah, I'm pretty sure it should at least be about 76%.

Agree that singletons for Flux are bad, but they're totally not necessary (e.g. https://github.com/acdlite/flummox). And if you don't like Flux, don't use it. I don't see how that's can be a demerit against React, since they're completely separate things.

React doesn't have a good pattern for passing information up the tree other than Flux. Prior to Flux they told everyone to pass functions through props which is fine up until a certain point but it doesn't scale to large apps. Flux does solve it, and is a generally good idea, but the singleton pattern breaks when applied to the server.

Ah, I see. I don't really agree, because I think the enforced unidirectional data flow is one of the best parts of React, but that's certainly a valid point of view.

I just want to emphasize again that Flux is entirely possible without singletons, and works just as well on the server if you create new instances for every request. Flummox does it, Fluxible does it (at least for stores). It's just a shame Facebook pushed singletons and then everyone followed their lead.

Honestly I think FB put the flux pattern out before that idea had become fully developed looking for feedback from the community. The flux repo explicitly states that none of the examples are used by facebook or even resemble facebook (client-side) code. The dispatcher, which was released months after they announced flux, is the only component in the flux they admit to using. Immediately after it's release (even before the dispatcher) we began writing client-side javascript code based on arbitrary examples meant to demonstrate a concept.

I also think flux's real-world implementation came from the necessity to build React components within pre-built apps, where they simply didn't have the ability to pass down props because they had to create complete separate components.

passing functions through props scales up to large apps fantastically better than any other not-React based approach I've ever used. I've done it.

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

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.

Ractive also uses a virtual DOM. http://www.ractivejs.org/ I found the blog pretty useful for comparing to React: http://blog.ractivejs.org/posts/whats-the-difference-between...

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

I've been against mixing logic and views for the longest time and I still wouldn't mind if separation would have been introduced, but recently I gave up.

Either I'll be unnecessary stubborn and miss this awesome new tech or I'll shovel my opinion aside and do try working with this approach.... or at least until someone else introduces new framework that comes with code separation.

It's not the end of the world.

Are user triggered events for a view part of the view, or something else? I think this is where such a separation of concerns comes in... a view is more than just how it is rendered, it is also events for the view. There are also child components, and handling these events, or encapsulating them into events to be triggered by a given view.

When you think of it this way, it makes sense. From a designer perspective it doesn't, and you have to adapt designs into a view, just the same, you usually do anyway.

I think you've got it exactly backwards. Events are not part of the view.

Events happen to be triggered by the view and they affect global state which is then reflected in the view.

This is the separation of concerns you want. Components don't need to know about events beyond triggering the ones they need. Components only worry about rendering state.

The react philosophy of the world is that mixing mutable state and views is bad, logic and views is fine. To be honest this makes a lot of sense to me as a functional programmer.

After learning react something conked in my brain. As I rehashed the arguments against logic in views, I realized that they recapitulated FP's arguments against uncontrolled mutable state, just without the nuance. Nothing wrong with purely functional logic/computation itself. And that delineation feels a lot less arbitrary than "logic in views is bad".

To be clear, I'm not arguing you should implement domain logic in your views. That's a dumb strawman.

But the religious fervor that people have against logic in views is absurd. Reexamine why you think logic in views is bad, and I think you'll find the arguments are actually against 1. poor factoring resulting in ridiculously complex views (and hiding logic is a halfass, crappy way to control complexity) or 2. mutable state.

MS have been doing declarative UIs for literally 8 years (XAML).

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.

React is closer to an immediate-mode UI model: you write programs that compute exactly what the UI should look like on each frame, rather than mutating a scene graph each time something interesting happens (as occurs in retained-mode UI models). Substitute DOM for scene graph, and the distinction might hold.

But I'm not sure.

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.

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

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.

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.

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.

For sure there’s this «don’t cross the bridge» paradigm in the community, yet I’ve never actually experienced this issue. In our biggest app, an SFA that grew other time in a big fat ass app (project that I’m quitely waiting to chop in different pieces/apps) the kind of performance issues we found we’re related to managing tableviews of… 20'000 rows! And then we switched to dynamically loaded listviews and boom. No perf issues at all.

The issue with Titanium is the direct manipulation of view objects via the proxies.

Much of what makes React Native special is that everything -- from the original React API all the way to the latest and greatest bridge stuff -- has been designed with the assumption that the bridge (DOM) is the bottleneck so everything is batchable and async.

The API that Titanium gives you is much more traditional OOP which means that developers can easily create applications that chatter over the bridge.

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.

yep agree 100%. i have been thinking a lot about high quality responsive hardware accelerated layouts myself and have actually been thinking and experimenting on how to make something like that on a primitive level with the technology at hand for making responsive apps.

I honestly believe you will be able to see something like that in the near future as device gapping technologies gain more momentum.

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 language. I would kill to be able to do React in F# or OCaml.

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/the-false-promise-of...

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

I have used cljs for non-mobile web interfaces, but the performance of Om in Phonegap on mobile hardware was terrible enough that I scrapped it for Xamarin.

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.

Om is fast at checking if a component's state has changed because you can do a very fast identity comparison on the persistent hash map holding state, but persistent data structures are not faster than their mutable cousins simply because of immutability. That immutability leads to significantly more objects being allocated, which means to really take advantage of these features in a managed language you need a VM with a very high performance garbage collector. This is partly why Clojure on the JVM works so well. That being said, non JIT compiled JavaScript VMs generally provide terrible performance for ClojureScript. I do not believe JavaScriptCore JITs anything, so I don't know how immediately useful ClojureScript with React Native will be outside of toy examples.

Fair points.

> That immutability leads to significantly more objects being allocated

What about shared immutable data structures?

Clojure uses structural sharing of course, but that was taken in to account in the parent comment. It's still a lot of allocation.

> It is a terrible language

As Douglass Crockford says, JS is a great language with some terrible parts. I don't understand why some people can't get past that.

Because many people use the terrible parts.

Except that it's not.

Having many different parts by itself is enough to make a language bad. The fact that some of the most important of those parts are basic makes it terrible.

Well, then. What about the language should make me think "wow, this actually is a great language"? And I mean the actual language itself, not the ecosystem around it.

With the exception of the bad parts that you have to remember to stay away from, it is a very simple language.

By definition, if I have to remember to stay away from the bad parts, it can't possibly be that simple.

There's js_of_ocaml?

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

I use CoffeeScript with JSX. It's even more easy to read and write. https://github.com/jsdf/coffee-react

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.

> I would kill to be able to do React in F# or OCaml.

Websharper (http://websharper.com/) for F# is now Apache-licensed and comes with the UI.Next framework that provides a really nice reactive paradigm for creating web UIs. Unfortunately it doesn't help with mobile apps as React Native does but is still pretty good.

That shouldn't be a big problem.

Since the JS execution is isolated on a single thread and communicates with the main thread via a bridge, it should be possible to implement the rendering code, vDOM diffing, bridge etc in any language you want. That might take some effort, but I can't see any fundamental reasons why it wouldn't work.

> the languages that compile to javascript are a poor substitute (bloated code sizes, interop issues, poor runtime performance, etc)

js_of_ocaml has good code size and performance in my experience. Interop with js is variable -- some js libraries are inherently typed and are easy to bind to in a well typed way, others use very dynamic typing and those are difficult to bind.

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

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.

Sounds amazing... What are the challenges, limitations, and tradeoffs for using React Native? There have been similar initial reviews of Titanium, Phonegap, and Xamarin, but in my experience they all have serious issues that make native development a better option in most cases.

There's always going to be the big drawback of working in a separate VM (JavaScript) rather than directly accessing native APIs. But React is taking advantage of that as much as possible, making it easy to refresh everything and allowing you bring everything you knew about React.js over.

But if you want to access an API, you still need to wrap it. Depending on the API, you need to be careful performance-wise. Native React avoids a ton of problems that other frameworks have though because they provide a solid mechanism for dynamically working with UIs, and it's very efficient because they only send minimal diffs across the bridge.

Probably the most useful way to get a read on this is to compare it to Titanium, also a JS-to-native framework that runs JS on a separate thread. The biggest problems with Titanium were not performance. A couple of the most common complaints:

1) You don't have full access to native SDK functionality (e.g. all the latest cool things in iOS8). You're going through a cross-platform API wrapper and limited to the choices of the framework architect. So it can be frustrating to go down this path only to find you still can't quite get the native experience you want.

2) Debugging is harder because the native toolchain (e.g. Xcode) doesn't understand the framework. You have to rely on tools provided by the framework.

AFAICS the author doesn't address these issues. He seems to focus largely on the (theoretical?) performance optimization of not crossing the JS-to-native bridge as much in React... by being even more isolated from the native APIs and doing more work in JS. But even if true, performance was not the chief complaint with the closest predecessor to this.

They are working on web-like APIs so you don't have to necessarily deal with the native platform for basic stuff like file/network access, etc. For more advanced stuff it's super simple to make your own wrapper. But yes, this is a constant downside to anything like this (only thing to compare is how difficult it is to wrap, and they aren't done with that part yet).

For #2, there's actually a great story. You can literally run the JavaScript inside an existing engine, like Chrome or Firefox, and serve it from there. You can use the normal devtools and set breakpoints on the JS.

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

>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 <doohickey> 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 <=0.12 using an HTML tag whitelist to tell native tags from custom components. It's not an issue anymore in 0.13, where any HTML tag (including custom Web Components) will work: 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

Ah, that makes sense. Thanks!

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.

So if this is native widgets etc., the main point is being able to write this in JavaScript, right? Anything in it for those who don't consider this inherently beneficial?

Souns a lot like GWT, s/Enterprise "architects"/Web "ninja"/ to me.

It's not about "Write once, run everywhere" but rather about "Learn once, write everywhere". React-Native encourages better design patterns for UI, especially on iOS.

This blog post summed it up perfectly for me: https://joshaber.github.io/2015/01/30/why-react-native-matte...

I don't get the "better design pattern" from that. And even worse, adding yet another piece on top of the stack (a "better language" transpiling to JS) instead of just doing "react" in the native environment?

Doing "react" in the native environment is hard, you have to fight UIKit really hard to get to a good place.

[ReactiveCocoaLayout](https://github.com/ReactiveCocoa/ReactiveCocoaLayout) is a good example of how much work it takes to get close to this pattern, but the view lifecycle as a whole (adding and removing subviews, layout passes, etc.) makes it hard.

From what I understand React-Native does this for you natively under-the-hood, but using JS as an implementation detail.

I really don't think that anyone is advocating for JS being the "better language", but rather one that has a framework (read: React.js) being used in practice which will work with native view as well.

OK, so how long before we backport the Android UI toolkit to WebGL using GWT and get rid of HTML and CSS altogether? Or even just write a sane new one?

Very interesting that this stuff comes from Facebook, who have very little concern about being indexable by search engines.

And yet React for Web browsers is the first framework in its class to do server-side rendering out of the box... a feature Facebook doesn't even use. Pretty funny.

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 interesting, but honestly, 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. Perhaps there's an argument that these apps can also be translated to the web when their time comes, but I wonder what sacrifices are being made in the name of going Native?

React Native seems to be an attempt to fight in the opposite direction (Web -> native) while the real momentum is going the other way (native -> Web), and the best part is, you don't even have to do anything to get it, the major players are building that open ecosystem for us.

How is the real momentum going the other way (native -> Web)?

Those who have created the native environments (Google, MS, Apple) are also creating the browsers, with another big player thrown in (Mozilla). Facebook makes web applications, has no native environment, and is trying to swim the other way.

Google Native Client is a big push for native -> web, though I haven't heard much about it lately...

I agree with the "swimming the wrong way" sentiment, in my own very biased opinion. I'm working on reapp.io to solve just that. What's funny is react actually makes it possible to make hybrid a real option.

That looks pretty interesting. Are there any plans to support responsive designs? What I really need (don't we all?) is a unified desktop & mobile code base.

Very interesting looking! One thing though is that the back button looks a little wonky in the Kitchen Sink demo.

> 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 OpenGL 4.5 compatible already?

What about those sensor APIs?

Oh, which browser is doing OpenCL and CUDA?

Web is stuck in a 90's desktop feature level and it will always be playing catch up native.

The real direction is web -> native/micro-services.

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.

> What the web has going for it (and what native will never catch up to) is having solved the distribution problem.

apt-get, yum, app stores, click once, web start, ...

Right: fragmented, environment dependent, user learning curve, etc.

Web: URL + links

Web: Network always on required (offline apps is a joke), code behind a pay wall, data behind a pay wall, forced upgrades, removal of features without respect for the users, no guarantee of availability

>3 minute installer with possible malware

>a url

pick one

You forgot

>a url with a JavaScript exploit

>a url with a img/css browser buffer overrun

>a url with cross site scripting

I see no difference.

EDIT: Actually I do. I is easier to exploit users that can't wait 3 minutes.

I suspect your perspective is a bit skewed as most companies are building native apps first and only doing a webapp when / if it becomes necessary. Native apps have won the this round and their momentum isn't slowing down. IIRC, Facebook is seeing 78% year over year growth on their mobile app, while desktop usage is declining. Instagram is another huge use-case where the web app is a second-class citizen.

What "most companies" are doing is mostly irrelevant in the larger picture. You're talking about proprietary networks and how they are shuttling their users around, while the interesting things are the opening up of real information and creating linked, collaborative, open ecosystems where everyone is free to participate. That's happening on the web, not in Facebook's latest iOS offering.

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.

As someone who has developed many apps using Appcelerator Titanium, I am looking forward to getting my hands on this to see where the differences lie.

I know that it has taken Titanium years to mature, so I wonder if it will take a similar amount for React to iron out the bugs - I'll be surprised / pleased if they hit the ground running.

Hopefully they'll hurry up and make it public!

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.

Except, you know, the App Store rules explicitly forbid downloading new code over the network.

Unless it's JavaScript.

...running in a WebView. So yes, RN apps will not enable this.

There's no technical reason it couldn't work, but we have no plans to load code over the network.

I would have thought it would bring new A/B testing possibilities that would have been otherwise impossible. Oh well, thanks.

    "React Native actually performs the layout on
     a separate thread, so the main thread is as free
     as it can possibly be to focus on smooth animations 
     (it also provides flexbox for layout,
     which something that no other framework provides)"

Interestingly - though perhaps increasingly less relevant - this is how BlackBerry 10 platform native QML-based applications work as well.

I can't help but feel that all this energy would be better spent on improving webkit itself (such as running JS in a separate thread to the UI)

For me the best of the web has always been HTML & CSS which I miss so often when dealing with native widgets or creating my own. The only thing that used to scare me off the web was JavaScript. Give me a HTML & CSS frontend, please. But let me keep my beloved Scala or Swift ;)

I'm still very excited to try it. I agree that this is the way forward for writing apps. I have attempted to write iOS apps before, and the problem is not objc, I actually kinda like objc. The problem is the damn view layer.

Didn't we do this already with Qt? Or Java? Or wxWidgets? Or OpenGL? Seems like cross-platform UIs have been a reality for quite some time.

What does React bring to the table that these do not?

Isn't it just the specific platforms you can target? I think the point is that there's nothing that can target the browser and the phone this successfully.

Wonder if the ability to easily refresh the view will make a difference to ios dev used to the wysiwyg approach by xcode for building views.

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.

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.

Soooo... Strap a code editor component on the front and call it Hypercard 9000?

Do a Ctrl + F, then type "android". How many matches have you seen amongst 122+ comments? 2, including this one!

This made me think differently => JS can be used as a control layer and the native components are the data layer.

Why not Titanium?

Will React's concepts every make it as truly native code I wonder?

OK this DOM stuff is great but what about the other HTML5 interfaces, like sending requests to the server, localStorage, etc. ?

There is an API-compatible XMLHTTPRequest so all libs that have those deps (Backbone) work.

There is also localStorage (not in this release though), but it's not 100% compatible because it has an async API.

Is the localStorage going to be something similar to IndexedDB (or localForage perhaps?)

When I was at FB it was just getItem() and setItem() with a callback. The Relay stuff announced at React.js Conf is closer to what you're talking about (they run a local GraphQL engine which reconciles with the remote one iirc)

Reply on news.ycombinator.com