React is awesome. It is the biggest change to how I approach web development that I can remember over the last 10+ years.
It has made many things that used to be laborious and error-prone fun and robust (URLs for every state in a SPA, enabling search crawlers for SPAs, live updates, infinite/virtual scrolling, unit testing). I keep finding more things it works really well for. I really need to write an article about this at some point.
Anyway, if you haven't spent some time playing with it I really recommend doing so.
Just wanted to share some anectodal evidence about an angular app I am in the process of rewriting in react. For now, I am reimplementing the main functionality as a directive in react, keeping other angular parts. (Angular directive is there to make the transition seamless, while keeping other parts like routing etc. in angular)
Performance had become unacceptable in angular and hard to track. Mutable state with two-way bindings made it hard to reason about.
React makes state much easier to reason about. App performs noticably faster (three/four times faster), memory consumption is halved. React devtools is very helpful to inspect the virtual DOM. Integration with other libraries is very easy, it doesn't try to own your app like Angular.
Getting up to speed with react is very easy too with a small and very nice to use API. I would encourage everyone doing webapp development to check it out, at least for a demo app to get a sense of it. Go through the tutorial on the site and you'll feel comfortable within hours.
I haven't yet put React in production (possibly in the next month or so), but so far working with it has been fantastic. In my case, I've been refactoring some complicated Backbone views as React components, but still mixing in Backbone models, collections, and the event bus. So far, the event system has proven to be vital. Since React has one-way communications from parent to child, the existing Backbone event system is useful if you need to trigger an event back up the chain.
Every time I finish up a React component, I'm blown away by how much simpler (and shorter) the code is compared to a traditional Backbone view — particularly when multiple subviews are involved.
I've tried just about everything - Meteor, Ember, Angular, and others. Meteor is of course its own special case, but of the client-side libraries and frameworks, nothing's quite felt right in my opinion. Backbone is still going strong for me, and React gives it a whole new life.
JSX can be a tough pill the swallow — and I should note it's entirely optional — but I've found it really useful to have your component markup just lines away from your component logic. Embrace it. :-)
> Every time I finish up a React component, I'm blown away by how much simpler (and shorter) the code is compared to a traditional Backbone view — particularly when multiple subviews are involved.
Have you considered that this is now (presumably) your second time implementing this code, and you get to implement it in one shot, as opposed to (presumably) piecemeal development and feature additions that happen as part of organic feature growth.
I suspect that if you reimplemented your backbone stuff again in backbone, you would find the code to be better/more readable/shorter/etc.
That isn't to take anything away from react(I haven't used react or backbone in my life), but you should keep that potential bias in mind when comparing frameworks using "porting existing code to new framework" methodology
Like mrcwinn, I recently switched from Backbone to React, and my experience mirrors his.
I have implemented Backbone views many enough times to know how to do it right; I am in no doubt whatsoever that the improvements that come from reimplementing in React are not thanks to any knowledge gained from the first implementation but rather, come from React's design itself, especially three three aspects in how React does things differently from Backbone:
* The method of rendering everything from scratch every time, through the virtual DOM;
* The nested component support; and
* The explicit state management.
In addition I would give "ability to add event handlers directly to elements" an honourable mention. (Automatic binding of "this" to component methods is also a lifesaver, but probably not dependent on React's design.)
For what it's worth my experience mirrors the OPs, even when writing new functionality in React. The use of components really makes composing functionality and breaking problems down really easy. Backbone doesn't give you the structure to solve this problem easily.
Still <3 backbone, but React is a really great solution to the view layer, which is a problem that backbone doesn't even really try to address.
Thanks! And I agree. I have Backbone code from quite a while ago and it's still holding strong today. The thing with Backbone, as opposed to some more convention-orientated frameworks like Ember, is that it's as good as the programmer. And if you are an experienced Backbone developer, that can be _damn_ good.
If Backbone had any weakness, it was managing subview chaos at large scale. React does a great job solving that - and introduces other opportunities for better patterns. Thinking in terms of reusable components, and maybe even using those components on the server side as well, is pretty exciting.
We use React for view components, and TypeScript for everything else. The ES6 class syntax would be great for us, because it'll allow our view code to look more like our TypeScript code, and still work in all browsers (because we already use the JSX compiler anyway).
Nevertheless, a simple way to put JSX inside TypeScript code would be even cooler (and I suspect that CoffeeScript people might have similar feelings wrt JSX).
I don't think CoffeeScript would benefit much from JSX, since the sugar for function calls and object literals applies well to React. For example, one of the examples from the React page translated to plain CoffeeScript:
A hypothetical CSX would probably be more along the lines of Haml or Slim than XML syntax (closing tags would be pretty weird and out of place), and plain CS isn't that different from them already.
The point is getting designers to shift paradigm and start writing React components. This is a major shift, because while the designers I've worked with have all done a little JavaScript here and there, it's seldom much more than copy/pasting some jQuery code from Stack Overflow.
HTML/CSS is their home turf. To you, the CoffeeScript literals might be just as good as the JSX stuff, but to someone who's already out of his comfort zone because the markup is in the middle of all kinds of weird React.createClass stuff, it's a very major difference.
Sure. We're building a single page webapp here at http://izooble.com. Our frontend is Model-View-Nothing with React for the view and TypeScript for everything else. We build with gulp, and avoid browserify because it makes debugging more difficult. Therefore, we generate a debug and a production build: the production build simply concats all generated JS, and the debug build keeps the separate JS files with source maps back to the .ts sources. We autogenerate the index.html.
Some of us code TypeScript in Visual Studio, which is awesome. Many just use a text editor and `gulp watch`, though, which works remarkably good as well. I wish there was good TypeScript IDE support on other platforms than Windows. The entire team has previous experience that makes them think strongly in terms of classes and object. TypeScript is a very natural fit for a team like this, and made us productive very fast. Prototypal inheritance, not so sure.
On the backend, we do C#, hosted on Linux with Mono (we have devs running Linux, Mac and Windows, we're just as cross-platform as your average Python shop). We use ServiceStack v3 for the API and PostgreSQL for data. We heavily rely on stored procedures and Postgres-specific features (such as returning cursor sets instead of gigantic joins) for making the backend very lean and simple.
We use Docker for running stuff locally and in production. Our designers just run the backend docker containers locally with a single click (in Vagrant). They never installed Mono or Postgres anywhere.
WebStorm from JetBrains has good TypeScript support. You could look into that as VS alternative.
Another question: our TypeScript compile-times are approaching 5/6 seconds whenever gulp watch triggers. Imo this is too long for a workable frontend workflow. Did you guys find a way to incrementally compile TS with gulp?
No, we did not. Our stack is still on the grow but we're starting to run into the same problem.
That said, we have many small files, so I'm pretty certain that for us, setting up gulp to always only recompile whichever file changed (which we currently don't do) should be good enough. Afaik there's ways to do this with gulp but I did not investigate yet.
Do you guys manage to only recompile changed files?
I tried using https://www.npmjs.org/package/gulp-changed, but couldn't get that to work in the timebox I allowed myself. Also, just passing the changed file to the typescript compiler would probably not work in our case (since we also need to pass in our type definitions in the same compiler pass), and recompiling a single file might lead to errors in a different file importing the changed file that you would miss with this setup...
The tsc executable does have a -watch flag itself for incremental compilation, which presumably takes into account these dependencies. So may be the solution is to use that outside of gulp (since gulp-tsc doesn't seem to be able to launch the compiler in watch mode).
What I'd really like to see is a switch to macros instead of preprocessors, so you could use (almost) arbitrary transformers together. While not always possible, it would at least let one easily mix, say, JSX and generators from different libraries.
I absolutely love React. It's small and does what it aims to do just great. You can probably learn React in an hour or two. I don't really mind the React.createClass semantics because I'm aware of how many ways there are to build objects in JavaScript. This roadmap seems useful, but please don't add too many features and ruin a wonderful thing.
React is absolutely incredible! They only thing i'd ask for is better support for mobile applications. Namely, touch gestures (tap, swipe, pinch, etc). Since react uses synthetic events, perhaps pointer-events can be baked right in so that it's backwards compatible, replacing touch* events.
I've done sufficient with both Angular and React to have decided to go with React for next our project. Its a better fit for this particular project because the "reusable components" paradigm fits what we're doing, which includes building a non-model-specific framework that we can reuse for different models, where the framework renders slightly differently based on meta data provided with the model. We'll probably use Backbone for the model (& meta) & router. I like Angular, and would like to use it for a project that's more concrete and less meta.
Something about Angular rubs me the wrong way. I think it has to do with dirty checking. Either that or the scope magic that happens. React, comparatively, is quite straight forward. I hope it stays that way, a minimal API and no magic.
The more I look into react the more I wonder if some intermediary representation of the DOM ought to be standardized so that a native "diff/batch" algorithm can be provided as regular functions. I think react would help this cause if it can break up into several projects (react-events, react-virtual-dom, react-dom-diff/batch, etc). Perhaps other projects can adopt parts of react into their own frameworks. Just a thought.
Core team member here. That's excellent feedback and we are definitely going to be pushing in that direction where we can. API simplicity will always be a primary goal and a modular core implementation will help advancement of mobile support and testability. The event system is already self contained and shouldn't depend on anything in React at all.
Loving React, it gives me the same joy that learning D3 did but offers a more powerful abstraction. I've been able to render the same markup on the server as on the client using Browserify. If you like D3, you should give React a try.
I actually landed on that link a week ago, and gave up on learning reactjs.
I've heard of the various JS frameworks over the past two years, but only until this month I was considering using one (NIH mentality @ work). I tried out AngularJS and it made sense, but I had issue after issue with npm deps. I tired of web searching, and went to my default search engine (DDG) to look up reactjs.
Just an anecdote I felt like sharing. I upvoted grandparent because someone took the time to downvote him, but believe it or not, I wasn't going to click the link until I read the commends and had him clarify it for me.
<3 React! It is a serious paradigm shift that has finally brought the #1 thing that I care about the most! Performance With React, my app got around x13 more performant
We started in Backbone, then migrated to Angular to mitigate nested view chaos. Latest rewrite drops Angular in favor of React and a bit of Backbone, mostly to reduce the learning curve for new devs. Using React for views is the simplest/most robust stack we've experienced. Easier to share/reuse code, easier to debug.
React with Coffeescript has been super great - dropping JSX lowers the learning curve even more, especially since we already use and love slim, and Coffee/React sort of resembles slim.
>> then migrated to Angular to mitigate nested view chaos.
For the record, and for those who are unfamiliar, "nested view chaos" isn't an inherent characteristic of Backbone, and it can also be mitigated by writing good, thoughtful code (often easier said than done).
Using React views can make life easier, since composition of nested components is part of the design.
Yeah...I imagine that the original poster is going to be making a very similar post in 1 year, saying "We started in React, but switched to <sexy new tool> because <some fault of our own that we then blame on React>"
Since those accounts don't really look like spam accounts, we'll take that as a compliment =).
Even as a contributor, the reactions from the React users surprise me sometimes.
It has made many things that used to be laborious and error-prone fun and robust (URLs for every state in a SPA, enabling search crawlers for SPAs, live updates, infinite/virtual scrolling, unit testing). I keep finding more things it works really well for. I really need to write an article about this at some point.
Anyway, if you haven't spent some time playing with it I really recommend doing so.