4 ms·

I don't use React for it's speed, I'm sure I can make anything using vanilla or ember, or whatever just as fast. It's the way it makes you think about things...

I don't use React for it's speed, I'm sure I can make anything using vanilla or ember, or whatever just as fast. It's the way it makes you think about things...the developers on my team are now much more productive. They can jump onto something another developer has been working on and see what each component is doing. It's the declarative nature of React and the way it makes developers think about how they compose their components that makes it a great framework. And let's not forget the reason behind a framework...for developer efficiency. There are no frameworks that are the panacea to everything either, which is probably why the framework arguments break out every single day in the JS world...people think the framework they choose is the one true solution, when in fact, there are many ways to build a building.

Murkin 11y ago
This is a great point, ReactJS has many benifits. People should choose it based on those merits not "speed".
- moonchrome 11y ago
  If you really buy in to react for the benefits of easier to reason about code then you should be using clojurescript on top of it.
nogridbag 11y ago
I was swept away by the React hype a bit. I tried to sell my team on React by stating many of the same points and eventually we decided to stick with our current JS framework: ExtJS. And I'm thankful I was overruled a bit. For our team and the types of applications we're building ExtJS simply makes much more sense. I've used React now for a simple web app and also a Chrome extension. For certain UIs scenarios like Facebook's ad example, the React method of rerendering everything definitely makes things easier. But in most applications, I think such a complex UI is usually rare and ~80% of the UI screens are usually fairly simple. For the majority of UI screens, React or perhaps React+Flux complicates things by adding unnecessary boilerplate even when using third party Flux implementations.
- mejari 11y ago
  We're in the process of migrating from ExtJS to React, and it is, to put it simply, awesome. Ext was great when we started because it gave us all these great out-of-the-box components to just mix and match and shove things together and get things out the door. But relatively quickly (i.e. as soon as we wanted to make something look like it wasn't Ext, and you can always easily tell an Ext app) we ran into Ext's inflexibility. A huge percentage of our code now is finagling Ext over an entire file of code to do what would be a line and some css in any other framework. I have had the exact opposite experience with "boilerplate", as I see Ext needing much more of it than React. As a caveat; we are building extremely complex enterprise-level software, but even for the basic stuff if you want to do what Ext wants you to do you are golden. If you want anything a pixel different? Good luck.
  - nogridbag 11y ago
    Is your main complaint over theming ExtJS? We're also building enterprisey software that's for the most part not consumer facing. Our clients are much more concerned about functionality. So while we have several custom themes for our products, we haven't drastically altered the base themes. Regarding boilerplate, I'll give you a simple example. In ExtJS 4, it's one line of code to wire up an event handler in your controller to a view component like a "Save" button. Then in your onSaveButtonClicked event handler in your controller, you typically you write something like: myView.setLoading(true) // to mask the view myModel.save() // to execute an Ajax req, on success, myView.setLoading(false) In React+Flux, clicking the Save button calls an action creator. The action creator first fires an event "loading: true" before it does anything. A store which is bound to that load action then calls a method which dispatches another event. The view which is listening on the store is notified that "something changed" and redraws itself (to show the loading mask/spinner). All this and we haven't even begun loading any data yet. Repeat all steps once the data is loaded or if an error occurs. I'm not against React at all - just for our purposes ExtJS seems like a better fit. To be fair, I did spent some time building a custom URL router which really simplifies everything. All of our controllers are consistent with start() and stop() methods, they can define data dependencies (i.e. this data needs to be loaded before start is called), etc.

Murkin 11y ago

This is a great point, ReactJS has many benifits. People should choose it based on those merits not "speed".

moonchrome 11y ago
If you really buy in to react for the benefits of easier to reason about code then you should be using clojurescript on top of it.

nogridbag 11y ago

I was swept away by the React hype a bit. I tried to sell my team on React by stating many of the same points and eventually we decided to stick with our current JS framework: ExtJS. And I'm thankful I was overruled a bit. For our team and the types of applications we're building ExtJS simply makes much more sense. I've used React now for a simple web app and also a Chrome extension. For certain UIs scenarios like Facebook's ad example, the React method of rerendering everything definitely makes things easier. But in most applications, I think such a complex UI is usually rare and ~80% of the UI screens are usually fairly simple. For the majority of UI screens, React or perhaps React+Flux complicates things by adding unnecessary boilerplate even when using third party Flux implementations.

mejari 11y ago
We're in the process of migrating from ExtJS to React, and it is, to put it simply, awesome. Ext was great when we started because it gave us all these great out-of-the-box components to just mix and match and shove things together and get things out the door. But relatively quickly (i.e. as soon as we wanted to make something look like it wasn't Ext, and you can always easily tell an Ext app) we ran into Ext's inflexibility. A huge percentage of our code now is finagling Ext over an entire file of code to do what would be a line and some css in any other framework. I have had the exact opposite experience with "boilerplate", as I see Ext needing much more of it than React. As a caveat; we are building extremely complex enterprise-level software, but even for the basic stuff if you want to do what Ext wants you to do you are golden. If you want anything a pixel different? Good luck.
- nogridbag 11y ago
  Is your main complaint over theming ExtJS? We're also building enterprisey software that's for the most part not consumer facing. Our clients are much more concerned about functionality. So while we have several custom themes for our products, we haven't drastically altered the base themes. Regarding boilerplate, I'll give you a simple example. In ExtJS 4, it's one line of code to wire up an event handler in your controller to a view component like a "Save" button. Then in your onSaveButtonClicked event handler in your controller, you typically you write something like: myView.setLoading(true) // to mask the view myModel.save() // to execute an Ajax req, on success, myView.setLoading(false) In React+Flux, clicking the Save button calls an action creator. The action creator first fires an event "loading: true" before it does anything. A store which is bound to that load action then calls a method which dispatches another event. The view which is listening on the store is notified that "something changed" and redraws itself (to show the loading mask/spinner). All this and we haven't even begun loading any data yet. Repeat all steps once the data is loaded or if an error occurs. I'm not against React at all - just for our purposes ExtJS seems like a better fit. To be fair, I did spent some time building a custom URL router which really simplifies everything. All of our controllers are consistent with start() and stop() methods, they can define data dependencies (i.e. this data needs to be loaded before start is called), etc.