Since I was a kid I enjoyed racing cars and racing events. I always played games within this theme - like Gran Turismo, Forza Motorsport, NFS, F1… and also tried to follow the tournments.
I remember playing with my cousins those endurance race events on Gran Turismo, with 24h or 400 laps duration. We took turns to play, trying to not get so tired; also in accomplish to win the race game.
And, looking back at those old (and good) days I was thinking about front-end development almost as an endurance event - the event is your project, the car is your tooling, and the finish line are the project’s deadlines or the due date to deliver something.
If we continue thinking about it (the metaphor), we can see several similarities with both worlds - we have newbies and experienced developers (and racers), we have fastest and slower tools (and cars), we have strong and weaker teams and leaderships (and crews), we have easiest and hardest tasks to do (and circuits), and who wins in the end is who has more balance - not the faster nor the stronger.
Front-end frameworks are almost like racing cars - we have a lot of them, each one with its own technical features, communities and documentations. Some of them are strong, easy to use, and we can do almost everything using it - some others are heavy, slow and hard to use; and we can do little using them.
Since the emergence of ES2015 (ES5, ES6 - I always lose myself) we’ve seen a lot of nice JS frameworks coming around - React, Vue, Angular, Svelte, Ember, Polymer, Meteor, Node… There’s a lot of them, and every day we can find a new one (which claims to be the solution to all problems). We also have seen a lot of great stuff done with those tools; and a lot of shitty stuff done as well. So, what’s the difference between the nice and the crappy things?
We can spot a lot of differences - UX, the architecture, the bundler, performance issues, browsers support, even the developers (which I avoid to compare). But, I believe the main difference we can (and we need to) spot is the value delivered - the problem solved.
If the car is faster, doesn’t mean that it’ll win the race. As well as a framework - you won’t solve a problem or deliver value just because the framework you’re using is faster or has a large community. Beyond the framework’s reach - which is very important - you need to consider if your team can do great stuff using it. Not everyone can win a race just because they’re driving a Ferrari.
For many users, doesn’t matter the architecture used or how the bundle is generated. They care about support, mobile-first design, how the app will work over divergent network conditions, and if they can solve a problem using your app at all.
Another great point we can spot in this metaphor is: endurance races requires experience, resilience and continuous hard working/learning. You must know when to pace up and down, when to try a takeover, when to push the car’s limits, when to stop in the pits… As well as you must know when to use X or Y tools or approaches, when to speed up your team, when to ship new features and when to remove them…
Both in racing and in development, the only way to gain experience is doing stuff; and it takes time, because you won’t master anything overnight. Everyone has their own pace, so try to keep a daily routine to learn something new, or trying to do something different.
You won’t win the race when you want, but only when it’s over. And you won’t reach success when you want, but only when people using your app sees value on it.
I’ve seen a lot of “fights” among developers, claiming that React is better than Vue, or WordPress is shitty, I won’t use it… Every developer has their own preferences - some people like React, some others like Angular; but the correct discussion would be “can you deliver value using any of these?”.
I have my personal preferences, and they change (a lot) over the time; I’m always trying not to get stuck with technology, or not to get too much accommodated with a special tool. Over the last years my mantra is: “the simpler, the better”.
Software development is meant to be simple - if it isn’t, there’s something wrong. I’m not talking about the complexity over a language, or over a specific architecture - I’m talking about doing nice stuff, which solves problems.
So, talking about tools, a great tip I can give you is to choose what better fits your needs. If it’s React, go on; if it’s Vue, go on… Don’t try to choose based on your colleagues’ opinions, or based on a blog post showing great results using X framework. There aren’t any silver bullets.
When a pilot needs to know a car, he will test it; when you’re buying a new car, you will test them; and when you’re choosing a tool to use, you need to test it too.
A nice way to test tools is to create POCs - or Prove of Concept. If you’re not familiar with it, basically by doing a POC you’ll try to create the critical part of your project, using a great amount of possibilities. After doing so, you’ll reach a final verdict about what is the better path to go.
When you’re doing a POC, take notes on what everything you’ve noticed - performance, scripting time, building time, the difficulty over the tasks, how the configuration goes… And, in the end, see which alternative better fits on what you need to do. There’s no secret.
By doing so you’ll ensure that you’re following the right path, doing the right things and you’ll have a great possibility to win the race by yourside.
