12 ms·

First Impressions Using React Native

539 points by jlongster 12y ago

danabramov 12y ago
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 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.
- Touche 12y ago
  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.
  - danabramov 12y ago
    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-react-a20e34a51e1a https://medium.com/@dan_abramov/youre-missing-the-point-of-r...
    - Touche 12y ago
      I don't know what you mean by "declarative component model", can you explain?
      - danabramov 12y ago
        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-Why-React-is-Awesome http://jlongster.com/Removing-User-Interface-Complexity,-or-...
        Touche 12y ago
        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.
        danabramov 12y ago
        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.
        Touche 12y ago
        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.
    - adrusi 12y ago
      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.
      - danabramov 12y ago
        >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.
  - rattray 12y ago
    You can: https://www.npmjs.com/package/virtual-dom https://www.npmjs.com/package/virtual-dom You should also check out Mithril: https://www.npmjs.com/package/mithril https://www.npmjs.com/package/mithril
    - Touche 12y ago
      I'm aware of these. But React gets all of the attention despite its warts like local component state or encouraging singletons for Flux.
      - danabramov 12y ago
        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.
        Touche 12y ago
        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%.
        danabramov 12y ago
        >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.
  - vog 12y ago
    I believe Riot.js provides a lightweight alternative: https://muut.com/riotjs/ https://muut.com/riotjs/
    - danabramov 12y ago
      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 https://github.com/muut/riotjs/blob/master/lib/view.js#L75
- Ronsenshi 12y ago
  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.
  - tracker1 12y ago
    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.
    - lumpypua 12y ago
      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.
  - lumpypua 12y ago
    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.
- xanadohnt 12y ago
  MS have been doing declarative UIs for literally 8 years (XAML).
  - aboodman 12y ago
    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.
    - seanmcdirmid 12y ago
      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.
      - aboodman 12y ago
        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.
        12y ago
- tootie 12y ago
  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.
  - nkohari 12y ago
    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.
saosebastiao 12y ago
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.
- danabramov 12y ago
  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 https://github.com/omcljs/om [2]: http://swannodette.github.io/2015/01/06/the-false-promise-of-javascript-microlibs/ http://swannodette.github.io/2015/01/06/the-false-promise-of...
  - saosebastiao 12y ago
    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.
    - Touche 12y ago
      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.
  - adrianm 12y ago
jobu 12y ago
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.
- jlongster 12y ago
  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.
coldcode 12y ago
Will React's concepts every make it as truly native code I wonder?
yuchi 12y ago
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.
- jlongster 12y ago
  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.
  - yuchi 12y ago
    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.
- peterhunt 12y ago
  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.
regularfry 12y ago
Soooo... Strap a code editor component on the front and call it Hypercard 9000?
jordanlev 12y ago
> 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).
- danabramov 12y ago
  >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.
  - jordanlev 12y ago
    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?
    - danabramov 12y ago
      >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 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 https://github.com/facebook/react/issues/140
api 12y ago
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.
- arxii 12y ago
  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.
deleted 12y ago
[deleted]
jsprogrammer 12y ago
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.
- martco 12y ago
  How is the real momentum going the other way (native -> Web)?
  - jsprogrammer 12y ago
    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.
  - egillie 12y ago
    Google Native Client is a big push for native -> web, though I haven't heard much about it lately...
- nwienert 12y ago
  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.
zkhalique 12y ago
OK this DOM stuff is great but what about the other HTML5 interfaces, like sending requests to the server, localStorage, etc. ?
- peterhunt 12y ago
  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.
  - Bahamut 12y ago
    Is the localStorage going to be something similar to IndexedDB (or localForage perhaps?)
    - peterhunt 12y ago
      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)
falcolas 12y ago
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?
- state 12y ago
  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.
crudbug 12y ago
This made me think differently => JS can be used as a control layer and the native components are the data layer.
malandrew 12y ago
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.
- untog 12y ago
  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.
azakai 12y ago
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-workers-today-and-faster-than-expected/ 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).
- untog 12y ago
  IIRC, Web Workers have a really limited subset of functionality available to them, which adds a whole load of gotchas to anything like this.
  - azakai 12y ago
    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.
    - untog 12y ago
      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.
- aikah 12y ago
  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.
pothibo 12y ago
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.
- akx 12y ago
  Except, you know, the App Store rules explicitly forbid downloading new code over the network.
  - misuba 12y ago
    Unless it's JavaScript. ...running in a WebView. So yes, RN apps will not enable this.
- spicyj 12y ago
  There's no technical reason it couldn't work, but we have no plans to load code over the network.
  - pothibo 12y ago
    I would have thought it would bring new A/B testing possibilities that would have been otherwise impossible. Oh well, thanks.
swanify 12y ago
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!
fidotron 12y ago
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.
- misuba 12y ago
  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.
mhd 12y ago
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.
- eliperkins 12y ago
  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-matters/ https://joshaber.github.io/2015/01/30/why-react-native-matte...
  - mhd 12y ago
    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?
    - eliperkins 12y ago
      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 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.
eclipxe 12y ago
Why not Titanium?
serve_yay 12y ago
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.
deleted 12y ago
[deleted]
GrinningFool 12y ago
"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.
jenius 12y ago
> "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.
- serve_yay 12y ago
  I like having opinions. People can disagree with them, of course, as has always been the case.
  - jenius 12y ago
    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.
    - serve_yay 12y ago
      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.
      - eitland 12y ago
        > 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.
crazychrome 12y ago
Do a Ctrl + F, then type "android". How many matches have you seen amongst 122+ comments? 2, including this one!
abalone 12y ago
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.
- jlongster 12y ago
  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.
bsaul 12y ago
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.
Taig 12y ago
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 ;)
akrymski 12y ago
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)
datashovel 12y ago
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.
arxii 12y ago
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.

539 points by jlongster 12y ago

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

Touche 12y ago
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.
- danabramov 12y ago
  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-react-a20e34a51e1a https://medium.com/@dan_abramov/youre-missing-the-point-of-r...
  - Touche 12y ago
    I don't know what you mean by "declarative component model", can you explain?
    - danabramov 12y ago
      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-Why-React-is-Awesome http://jlongster.com/Removing-User-Interface-Complexity,-or-...
      - Touche 12y ago
        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.
        danabramov 12y ago
        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.
        Touche 12y ago
        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.
  - adrusi 12y ago
    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.
    - danabramov 12y ago
      >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.
- rattray 12y ago
  You can: https://www.npmjs.com/package/virtual-dom https://www.npmjs.com/package/virtual-dom You should also check out Mithril: https://www.npmjs.com/package/mithril https://www.npmjs.com/package/mithril
  - Touche 12y ago
    I'm aware of these. But React gets all of the attention despite its warts like local component state or encouraging singletons for Flux.
    - danabramov 12y ago
      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.
      - Touche 12y ago
        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%.
        danabramov 12y ago
        >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.
- vog 12y ago
  I believe Riot.js provides a lightweight alternative: https://muut.com/riotjs/ https://muut.com/riotjs/
  - danabramov 12y ago
    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 https://github.com/muut/riotjs/blob/master/lib/view.js#L75
Ronsenshi 12y ago
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.
- tracker1 12y ago
  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.
  - lumpypua 12y ago
    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.
- lumpypua 12y ago
  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.
xanadohnt 12y ago
MS have been doing declarative UIs for literally 8 years (XAML).
- aboodman 12y ago
  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.
  - seanmcdirmid 12y ago
    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.
    - aboodman 12y ago
      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.
      - 12y ago
tootie 12y ago
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.
- nkohari 12y ago
  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.

saosebastiao 12y ago

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.

danabramov 12y ago
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 https://github.com/omcljs/om [2]: http://swannodette.github.io/2015/01/06/the-false-promise-of-javascript-microlibs/ http://swannodette.github.io/2015/01/06/the-false-promise-of...
- saosebastiao 12y ago
  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.
  - Touche 12y ago
    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.
- adrianm 12y ago

jobu 12y ago

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.

jlongster 12y ago
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.

coldcode 12y ago

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

yuchi 12y ago

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.

jlongster 12y ago
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.
- yuchi 12y ago
  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.
peterhunt 12y ago
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.

regularfry 12y ago

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

jordanlev 12y ago

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

danabramov 12y ago
>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.
- jordanlev 12y ago
  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?
  - danabramov 12y ago
    >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 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 https://github.com/facebook/react/issues/140

api 12y ago

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.

arxii 12y ago
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.

deleted 12y ago

[deleted]

jsprogrammer 12y ago

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.

martco 12y ago
How is the real momentum going the other way (native -> Web)?
- jsprogrammer 12y ago
  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.
- egillie 12y ago
  Google Native Client is a big push for native -> web, though I haven't heard much about it lately...
nwienert 12y ago
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.

zkhalique 12y ago

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

peterhunt 12y ago
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.
- Bahamut 12y ago
  Is the localStorage going to be something similar to IndexedDB (or localForage perhaps?)
  - peterhunt 12y ago
    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)

falcolas 12y ago

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?

state 12y ago
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.

crudbug 12y ago

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

malandrew 12y ago

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.

untog 12y ago
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.

azakai 12y ago

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-workers-today-and-faster-than-expected/ 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).

untog 12y ago
IIRC, Web Workers have a really limited subset of functionality available to them, which adds a whole load of gotchas to anything like this.
- azakai 12y ago
  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.
  - untog 12y ago
    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.
aikah 12y ago
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.

pothibo 12y ago

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.

akx 12y ago
Except, you know, the App Store rules explicitly forbid downloading new code over the network.
- misuba 12y ago
  Unless it's JavaScript. ...running in a WebView. So yes, RN apps will not enable this.
spicyj 12y ago
There's no technical reason it couldn't work, but we have no plans to load code over the network.
- pothibo 12y ago
  I would have thought it would bring new A/B testing possibilities that would have been otherwise impossible. Oh well, thanks.

swanify 12y ago

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!

fidotron 12y ago

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.

misuba 12y ago
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.

mhd 12y ago

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.

eliperkins 12y ago
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-matters/ https://joshaber.github.io/2015/01/30/why-react-native-matte...
- mhd 12y ago
  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?
  - eliperkins 12y ago
    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 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.

eclipxe 12y ago

Why not Titanium?

serve_yay 12y ago

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.

deleted 12y ago

[deleted]

GrinningFool 12y ago

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

jenius 12y ago

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

serve_yay 12y ago
I like having opinions. People can disagree with them, of course, as has always been the case.
- jenius 12y ago
  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.
  - serve_yay 12y ago
    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.
    - eitland 12y ago
      > 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.

crazychrome 12y ago

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

abalone 12y ago

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.

jlongster 12y ago
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.

bsaul 12y ago

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.

Taig 12y ago

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

akrymski 12y ago

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)

datashovel 12y ago

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.

arxii 12y ago

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.