The Use Case

TL/DR #

Throughout my software engineering escapades, I’ve seen enough tool debates to fill a tech conference. Some swear by their framework like it’s family, others treat their chosen library like the Holy Grail. So, when the eternal question pops up: "Vue.js or React?"—grab your popcorn, because it’s showtime!

Here’s the skinny: Use Case. That’s the golden rule. Picking a tool isn’t about brand loyalty like we’re choosing sports teams (Go Frameworks!). Whether you’re crafting the next killer app or simply hacking together a project, the right tool really depends on what you’re building. MongoDB for your startup’s skateboard shop? Sure, if you like skating uphill. React for your mega-corp’s enterprise software? As solid as grandma’s fruitcake.

Remember, software development isn’t just a job; it’s like cooking. Sometimes you need a blender (Vue.js for a smooth mix), and other times, you need a food processor (React, when you need that extra grunt). But let’s not get carried away. Don’t be the person with a kitchen gadget for every task and no counter space left.

The famous Use Case #

Well, in my time as a software engineer, I met a lot of people that at the end, always stick to only one tool. Doesn’t matter if it’s some kind of language, framework or even library, but there is always going be debate which language is best, which framework is fastest and easiest to use and which library could save you a lot of code with no consequences.

From my experience, everything resolves around the famous - Use Case

What is Use Case? #

A use case in software engineering is a methodology used to describe a system’s behavior while it interacts with external users, systems, or processes. Essentially, it identifies the requirements of a system and helps in understanding how the system will behave under different scenarios. This approach is particularly useful in software development for elucidating how features should work and what needs to be done to ensure the software meets the expectations of the users.

What does this tells us?

Well first, the tool you use at the end matters, even though it may not appear to do so at first.

Example #

Let’s see what it takes to build a bank system. You could use noSQL database like MongoDB or AWS DynamoDB. Just because you like it and think it’s cool. Will it work out in the end?

Well depends.

Again, everything is use case, and by definition of the project you are working on, yes, maybe you can use NoSQL database, if you are handling a large volumes of data, and for some reason you need unstructured or semi-structured data (which you probably don’t), then maybe it is a right chose. But probably, you are much better of using for instance, Postgresql as database, having a relation database that you know that instance has to have specific properties, especially in bank systems, where every piece of information that is either lost, or corrupted can have serious consequences.

WeLL I liKe hOw fAst I caN seT it Up anD SPeed up DEvelopment
> Probably a die hard React Developer

It may be true, but at the end, is it going to fulfil it’s purpose to it’s maximum? Is it going to cause road blocks during development, which could’ve been avoided by just using the right tool?

Those are all the questions that during a brainstorming and before an initialization of the project, the developers need to think about.

I like React

Well I like it too, in fact the first framework I learned is React. While interviewing for the job, I got asked have I used any other framework besides it, and I said no. They asked me if I was willing to learn a new one, and I said gladly, even though I didn’t like the idea of using something new. The framework was Vue.js.

They migrated to it, because while researching, the found it the most soothing, most simple way to write the frontend code, tried it for a few projects and it did really well.

I got the job, and while I did my own research, I liked the syntax, but I thought i couldn’t for the life of me, find myself using it because it did have a much, much smaller ecosystem than React. After a while working on it, I really started to like it, and started to change my mind about the use case.

I think in frontend world, that use case is much more less pronounced than working with the actual server, building the back side of the system etc. In the end it all compiles to Javascript.

This brings us to a pivotal point.

Flexibility vs. Rigidity: Choosing the Right Tool #

In the world of software engineering, being dogmatic about tools can sometimes hinder progress. This is especially true in a dynamic environment where requirements, technologies, and best practices are continuously evolving. While some developers may prefer the flexibility of Vue.js or the vast ecosystem of React, it ultimately comes down to what fits best with the project’s requirements and the team’s capabilities.

Example Redux #

Imagine you’re tasked with implementing a new feature in an existing application that has a complex state management requirement. You’re familiar with React, and your first thought might be to use Redux, because, well, it’s robust and you’ve used it before. However, consider the learning curve for new team members or the integration complexity with existing code. Perhaps a simpler context API or even a third-party library like Zustand might be a better fit for this specific scenario.

Importance of Adaptability #

Being adaptable as a developer is crucial. This means being open to exploring new tools, languages, or frameworks if they can deliver better outcomes for your project. For instance, when I transitioned from React to Vue.js, I realized that while the ecosystem was smaller, the overall developer experience and the simplicity of the framework allowed for faster development cycles on certain projects. This adaptability can often be the difference between a good developer and a great one.

But also on the other side, sometimes there is no need of adaptability. Imagine a workplace where everyone is used at using bootstrap. It has it’s own semantic way of doing things. And you like Tailwind. You really like tailwind and the way that it can speed up your workflow. You go to your superiors with a great idea, and at the end, get turned down. Why? I mean, why not?

Exploring new tools is always nice, but in a work environment that already has a lot of it’s workers used to one way of "thinking" and writing code, a big change as Tailwind can be big.

For comparation, this is the button in bootstrap and tailwind.

Bootstrap

<button class="btn btn-primary">Submit</button>

Tailwind

<button
  class="bg-[#007BFC] px-3 py-1 text-white rounded hover:bg-[#005FCC] transition-colors"
>
  Submit
</button>

Well, this is totally different writing of the same thing. Teams of people should adapt to the new css framework just because you thought it was nice, and didn’t actually upgrade the current working flow. New technologies aren’t always the solution, but in right circumstances can be beneficial.

Final thoughts #

Ultimately, every tool has its place. Vue.js might be the perfect fit for projects that require a quick setup with less complexity, while React might be ideal for applications where scalability and a comprehensive library ecosystem are paramount. The key is to assess the use case thoroughly and choose a tool not based on personal preference but based on what will serve the project best in the long run.

Being flexible and knowledgeable about multiple tools, frameworks, and libraries allows you to make informed decisions that align with the specific needs of each project. After all, in software development, the best tool for the job is always the one that most closely aligns with the project requirements, team skills, and the end goals of your application. The debate between Vue.js and React isn’t about which is better universally, but which is better for your current project’s needs.

Just don’t go overboard, also learning every tool is not a good choise either. As a wise man once said: