How do You Choose a Front-End Framework?
Have you ever experienced the crippling fear of choosing a frontend framework to go deep on, to use for your next project, or to specialize in?
We've got sparse time to spend learning, and how we choose to specialize is a critical aspect of being a web developer. It's a choice that makes a difference.
It's a decision that matters.
For me, and many others, the choice is very mainstream.
- What are other people learning and using?
- Who will be working on the project?
- Where are the jobs?
- Is this something we can hire for?
- How's the community?
- Are the docs excellent?
For others still the choice might be more granular and specific for a particular problem.
One of the most critical factors is who will be working on a project.
If it is just myself, I might go for something experimental for learning or evaluating new less proven technology and patterns.
If it is myself and one or two other people, we can all chat and decide what we want to use for a given project.
At egghead we've gone through a lot of experimentation with various ways to utilize CSS. The experiments are on smaller free standing projects so we can explore the current options for CSS-in-JS and figure out what works best for all of us and our users.
If you are choosing technology for larger teams, more questions arise.
More care must be taken in the evaluation of new tools and patterns.
This is why "enterprise" software lags behind the bleeding edge by many years. It's why you can find COBOL actively used or any number of "legacy" languages, frameworks, infrastructure, and practices.
But those slower changes are a result of our individual experimentation and exploring tools at the bleeding edge.
This includes the inventors that are dissatisfied with the status quo and are out there thinking about the framework that doesn't exist yet. Something new. Something better.
There's never "best" practices. We only have what works right now 😂
Speaking of best practice I really enjoyed this short 15 minute video from Michael Jackson that digs into what really good composition can look like for building components and how we can use that in React to avoid using Context willy nilly and not be stuck with "pass the puck" style prop drilling in our apps. It's generally interesting and I think the rules and ideas of composition are broadly applicable and not just related to React.