5 ms·
"I love how cleanly it integrates with ES6 and its component style architecture that the future of the web lies upon. That said, I rarely choose it for projects
by jypepin 11y ago
"I love how cleanly it integrates with ES6 and its component style architecture that the future of the web lies upon. That said, I rarely choose it for projects."
I can't find one reason why ES6 and component-like architecture wouldn't be chosen "often" for projects? React is the first javascript (frontend) framework I use that allows to easily break down architecture and keep a complex (or simple) application clean and well structured. It feels like writing server-side code.
"For static sites, Jade is a fantastic templating engine."
Cool. But why compare how to use a javascript, dynamic framework for static sites? That's just a bad argument.
"For data-bound REST apps, I choose Angular. "
Good for you but... why Angular over React? Those are 2 frameworks that are supposed to do the same thing (build dynamic front end applications) with 2 different sets of mind.
But... I build REST apps with React. I even build Forms with React. And they are not even dynamic. What's wrong with it? It makes my code, form validation, form submit way cleaner, easier and reusable!
What should I do instead? Use vanilla js? jQuery? Why? Because it's enough? It's enough, but trust me, I've recently (no later than last week!) refactored some of our forms with React, and it-is-so-much better.
I totally agree with the author's point of "do not use X for the hype and everything, but use X for the good reasons" but the argument given is plain bad and examples are wrong.
- 0xCMP 11y agoWell there are people doing some of these things in React and fighting React just so they "did it in react." For instance there is some blog out there which is "the more complicated blog ever" and it's an isomorphic react application. Then there are the people who use React and the 'renderToStaticString'(or something) to make static sites using React.
- straws 11y agoI'm not sure I'd agree that those are examples of people fighting React though — using it on the client and server allows you to never duplicate markup you might have in a component with markup in a template, for example. The case for writing your entire UI in React is pretty strong actually, as it's just a matter of where you create the data to pass down to your tree of components: once, on the server for a complete page load, or incrementally and dynamically on the client. There are some cases though where the component model feels strained — consider components that act as a pass-through for debouncing data, components that implement routing as a tree of routes and handlers, or components that perform data-fetching. Perhaps it's that the community hasn't found the right APIs for these higher-order components, but it's hard to argue against using React for a stateless tree of UI components.