A guide to choosing your next front-end
I’ve done quite a few posts now about Angular vs React and I’ve gotten quite a lot of feedback. So I wanted to take a quick step back and examine how do we pick what our front-end is going to be done in? With hundreds of choices in how to build a front-end how do we decide? Well, hopefully, I can shed some light on that and help you come to a decision in an impartial way.
If you’re looking for some simple definitive “use this always” kind of thing I’m sorry this ain't it. While I certainly have a favorite front-end technology, if you’ve read my content you know what it is, but this won’t include any reference to any specific library or framework. I really wanted this to be a more high-level overview of making a good decision when there are so many choices available.
Understanding your use case
Before you ever even think about writing any of your code you should already be thinking through your use case. Whether you’re working on a personal project where you can choose whatever tools you want or you’re working as a part of a team where you have less control you’re still going to do this step.
I can’t tell you how to think, but I can guide you to certain things you need to consider. Here are some of the things I generally think about:
- The size of your project
- The complexity of your project
- The project setting (startup, small team, personal project, enterprise project, etc.)
- The needs of your specific project (like if it’s heavily form-based or something like that)
- What are my time constraints, if any?
This is not a full 100% complete comprehensive list, but this should get you started down the rabbit hole. Once you’ve answered all of your questions about your use case you can start to think of the best way to go about building something.
For example, say you just want to build a landing page. Do you even need to use anything outside of vanilla JavaScript, HTML, and CSS? What if your landing page has to have fluid content, does that change things? What if a client is asking for a landing page that they can edit themselves and they absolutely need it to be done within a month? These are an example of some of the requirements you would have to take into account.
Filtering out the noise
Every front-end developer should have a sense of the noise around all the different frameworks and libraries that are available these days. There are always going to be costs and benefits with anything you choose but you need to decide if the benefits outweigh the cost. When choosing a way of building your front-end you can think about several things regarding that specific technology:
- Does it make sense for my use case? This is really broad and kind of plays into the other points.
- Will this thing work with me or against me? This is basically just asking yourself if the features of your chosen technology are going to aid or block you.
- Does it scale? This is two-fold, does it scale across the development team, and does will the code itself scale?
- Am I (or the team) comfortable with this or will they be able to easily adapt?
- Is there a good amount of support behind this technology?
These can be really subjective and definitely depend on what you’re building. The reason for that is there is such a broad range of use-cases. For example, if you’re building a personal project maybe you want to try out that hot new technology to see what it’s all about. That might be enough for you and that project. That choice becomes a lot more involved when it comes to a team setting and especially an enterprise setting when there’s usually quite a lot more to consider. Companies (especially those branded as “enterprise” companies) are slow to move and are made up of lots of different teams and developers. Getting them on the latest hot new technology can sometimes be unfeasible for many reasons.
I wanted to talk a little bit more about point number 5. I often say that the most popular solution is not always the correct solution. That goes for just about everything. However, I’m not just talking about popularity here, or community support, I’m also talking about the developers who made the thing. How well are they supporting their creation? People talk a lot about how often different JavaScript libraries and frameworks pop up, but they also die off pretty quickly as well. That’s something you’re going to want to think about because the last thing you want is to finish your amazing new web app only to find that the entire technology you used is not unsupported.
You also want to make sure that you’ve got enough community support around the technology you’re using. Having a bunch of questions you can’t answer is super frustrating and not having anyone else to answer them can be even more frustrating. It’s also super frustrating when there are no docs and even more so when there are really bad docs. Personally, I find bad documentation the most annoying because oftentimes bad documentation can serve to confuse you even more so in a sense it can be worse than no documentation at all.
Making a choice
At the end of the day, you gotta make a choice and you have to stick with it. I’ll add a qualifier to that statement and say stick with it but to a point. Change can be good and is sometimes necessary. Don’t be afraid of change, but like anything else you gotta decide if the change is right for you and your project. If you make a definitive choice based on the requirements you’re given and everything else you’ve taken into account you should see it through, even if it doesn’t work out as well as you hope or at all. We’ve all been there as developers, you make a mistake and it comes back to haunt you later. Don’t shy away from it, embrace the mistake and learn from it. Learning from your mistakes in the past will help you make better choices going forward.
At this point, if you’re still stuck deciding here’s something you can do. Take your top 2 or 3 choices and build the same thing with it, anything. Build the same thing with each technology and that will give you a better idea of the pros and cons of each. When I was starting out I wanted to build apps. I decided to build a tip calculator app for the Apple App Store, Google Play Store, and on the web to see what it was like using each technology. A tip calculator is still my go-to choice for vetting new front-end technologies if you want an idea of something to build. Once you build your thing, go back to the process and compare the technologies with your use cases and make your choice. This may seem tedious, but in the long run, it will help you out.
Hopefully, I’ve been able to help you pick your next best technology for building your front-end, but this general process can be applied to really any kind of technology we have to choose.
If you’ve enjoyed this article I’d love for you to join my mailing list where I send out additional tips & tricks!
If you found this article helpful, interesting, or entertaining buy me a coffee to help me continue to put out content!
