3 ms·

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

by mrcwinn 13y ago

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

AdrianRossouw 13y ago
I think backbone is going to be here for a while, because I don't actively expect it to get more complex over time. 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.
- mrcwinn 13y ago
  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.
  - AdrianRossouw 13y ago
    i've used backbone on the server for years. rendering too. it's why i prefer backbone to angular.
oh_sigh 13y ago
> 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
- masterj 13y ago
  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.
- lobster_johnson 13y ago
  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.)

by mrcwinn 13y ago

AdrianRossouw 13y ago

I think backbone is going to be here for a while, because I don't actively expect it to get more complex over time. 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.

mrcwinn 13y ago
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.
- AdrianRossouw 13y ago
  i've used backbone on the server for years. rendering too. it's why i prefer backbone to angular.

oh_sigh 13y ago

> 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

masterj 13y ago
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.
lobster_johnson 13y ago
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.)