Best practices aren't always the best choice

Sean W. Lawrence -

The answer to everything is "it depends"

I rarely trust people that seem to already know the answer to a question about a complex topic without them first diving deep into the problem. Complex problems are nuanced. And a strong decision requires independent thinking. Not just parroting what the rest of the world thinks.

Want an API? You probably shouldn't just scream out something like GraphQL without more context. GraphQL is wonderful for many things. But maybe you don't need all of it's power and complexity. For example, full stack frameworks like Remix and NextJS allow you to pass data directly from your server to your frontend code without an API layer.

Trust, but validate

Sometimes you hear things like "Rust is the best language. Everyone has said it's their favorite in the Stack Overflow survey for 6 years in a row!" And while that may be true, I encourage you to tinker with building something fun with it and form your own opinion. I enjoyed learning Rust and love the functional API it offers. But it was more complex than my daily driver (TypeScript) and didn't have as large of an ecosystem as JavaScript or Python. With that experience, I'd reach for Rust if I was building something that already has stable crates and the project requires stronger typing or strict performance constraints than TypeScript or Python can offer.

But the point is that without the tinkering, I'd have it in my head that I'm missing out and things would be so much better if I had used Rust when starting a new project. The grass is not always greener.

In a similar vein, before using a third-party package to do something, I suggest timeboxing a small effort to building it yourself. You might be surprised at how far you can get with writing vanilla code. Especially on the web. For example, the new APIs for things like Intl.DateTimeFormat make packages like date-fns or moment.js less necessary.

If you check Hacker News often enough, you're bound to see posts about exciting new tech. And then a follow up a few hours later from someone else about choosing "boring'" tech instead. Both choices have tradeoffs.

Boring is usually a solid choice. Something battle-tested and older will often offer you detailed documentation, code examples, answers on Stack Overflow, blog posts, etc. to search for what you're trying to do. Cutting-edge challenges might be harder to solve though. For example, merging in many different data sources into a single, unified API is not as easy to accomplish without a relatively newer technology like GraphQL. Doable, but more challenging.

New technology can also be a strong choice. It was probably written by someone that found a problem too cumbersome to solve with the boring tech and decided to make it better. Like the GraphQL example. Back when REST was released, having different data sources and creating a unified API wasn't as necessary as it is today where the microservices pattern and third-party integrations are more popular.

Conclusion

I prefer a bias for action over taking too long to decide something. I usually start with the new tech on a small spike to get my hands dirty and feel the pain and joy of using it. It's usually easy to see right away if something is mature enough to use in production and if it's worth taking the risk over the boring technology.

I've found that most choices are two way doors and are easy to redo as needed. My recommendation is to follow your curiosity and due your due diligence at the same time. Timeboxing whenever possible to ensure you don't get too deep in the rabbit hole before providing real value to your customers.

And the next time you get asked if A is better than B, remember to say "it depends."

Happy coding! SL