"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.
Well 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.
I'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.
How about learning one thing well, so that you can use it for a wide range of projects? Choosing React and using it for everything sounds like a great idea to me, since you can transfer your knowledge from larger projects to smaller ones, and vice versa, instead of spending time learning new things.
Also, I don't mean to be snarky, but I suggest the writer uses fewer ALL CAPS, fewer exclamation marks and tones down the provocations to be more convincing.
Agreed. I'm using React on a project that it is a bit heavy weight for simply because we're also using it on two projects that it is awesome for. The server side rendering is the excuse we're using, but the real reason is to maximize knowledge transfer.
React is neither a hammer or a screwdriver. React is the toolbox. The problem here is that the article writer and you think that React is some kind of hammer.
The person I replied to said exactly that React should be used for everything.
There are certain categories of web applications and pages which do not benefit at all from React (or other semi-related technologies like Angular), and it's folly to pretend that they do.
If you want to go the "it's a toolbox" route...showing up to a carpentry job with a plumbing toolbox isn't useful.
>There are certain categories of web applications and pages which do not benefit at all from React (or other semi-related technologies like Angular), and it's folly to pretend that they do.
That's like saying there are certain programs in which functions do not provide any benefit at all. It's folly to pretend that they do.
Look, if you're over 28, you should be in management by now.
What, you've got some other way of updating the DOM using the existing elements? Some other way of receiving data from the server and updating the page? Some other way of detecting bad form data? Pshaw.
You probably still use CSS.
EDIT: Because hivemind cannot into humor, this was all sarcasm.
Humor?!? How dare you, sir! Arguing about the smallest minutia of javascript frameworks is no laughing matter! Why, just last week a friend of mine used Angular when he should have used Angular2, the fool! His arms turned black and fell off! Do you want your arms to turn black and fall off? I thought not!
For most generalists who doesn't live in the frontend, learning every framework and applying the right one is not tenable. None of the js client-side MVCs I've seen are easy to just pick up. Even 6 months after I haven't used one I have trouble remembering how it works. You'll be much much more productive on something you are familiar with, even if it's not an exact fit.
If you are a frontend javascript consultant, than by all means, learn them all.
I agreed with the headline but was disappointed that the upshot was "use Angular, Ember, or Backbone instead" rather than "not all websites need to be JavaScript-dependent single page apps".
React brings sanity to the web UI world. It brings reusable components! It brings composition. It brings modularity.
... and it's written by adults who know CS. Your UI is a pure function of your state. Who knew?
Why would I use anything else? Really? Do I want state-management spaghetti and over-engineering?
The only way I'd give up React for dynamic sites/pages is if the web standards groups made Web Components into something that was actually as good as React and baked this into the stack. But somehow I doubt that's going to happen. Web Components might turn into something good to compose UI but you'll probably still need React to add dynamic behavior to it.
> It is not the one-size-fits-all solution you are using it as. If your site has a dynamic form, you don’t need a freaking virtual DOM.
The main benefit of virtual DOM afaict is that it makes rendering on the server trivial without needing to jump through all the hoops that, e.g. Angular has to. Contrary to the post, this makes it ideal for such sites.
The battle of front-end frameworks is powered by companies trying to lure new and inexperienced developers, as well as experienced employees already working with teams of developers, into a more unified thought pattern.
For that purpose they are great.
On the other hand, the underlying "magic" isn't optimal for all use cases. The author states:
"If you have a highly dynamic application that needs to rerender frequently, and you want to avoid the heavy weight of template diffing, [...] ReactJS’s virtual DOM will be super effective. However, if you’re site doesn’t have those needs, CHOOSE SOMETHING ELSE!"
Well choose a DOM representation implementation in this case. That's not what React is all about. And may I add that, "Virtual DOM" or however you want to call it, will never be as fast as manual DOM manipulation done right. It's just a well documented convenience magic abstraction.
We no longer have vast incompatibilities among browsers, so we no longer use JQuery. At the same time, threads pop up everywhere titled "how do I do [this] in [Angular, React, etc.], just like it has happened with JQuery in the past. And I won't even mention framework specific "plugins" ..
The underlying problem is, the majority of people involved with JavaScript for the web platform, are afraid and/or lazy learning it. And no framework can cure this, but at the same time frameworks help us hide the pile of ignorance we have under the framework carpet.
I'm not bashing anyone, frameworks can inspire and help organize vast amount of work. But at the same time they are hard dependencies, hailed by well known developers. Sooner or later there will be new ones [that got it right this time] and the cycle of hype-wow-sucks will continue. Well they are all built with JS, so how about you take your time to learn the language and philosophize a bit on programming, state management, application structure and the capabilities (as well as the bottlenecks) of the web platform?
Then you may choose any framework you like at any time and you won't be shooting yourself in the foot because you'll be using it as a tool, and not the panacea for all your troubles.
No. I <3 React for single-page applications. Add in browserify, and you no longer have to deal with the dependency soup that is jquery / requirejs / backbone / angularjs, and you write software with far fewer side effects. It's. Freaking. Great.
> If you have a highly dynamic application that needs to rerender frequently, and you want to avoid the heavy weight of template diffing, you’re looking at a grass-type opponent and ReactJS’s virtual DOM will be super effective. However, if you’re site doesn’t have those needs, CHOOSE SOMETHING ELSE!
What if I really like the programming model behind React? My UIs are so easy to reason about now, and that's why I like it so much.
This is actually the good thing on React: You can use it for certain parts of your websites and you are not forced to use it for everything on your website.
I am using React and all the trendy tooling for my personal projects, even if it's just a simple website. Why? Because that's an opportunity for me to learn new stuff.
I can't use React at work, but I don't want to stagnate either. That's why I'll always be using the most ridiculous trendy technologies for side projects.
I do think that's how most of frontend developers live nowadays.
The same could have been (and was) said for Angular. Weapon choice is part of a duel.
At the same time, I worked in a couple places that used better, but less fancy languages/frameworks. I won't name them to not attract a horde of "but Erlang/Racket/Ember is the best thing". There was a repeating pattern of having a hard time with both recruitment and with actual development. People didn't know our tech, or they did but not as well as they claimed they did. Then there was all the trouble with finding libraries, examples and general help of any kind with less popular tech. I suppose the cost of using a wrong but popular tool (be it React or anything else) may actually not overweight the cost of using the right tool which in general is harder to utilize.
I'd have to agree; React is pretty cool in some use cases but it's not always the best tool for the job. I mean take a look at the Atom editor; they initially used it which helped speed up their development but after a certain point they benchmarked it and found simply manipulating the DOM itself was far faster. Now that doesn't mean to never use React; all that means is simply use the right tool for the right job.
If you need something done and done fast with decent code separation, feel free to pick up React. If you need to optimize for performance (because many of us need to at some point) or you have a good understanding / way to architect your code to keep up a good separation of DOM and business logic then use almost anything else.
Hell, you don't even need to use a framework for the web. My last project I didn't use any and it was perfectly fine. Frameworks are great to get you going faster and doing the hard parts for you but you don't always need that.
The thing is do you want to build something or do you want to learn every JS framework and try to decide which is going to be the very best for what you are doing then build something.
Oh yeah I never built _____ cause I was busy learning a, b, c, x, y, and z frameworks and by the time you have those down there are three new ones. When most likely what you are doing any of the big ones will be fine so just pick the one you want to learn, or know already or whatever works best for you.
I'm at the point where I'm looking to pick the next web technology stack for projects moving forward. I am leaning towards React as the main framework for everything.
The reason for a one-size-fits-all choice is that I really don't want to have to learn the ins and outs of 3-4 different frameworks and libraries. Even if React doesn't exactly fit the model of a certain application, it makes sense to shoe-horn it in to avoid a fragmented technology stack. I only have so much space in my brain.
I think these points could be for 'hip' frameworks in general. As a developer, it's tiring keeping up with the latest and greatest AT ALL TIMES. Anyone have a good comparison of React and Angular that cuts through the hype?
React and angular.js don't really solve the same problems (though angular 2 is incorporating some react-like techniques). React is only the V (arguably a bit of C) from MVC, where as angular.js provides all three but does a rather crappy job on V IMHO. ng-react supposedly let's you use them together but I haven't tried it yet (I plan on it).
Yes, but beef I have with the cool kids I've worked with are they throw out the entire app: MVC, Server, etc. so they can use this magical V - then completely rewrite and wing the rest of the app "Oh it's, um, 'Flux Architecture'"
I'd like to read that too actually. The new place I'm working is all Angular on the front end. Seems decent enough, but I haven't tried many JS frameworks, and haven't messed with React at all, despite all the buzz about it lately.
I honestly don't know if there's any point to trying to learn it over getting better at Angular when we have so much invested in Angular, and there's a new coolest JS framework every other week anyways.
This is the angry way of saying - think about the needs of your website/web app before you decide what libraries and frameworks to use, and use them sparingly.
Def. Jquery filled the gaps in the built-in JS/DOM/HTML query & manipulation interfaces. React is filling in the gaps of the JS/DOM/HTML component interface.
I don't even have to read the article to know this is going to get down-voted into obscurity. It's like mom always said if you don't have something nice to say about this week's popular javascript framework, don't say anything at all (or else...)
I'm sympathetic to the basic idea, but surely this is not the article you're hoping for. There's a lot of ranting, with only a couple of sentences of actually useful information, eg. situations in which React is not a good fit. He mentions Angular for "data-bound REST apps" -- why? What makes React worse than Angular in that situation? What would be the tipping point in that situation that might make him use React instead? No data provided.
Yeah not exactly a well reasoned article about the strengths and weaknesses (these really do exist) of using React or X Other Framework. I went back and actually read it.
The CEO of the Meteor Dev group gave the following presentation recently:
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.