> ? Can React also connect with backend APIs to fetch JSON and present them on the front-end?

Technically? No.

React doesn't include the direct code to main API calls. You're still going to need to make the 'API calls' 'yourself', whether with jQuery or raw XMLHttpRequest or whatever. React comes into play when you have the data and you're ready do actually do something with it.

I found this tutorial series to be pretty good, demoing React with Ampersand as the model/controller: http://learn.humanjavascript.com/react-ampersand/introductio...

There's also a library to hook up React views directly to a Firebase (real-time JSON streaming) backend: https://www.firebase.com/blog/2014-05-01-using-firebase-with...

Yes, it's pretty much unnecessary to include React and a framework like Angular, Ember, or Knockout in the same project. And of course React works well with REST and GraphQL APIs for communicating with a backend. React is definitely a better alternative to a heavyweight framework like Angular for new projects.

I can't imagine using React and Knockout in the same project.

As a relative newcomer jo JS frontend development, is there a canonical JS REST client library that works well with React / Flux, or do I have to write that myself?

Fetch is really easy to use, and is native in modern browsers. There are several polyfills as well. It eliminates the need for any libraries.

Thanks, appreciate the pointer - the idea of adopting something potentially a future standard through a polyfill is appealing. @pvg I take your point about lack of browser support, but that's what polyfills are for after all! :)

In the meantime since asking I also came across restful.js (github [1], blog [2]) - it's new, but looks like a good framework-neutral alternative, if a little heavy at 27K minimised/uncompressed.

Edit: Actually, fetch.js + es6-promise-min.js = 26K, so not much in it.

[1] https://github.com/marmelab/restful.js [2] http://marmelab.com/blog/2015/03/10/deal-easily-with-your-re...

Fetch looks interesting but as far as I can tell, it's an in-progress standard with no support on any version of Safari or IE or any mobile browser whatsoever. Seems like it has a bit to go before it being 'native in modern browsers'

You can polyfill it in those browsers. Just use polyfill.io, or if you prefer, manually feature-detect it and if necessary load Github's fetch polyfill, which is good: https://github.com/github/fetch

Maybe "superagent". Client side and node.

React certainly replaces Angular as a View+Controller framework (idk about Ember, although I know there's been work on integrating the performance benefits of Virtual DOM).

In scenarios with complex interactions, something like Flux is desirable, however small web apps work fine with simple JSON REST APIs.

I'm more interested to see if polymer/x-tag/webcomponents will replace react/angular/other stuff.

AngularJS already has third-party libraries for polymer/webcomponents, and from what I've heard, they're integrating it more solidly in Angular 2.0

React is pretty new, once it gets bigger it'll also follow along too.

React will probably just integrate those as they become usable, since React acts as a layer of abstraction between the DOM and your presentation logic.

Not so. React does not really play well with web components. Currently React has to internally define JSX elements for every known HTML element that's out there, namely to track internal state and respond to events (i.e. input fields). Because they won't be able to do the same for the vast ocean of web components that will be authored in the coming years, it will be difficult to provide clean interop with new custom elements. The React maintainers have even stated that they don't believe web components are the right way forward for web application development. React was never designed to work well with web components in the first place. On the other hand, the main reason why Angular 2.0 is such a drastic rewrite is because they needed to do it in order for Angular to work seamlessly with Web Components. It's no coincidence that both Angular and web components are Google initiatives.

You're wrong about web components and react. As of 0.12, if you register a web component like you normally would, you can reference it in a react component. React no longer has a white list, and instead assumes all lower case tags are HTML tags (standard or custom).

The only drawback is that it doesn't support custom events out of the box. Instead, you have to manually create event listeners on elements on mount. As far as I can tell, there's no reason why it couldn't in the future though; Web component adoption is so low right now that it just hasn't been something people have complained about.

Not supporting custom events is pretty much the same as not supporting web components. What if you use a third party web component that has dozens of events? The goal should be interop with no additional plumbing required.

There was a time when React literally just didn't support web components, so I don't think that's really fair. Yes, it would be nice if it worked completely free, but if you're only listening to 2 or 3 events on a component, it is definitely a fair price to pay for being so bleeding edge.

But Angular is a glorified templating engine, where react is really about FRP and rendering from data. The React components you write are essentially web components that use DOM; as long as there are standard building blocks for web components in the future, you could easily port it to React.

Yes, but now you're requiring that developers go through the work of porting every single third party web component they might want to use in their project. That's the current pain we're all going through today with Angular, React, Ember, etc, which are basically glorified web component polyfills when it comes down to it. The whole point of Web Components is portability.

While this was true a few releases ago, with React.createElement() things have changed.

How exactly does that solve the problem of consuming custom web components with their own internal state and events?

People are already trying it.

https://github.com/Wildhoney/ReactShadow

> Can React also connect with backend APIs to fetch JSON and present them on the frontend?

Yes, obviously. My company uses it for this. Personally, I don't know if AngularJS is a better alternative moving forward because it has a bigger community and companies such as Microsoft are integrating it on Visual Studio.

(Sadly being downvoted for saying this)

I've read through the docs and they basically use JQuery for AJAX calls. Is that what you were referring to?

React will keep getting bigger, and AngularJS has no answer to React Native which I find pretty revolutionary.

(I work on the React team.)

The folks working on Angular 2 are looking at interop with React Native's native shell so that you can write native apps in Angular (2) as well.

How revolutionary does it end up being if you have to farm out a lot of hte stuff you'll do to other JavaScript libraries which presumably do not have a native component?

I've been told by several friends who love React that this is one of the main selling points.

It basically just gives you a view engine and then you have the flexibility to select what other libraries you want to supplement the rest of the app components.

This differs from other frameworks like Angular where you have to "go all in" and don't have the flexibility so that if something major changes (like when the Angular team announced HUGE changes coming in 2.0) you might get stuck with something you don't like. In this way, it's easier to switch out a part of your app as opposed to having to completely rewrite something if you use a full framework like AngularJS.

I get that but there's a sort of value to a monolith that gives you most of what you'd need to build an SPA with a "guarantee" that all the components are reasonably good too.

You've misunderstood.

I said React Native is revolutionary. It's the first JS framework that lets you build native iOS and Android apps. Key word here being "native".

React itself was designed as a UI library, purely to be used as the "V" in an MVC app. It's like expecting D3.js to do your AJAX calls. Unless it's a full front-end framework, there's no point trying to do everything.

Surprisingly D3.js actually can do your AJAX calls with d3.xhr()!

Perhaps that's natural, but I mean, if you had, say, "Angular Native" you'd have a whole application which would be wild.

What do you mean?

I mean that the competing frameworks are whole application frameworks instead of just a view; being able to write them and compile them to native would be even more powerful.

> I've read through the docs and they basically use JQuery for AJAX calls. Is that what you were referring to?

Yes.