It Is Not Just About Having The Right Tool for The Job
After launching my email list, I received a ton of great questions. Here's one of them:
I would be interested in post about technologies / tools / techniques you use for stable production applications. Not just javascript of course.
Instead of listing specific technologies, I'll try to express the thought process behind the technology decision. You could say that using the right tool for the right problem is the only thing that matters, but, unfortunately, things are not that straight-forward.
Choosing a perspective to take
As an independent web developer, I can only speak from a web development perspective. If you're programming embedded devices or writing a database engine, you probably have different criteria. I can't even talk about web development as a whole; different areas have their own criteria (for example, apps and websites with banking services criteria). I have primarily developed single-page applications for SaaS-services. Now that the disclaimer has been dealt with, let's look at what to consider.
Things to consider
To keep things simple, I'll use a word tool to describe a technology/library/framework.
It is about comparing not only two competing tools, but also versions of the tool. Some examples of tool versions that are not backwards compatible: AngularJS version 1.x to 2.x, ASP.NET to ASP.NET Core, and Python.
Short checklist of things to consider:
- Is the tool suited to the problem?
- How essential will it be?
- What are the alternatives?
- How easy will it be to switch to an alternative?
- What is the type and availability of support?
- Does it have a lot of open issues?
- How large is the user base and how active is the community?
- How easy is it to learn (documentation, tutorials, books, videos, etc.)?
- What is known about the future of the technology?
- What are the licensing requirements?
- Is it easy to find people who are interested in learning the tool?
Going through the checklist
Obviously, the first thing to do is understand the problem. Then, make sure that the tool is what you're looking for. Let's consider a small example: I am creating a web application, and the URL must change when the user navigates to a sub-page. Therefore, I need a client-side router.
In this scenario, the problem is choosing from dozens of router libraries. On the other hand, the negative impact of a bad choice is minimal. When the router logic and usage is isolated from the app itself, changing the router isn't a big deal.
In this example, I would check licensing, open issues, user base size, and documentation. Historically, there have been many client-side routers, so the collective solutions should be very polished (emphasis on should).
Bigger decisions (such as a client-side framework or view library) require more focus on ease of learning, the tool's future, licensing, support, and user appeal.
As for the future of the chosen tool, large open source and commercial products tend to have a roadmap. Sometimes, looking at the roadmap also gives you ideas about the kinds of features to expect.
The last (but definitely not least) consideration is how much the technology appeals to developers.
Appealing technologies
Recently, there was a popular blog post with a slightly click baity title: PHP Sucks. The post was interesting because it wasn't so much about PHP itself as it was about the social stigma the language carries. One practical implication of its (perhaps unjustified) negative reputation is that PHP doesn't easily fulfill the requirements of the "Things to consider" checklist despite possibly being a good solution for the problem at hand. This is a very unfortunate situation because, as in most cases, the criticism is based on false information. Things may have improved.
PHP is a very popular language and you can argue that you should be able to find PHP developers. This is only a hunch, but I expect that it would be hard to find seasoned developers to continue developing the product, especially if they would only be doing back-end programming. The stigma would definitely be a burden in their next job search.
I've used PHP as an example only. Appealing technologies applies not only to languages, but also to libraries and frameworks that greatly impact the codebase. Angular 1.x is a good example because learning it would be demotivating. Here are my thoughts on that: Version 2.x is clearly more modern, and project contributors learned a lesson from 1.x. They saw that releasing an incompatible version is better than continuing with 1.5. Why on earth would I spend time learning 1.5-related concepts and APIs, especially if I'm only supposed to work on the front end?
I think these kinds of topics should be considered when, for example, planning to migrate to a newer version.
Conclusion
What I've written represents just one perspective. Startup founders, DevOps with a twist (shoestring budget), etc., represent other points of view. Choosing a tool thoughtfully is always good. Sometimes, you might not even need one.
Writing a proof-of-concept solution will reveal problems with the chosen tool, such as a lack of documentation or a cumbersome configuration.
Thanks for reading and see you next time!