The Road to React 1.0
facebook.github.io
facebook.github.io
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.
Had I mentioned that I love React?
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 release just feels like it's tuning it up.
Oh, and you should check out marionette's extended event system. It's quite useful.
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.
it's why i prefer backbone to angular.
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
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.
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.)
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).
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.
Is that what you wanted to know?
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?
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?
Thanks for the WebStorm hint! Did not know that!
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).
JSX:
<div>
<h3>TODO</h3>
<TodoList items={this.state.items} />
<form onSubmit={this.handleSubmit}>
<input onChange={this.onChange} value={this.state.text} />
<button>{'Add #' + (this.state.items.length + 1)}</button>
</form>
</div>
R.div null,
R.h3 null, 'TODO'
TodoList items: @state.items
R.form onSubmit: @handleSubmit,
R.input onChange: @onChange, value: @state.text
R.button null, "Add ##{@state.items.length +1}"
`/** @jsx React.DOM */`
Todo = React.createClass
render: ->
`
<div>
<h3>TODO</h3>
<TodoList items={this.state.items} />
<form onSubmit={this.handleSubmit}>
<input onChange={this.onChange} value={this.state.text} />
<button>{'Add #' + (this.state.items.length + 1)}</button>
</form>
</div>
`
coffee -bc --no-header todo.coffeeclass Welcome extends Component
render: ->
@div ->
@text "Hello"
@span @props.name
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.
JSX really strikes a sweet spot here.
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.
http://daemon.co.za/2014/03/why-wrong-to-be-afraid-angular
I am looking forward to trying react though, because of how well it plays with backbone (which is still my preference)
For more info, check out my talk at the Ember NYC meetup here: http://bit.ly/P2Wu6X
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.
React is really interesting though, and from what I understand it's possible to use it with Angular, seems like you're on the right track!
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.
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.