Too many front-end tools and frameworks?

Before we begin, let me preface this with - I don't hold all of the answers and my voice isn't the definitive answer for any of this. I'm just another web developer trying to make sense of all this as I make things and share my thoughts with you. Also, I use the term front-end developer relatively loosely as that's how I got my start, but rapidly evolved to full-stack.

There is a dizzying array of tools, frameworks, language supersets, etc. for front-end developers. Want a single-page application (SPA), then you should definitely use AngularJS... wait I mean Angular because it totally changed with version 2. On second thought, maybe React would be better for you because it's lighter weight as it's just a library and not a framework. But maybe you want it to do a bit more and you're having problems with shared state, so definitely add Redux to React. If you're doing all that though, just use Next.JS and you can get much easier server side rendering (SSR). Please don't forget about Vue though. You can even take that a bit further with Nuxt.JS, which has Vue as its base, but makes SSR easier and helps you scale your app better.

This above scenario is just about picking a JavaScript framework for you project. This same scenario occurs in many different places with a web project. You choose your CSS preprocessor (LESS vs SCSS), which CSS framework you should use (Bootstrap, Tailwind, Bulma, Materialize, etc) or none, what build system and bundler should be implemented (Webpack, Browserify and Gulp), what about HTML templating (Pug, Vue in its templating capacity, Handlebars), JavaScript or TypeScript, to containerize with Docker or run without container, which service should the site be hosted on? Oh, yeah... if you're doing fullstack, which backend technology are you using (.Net Core, Node and Express, PHP) and what about your database (Mongo, MySQL, PostgreSQL). Also, pick your CMS and determine whether that should determine overall project direction (standard WordPress install) or if you go headless (Squidex, WordPress REST API, Butter, Strapi). This is all assuming you have the flexibility of a new project where you can set the direction from the start. Multiply this difficulty by approximately 1,000,000 when working through a legacy project and trying to incrementally roll it forward to modern tooling.

It's enough to drive any sane person crazy when trying to figure out what's "best". To make matters more difficult is many, if not all, of these pieces of technology have a vocal community espousing why their technology is the only one you'll need and that you should have started using it yesterday. With all of these choices before you, analysis paralysis can creep in. Before you know it, you've spent a week in contemplation-land and reality-land doesn't have any new useful code while its occupant is having a nervous breakdown. So, what are you to do?

Well, I don't know what you should do personally because I don't really know you. Maybe you like contemplation-land, so I'll leave you to your vacation. But if you want to end that unexpected trip, I can at least tell you what I settled on.

I stopped looking at these things in a "this or that" perspective. Instead, I realized - These are tools at your disposal, and like any tool, choose the right tool for the job. This means that I can use Vue and .Net Core with a MongoDB based headless CMS for one project, plain old vanilla JS with a legacy backend and a SQL database for another, and still a MEAN stack (MongoDB, Express.JS, Angular, Node.JS) for another. In my opinion, all of these decisions are correct so long as thoughtful analysis was done for what the job actually needed and not just what you thought would be fun to use. Obligatory analogy - If you see a screw, please for the love of all that is holy, don't try to hammer it into the wall because you have a shiny new hammer. Use the boring screwdriver that you've had for years. However, if that's a nail, take that new hammer and swing away you crazy kid. Swing away.

My guiding light for these things tends to be - choose the simplest solution possible and only opt into the more complex frameworks with more dependencies as the need arises or as requirements dictate. If you can solve the business need with vanilla JS relatively easily and you don't see the business requirements growing past that level for the foreseeable future, probably take a simple vanilla JS approach and save yourself the maintenance of upgrading frameworks and testing to make sure dependencies didn't start getting messed up. After that, if the problem can be equally solved by multiple frameworks and approaches, do a bit of digging on each one to see if any particular feature sticks out to you and your team - that'll be what you use. Just know that what is the fresh cool thing today, could easily be the "why did we pick this" in just a few short years, so whatever you do, please build things in a modular way where pieces can be removed and rewritten relatively simply in stages. You'll thank yourself later.

I'm rambling now. So, I'll leave you with this. Much of what I said was focused on JS frameworks because that's where I see the most polarization occurring, but this applies to any tool in your tech stack that has multiple alternatives. Learn as many tools as possible and don't get locked into just one because they're all probably pretty good in the right scenario, and it's up to you to use your discretion. If the tool you choose is based off of a base language or technology, make sure you're solid on the fundamentals of that language or technology because it'll make the tool you chose make more sense. I'll let everyone else fight about what's "THE best", I'm just going to use what I think is best for the problem I'm trying to solve. I don't want to be just a insertToolNameHere-developer. I want to be a developer that uses all the tools at my disposal to get the job done properly.

Final point - If you're working on a personal project, I say play with these tools and use them solely for the sake of using them just so you can see what you like about each one. Rewrite your personal projects a couple times with different tools to get a feel for them. It's your project and your time, so get the most value out of it and use it as your playground. You might just find a use for one of these tools in your day-to-day work that you didn't expect. Have fun!