What has the above statement got to do with React and Frameworks?
A lot of workplaces are now taking JS and its powers more seriously, it’s no longer just this simple frontend browser only language.
Because of this more and more developers have been attracted towards using JS Frameworks as a solution for refactoring or rebuilding existing non JS code bases. It makes total sense for you as a developer to want to be able to use JS to do things like offering your users Single page apps, the use of great libraries to create forward thinking interactivity and much more.
But your dreams are not going to be met if you approach the powers that be without some good, fast, all singing all dancing solutions. Remembering that time and cost are always going to be a priority.
This is where <input framework> is a perfect candidate, it can deal with most needs straight out of the box! What an attractive solution all round.
“What an attractive solution all round.
So in steps React, lots of hype lots of BIG companies now using it. Everyone keeps comparing it to <input framework> and how it handles the view so much more elegantly, faster… Hold on React can’t do this and that but <input framework> can!!
It’s an endless unfair comparison, because React simply ISN’T a framework. What is it extremely good at? Handling the view. In doing so there are a lot of great side effects which React teaches you like modularity and separations of concerns. You can write recyclable components through out your app, these methods can be thought as a very functional programming way of handling business. A React components handles the view, the component simply doesn’t care about the outside world and very much like pure functions React components will always give the same output if given the same input.
The key to all this is that React like pure functions, really doesn’t care how you handle everything else in your app.
“let’s get everybody on board
So instead let’s experiment with a single section of our project, just a single page if need be and replace its view with React. That’s not a massive risk. Management, BA, scrum masters, business requirements and our Ruby developers should all be happy with minimal disruption to the entire project/app.
Be sure to pick a section that everyone agrees would improve the user’s experience if React were to take over the view.
“You can still have your backend guys happy
If you buy into React you’re not buying into a Framework which likes to control every aspect. You can still have your backend guys happy. Maybe they can experiment with making their code base become more of an API that can feed to React for it to deal with the view.
A lot of businesses will have strong code base, that they will be reluctant to drastically change. Can you offer such non intrusive flexibility with <input framework> ?
The answer to that question is more than likely going to be no!! This is a real life working example rather than a side by side comparison of <input framework> can do so and so but React can’t. Every time I see these comparisons it just makes me chuckle how the original argument is floored.
You simply can’t class React as a framework and let’s be honest React isn’t the only option out there to perform these non intrusive view layers. What I’m mostly happy about is how React is not pulling a developer into only knowing how <input framework> is written and works.
“Frameworks are great and they have their place.
This is where React shines by not being a Framework, because React is so minimal and deals with so little you are still going to have to learn JS to deal with most problems and React almost forces you to.
“opinionated Framework beliefs
Is React a framework? I’d say no, so these endless comparisons are pointless.
Use what’s right for the job, just keep in mind that the all singing and dancing solution isn’t always the right one.