4 ms·

There is no 'one true way'; as long as your app works and you can hold it in your head, everything is fine. With all due respect, this is the maj

by wanda 11y ago

There is no 'one true way'; as long as your app works and you can hold it in your head, everything is fine. With all due respect, this is the major criticism of adopting React, given that it's still in active development and given that many who are looking at using it have established apps using other patterns already.

jasim 11y ago
React's API is fairly stable, and has been for a long time. Redux has almost become the de-facto standard for new projects, but again, it is just a library around a good idea: do all state transitions inside a pure function - get an input, return a new output, and the entire view gets re-rendered with it. You can use React's immutability helpers inside it, or or performance in large state trees, use ImmutableJS that gives persistent immutable data-structures. This comes at the cost of having to use its own methods like map and filter, instead of normal JS everywhere. But that is pretty much it. There are a few more other concerns that'll necessitate the use of redux-thunk, (which at its core is a few lines long), but you don't need to worry about any of this upfront. The thing with React is that unless you make costly architectural decisions upfront, you can always learn as you build, and figure out the right way to structure your project. Once you've built a fairly large project, you'll form your own set of opinions on which way you like to think about front-end code, and that'll inform you on your next project. There is a learning curve, but with React, you are always thinking about fundamental things like encapsulation and message-passing than trying to learn non-transferable knowledge about a particular framework's quirks and conventions.
- wanda 11y ago
  You don't need to sell it to me, I see the advantages--but precisely because I understand those advantages, I actually intend to complete my next project with Cycle.js [1]. [1]: http://cycle.js.org http://cycle.js.org
  - jasim 11y ago
    Awesome! A lot of smart people have been saying good things about Cycle.JS, but I unfortunately have been unable to wrap my head around it. The idea of putting stream of user-generated events front and center appeals to the puritan in me, but I find it more natural to think about the front-end beginning with the rendered view, and events and their mutation (uni-directional actions) later. The Elm language is yet another area that gives the fear of missing out on the 'better than yesterday's abstraction'. But as long as I'm able to build great software with the tools I know and patterns my brain is comfortable manipulating, they can wait. This is the line of thinking that I mentioned in the original post about no one true way.
pluma 11y ago
For most problems, the following is how you define a component: function Comp(state) { return React.createElement( 'div', // tag name {}, // props/attributes 'Hello ', state.name // children ); } And this is how you use it: ReactDOM.render( React.createElement(Comp, {name: 'World'}), document.getElementById('stage') ); So in those situations the entire surface of the React API consists of two functions: React.createElement and ReactDOM.render. And if you use JSX, you won't even directly use React.createElement in your code. React is conceptually trivial. The API has been getting tighter with each release. React is in active development but so are all of its competitors[1][2]. React is production ready -- Facebook is even dogfooding the pre-releases in production. [1]: in fact, when a library/frameworks stops being actively developed people start assuming it's dead. Counter-example: Redux is no longer actively being developed because it is officially complete and the implementation is so straightforward and resilient it can't really be improved right now. [2]: the reason it's bogus to compare it to Angular2 "because that's not finished yet either" is that Angular2 is being built to spec whereas React is being developed under use. Angular2 will be "finished" when the full spec is implemented. React will be "finished" when real-world use shows no further need to change -- by that definition none of the alternatives (including Angular2 post-"final") is "finished" either.
JustSomeNobody 11y ago
> There is no 'one true way'; as long as your app works and you can hold it in your head, everything is fine. Unless you write a blog post entitled "My reaction to react" and proceed to demonstrate components in straight javascript and that blog post winds up on HN where you're summarily dismissed as "doing it wrong."

by wanda 11y ago

jasim 11y ago

React's API is fairly stable, and has been for a long time. Redux has almost become the de-facto standard for new projects, but again, it is just a library around a good idea: do all state transitions inside a pure function - get an input, return a new output, and the entire view gets re-rendered with it. You can use React's immutability helpers inside it, or or performance in large state trees, use ImmutableJS that gives persistent immutable data-structures. This comes at the cost of having to use its own methods like map and filter, instead of normal JS everywhere. But that is pretty much it. There are a few more other concerns that'll necessitate the use of redux-thunk, (which at its core is a few lines long), but you don't need to worry about any of this upfront. The thing with React is that unless you make costly architectural decisions upfront, you can always learn as you build, and figure out the right way to structure your project. Once you've built a fairly large project, you'll form your own set of opinions on which way you like to think about front-end code, and that'll inform you on your next project. There is a learning curve, but with React, you are always thinking about fundamental things like encapsulation and message-passing than trying to learn non-transferable knowledge about a particular framework's quirks and conventions.

wanda 11y ago
You don't need to sell it to me, I see the advantages--but precisely because I understand those advantages, I actually intend to complete my next project with Cycle.js [1]. [1]: http://cycle.js.org http://cycle.js.org
- jasim 11y ago
  Awesome! A lot of smart people have been saying good things about Cycle.JS, but I unfortunately have been unable to wrap my head around it. The idea of putting stream of user-generated events front and center appeals to the puritan in me, but I find it more natural to think about the front-end beginning with the rendered view, and events and their mutation (uni-directional actions) later. The Elm language is yet another area that gives the fear of missing out on the 'better than yesterday's abstraction'. But as long as I'm able to build great software with the tools I know and patterns my brain is comfortable manipulating, they can wait. This is the line of thinking that I mentioned in the original post about no one true way.

pluma 11y ago

For most problems, the following is how you define a component: function Comp(state) { return React.createElement( 'div', // tag name {}, // props/attributes 'Hello ', state.name // children ); } And this is how you use it: ReactDOM.render( React.createElement(Comp, {name: 'World'}), document.getElementById('stage') ); So in those situations the entire surface of the React API consists of two functions: React.createElement and ReactDOM.render. And if you use JSX, you won't even directly use React.createElement in your code. React is conceptually trivial. The API has been getting tighter with each release. React is in active development but so are all of its competitors[1][2]. React is production ready -- Facebook is even dogfooding the pre-releases in production. [1]: in fact, when a library/frameworks stops being actively developed people start assuming it's dead. Counter-example: Redux is no longer actively being developed because it is officially complete and the implementation is so straightforward and resilient it can't really be improved right now. [2]: the reason it's bogus to compare it to Angular2 "because that's not finished yet either" is that Angular2 is being built to spec whereas React is being developed under use. Angular2 will be "finished" when the full spec is implemented. React will be "finished" when real-world use shows no further need to change -- by that definition none of the alternatives (including Angular2 post-"final") is "finished" either.

JustSomeNobody 11y ago

> There is no 'one true way'; as long as your app works and you can hold it in your head, everything is fine. Unless you write a blog post entitled "My reaction to react" and proceed to demonstrate components in straight javascript and that blog post winds up on HN where you're summarily dismissed as "doing it wrong."