JavaScript is renowned for having new plugins, endless frameworks all being created by its community on a daily if not hourly basis! That in itself is testament as to why the JS community is so thriving and becoming one of the biggest.
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!!
React simply,
ISN’T
a framework,
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.
So yes that’s all fantastic, promoting, pushing and showing a different way we can build large JavaScript apps.
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
At my place of work we have a lot of greatly coded Ruby on Rails code. So let’s get everybody on board and rebuild our whole project/app in JavaScript with <input framework> ? I’m sure you’d get an unanimous “HELL NO”.
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.
With React you are still prominently going to be coding in vanilla JS if you want and that to me is more important than providing an end to end solution like a Framework. You will code and learn JavaScript not the way a Framework wants you but how you chose to.
“Frameworks are great and they have their place.
I’d just rather not be known as a <input framework> developer and instead be a Javascript developer. That’s not saying Frameworks aren’t great and you are not less a JS developer for using one. Really great JS developers use and build Frameworks.
I worry more for entry level developers who don’t have a clear understanding of JavaScript and instead learn a Framework. Once <input framework> looses popularity or you decide to use another. Then you’ll have a harder time to do so as all you’ve really learnt is a specific Framework.
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
Look at how we deal with data flow in React! There are endless solutions and more importantly they don’t have to be React related! Another form of how you are forced to deal with a situation using JavaScript rather than 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.
