[aleem]

If you haven't already, you should be betting on React. It's the future:

> More importantly, this paves the way to writing components that can be shared between the web version of React and React Native. This isn't yet easily possible, but we intend to make this easy in a future version so you can share React code between your website and native apps.

Isn't this what we have all been waiting for? Writing components that are composable, that are "isomorphic or universal", that can run on Native or DOM without any downsides of it's predecessors.

Aside, the article also mentions a migration tool [1] to help you port your code from 0.13 to 0.14. While others may have done so before, it's pretty cool that this is streamlined as part of the beta release.

[1]: https://www.npmjs.com/package/react-codemod

[beefsack]

> It's the future

I've heard that too many times to not be cynical about it.

[pjmlp]

I've leaned to stop caring about fads until they become a reality in project requirements.

[tambourine_man]

It's the future

http://blog.circleci.com/its-the-future/

[KurtMueller]

For CircleCi, it's the present. Their frontend is written in Om, a cljs wrapper around React.

https://github.com/circleci/frontend

https://www.youtube.com/watch?v=LNtQPSUi1iQ

[mcintyre1994]

:) Did you see this one? https://medium.com/@boopathi/it-s-the-future-7a4207e028c2

[shiz]

... like HN in a nutshell.

[elorant]

Cross platform tools always make compromises. I’d rather write native code than have a framework that does it for me.

[matthewmacleod]

I'm not convinced that's true.

I do agree to the extent that things like PhoneGap do result in compromises. But React Native is basically a templating tool for native apps – you're still free to write whatever native components you require, but can compose these using React, which is pretty cool. You can then abstract the higher-level components across platforms.

[rimantas]

Why would I want to compose native using React?

[k__]

Probably nothing for the regular mobile-dev. But many of the web-devs can leverage their JS knowledge and hit the mobile-market without "web-container-apps".

[skinnyfoetusboy]

Well, that is the point actually. React doesn't put itself as a "write once, run everywhere" kind of solution. What's being offered here is better interoperability between native and web components. The core philosophy is still "learn once, write everywhere".

[Touche]

I would say that React is the present but that the future is a circle back to progressive enhancement. I'm seeing more high-profile JS developers jumping off the front-end framework bandwagon and back towards progressively enhancing existing HTML. I think we're going to see frameworks emerge which make progressive enhancement the priority and make it easier. So the whole JS templating engine race that has been going on for the last few years will simply not be important any more.

[insin]

I feel like React - or something like it - is part of the path back to progressive enhancement, as you can use the same components to generate the initial HTML on the server and to enhance it when JavaScript is available on the client.

As you say, React is the present, and it's making progressive enhancement easier right now.

[realusername]

Sure, it's the future but currently it's still quite far away, React Native is available only for iOS (and in a quite beta state) and the components are not fully sharable between both of them yet. But yes, I agree, I can't wait for this !

[iofj]

It's the javascript future. How long will it last, really ?

[erokar]

> It's the future.

It's the now. Elm is the future elm-lang.org

[Silhouette]

If you haven't already, you should be betting on React. It's the future

But last week the future was AngularJS, and the week before that it was Ember or Backbone or Knockout, and a few days earlier it was jQuery. Next week it will be Angular 2.0, maybe, or something with Web Components, and the week after that we're all abandoning JS in favour of some declarative functional language that hasn't been written yet but will be on TodoMVC tomorrow.

Seriously, this is a beta of a pre-release package. The article mentions, as motivation for the major architectural change, some other react-something packages, and literally in the opening section of their README.md they say things like "This project is a work-in-progress. Though much of the code is in production on flipboard.com, the React canvas bindings are relatively new and the API is subject to change."

By all means let's experiment with newer and potentially better ways to build sites and apps, but betting heavily on an ecosystem this immature for a long-term professional project seems like asking for trouble.

Isn't this what we have all been waiting for?

It's certainly not something I've been waiting for, as someone who works in the relevant fields. Rather like "isomorphic" libraries, I feel combined web/native generation is mostly a solution in search of a problem. No doubt a few people really do have that problem, but I'm guessing that for most day-to-day work in the real world this theoretical flexibility adds little practical value. There's no particular reason the same tools should be good choices for writing both web and native apps, any more than we should expect the same tools to necessarily be good choices for writing both server-side and client-side code in a web app.

In this particular case, I'm more concerned by the change in emphasis than the technical changes. To me, the big advantage of React over most other front-end libraries and frameworks is the efficient DOM updating, which in turn makes this kind of component model viable with acceptable performance where various other UI libraries/frameworks have struggled in the past. However, it looks like the React team think that is a secondary benefit and the real advantage is using components.

I can already build a complicated web app rendering layer using the same modular design skills I've spent the last 30 years learning in other programming contexts. After all, that's what I did before we had the modern generation of template/component driven frameworks, when we had to update the DOM manually using plain JS or libraries like jQuery. So did plenty of other people. Maybe I'm missing something, but while React might be a sensible enough choice for part of the UI rendering work, I don't see why it has anything unique or special to offer compared to many other libraries here.

If the React team focussed on the efficient DOM updates, flexible but reasonably simple component model, and then stability so the community could develop the ecosystem around a solid foundation, I could see it becoming a good choice for projects that can't afford to have their dependencies constantly shifting around and the maintenance overheads that incurs. But this separation and increased emphasis on react-native and the like feels like it's leaving behind the very things that made React attractive in a very crowded field of JS UI libraries.

[danmaz74]

Well, jQuery has been the future for a very short time, and has been the "present" for years now.

[swah]

Seriously: do you think it can revert the "native mobile apps is the only future" trend?

[Ambroos]

Since React Native has the UI performance of native apps with the ease of development of universal apps (and a minor performance degradation when it comes to logic), it could become a very important player very quickly.

[kendallpark]

I just copied that quote so I could comment on it. I appreciate the React team's vision.

[rimantas]

  > Isn't this what we have all been waiting for?

God no. It's just backwards.