Explaining to someone without a technical background can be challenging. That challenge is compounded by the creative names developers give to their products. If we are not careful, people may get confused when terms like Go, React, or Flutter slide into our conversations without explanations. The fact that we have so many software products around, sometimes solving the same issue in a slightly different way, has always raised a question in my mind. We can see how Occam's razor can be applied to benefit developers who bear the cost of deciding and picking the right tool for the right job. Why do we continue to have more software doing similar things and add to the complexity?
Of course, I can always defer the argument by citing that things exist for a reason. Bearing in mind the why, the sharing I attended (on Cross Platform Application Development) last night was insightful on the practical considerations when selecting a desirable framework for the job. I experienced a similar conundrum when I was settling on a framework for mobile development. Similar choices between React Native and Flutter. My answer back then: Flutter. I will explain some of my considerations (or the lack thereof) with what was mentioned by the speakers.
First Look
As a student, I like the fact that we do not always have to consider aspects of software durability or robustness when choosing something to learn or use in a side project. When picking a new tool or framework, the first thing that I would do is to take stock of what tools I already know. Though not entirely accurate, that would have given me a rough idea of how well-received and how much support for that technology online. One thing that I learned from the talk is to look at more data points such as Github stars and issue counts. As an example, React-native has 97.5k stars, and Flutter has 129k stars. The popularity of Flutter was one reason why I decided to take it up. Another aspect of popularity is the issue count, which I am still ambivalent about what it portrays. React-native has over 1k issues when Futter has over 5k issues. While I understand that more users might mean more complaints, other factors might also affect this metric. Whether the maintainers of these frameworks actively listen and patch the software to fix pertinent issues can be crucial when the software plays a huge role as a framework that drives the entire code execution.
Familiar VS Trendy
While the above point explains why I would prefer a trendy framework, I also understand the importance of familiarity (language or otherwise). It is especially true when development velocity and product quality are critical. A constant theme mentioned by the speakers was that developers would like to iterate on their products, frequent and fast. Therefore, choosing a familiar tool that most developers are aware of, will make onboarding and upskilling less a hassle. To illustrate, I only got to know Dart as a language used when working with Flutter and my experience with it is only within the period of mobile development that I have done. During the live coding session last night, the presenter was facing a bug due to the displacement of a variable. Looking at the code, I thought that it might be due to the incorrect assignment of the variable, which was not the case! It was the result of not me being unfamiliar with the tool used. Especially in frameworks with a lot of conventions AND configurations, developers might have to slow down significantly. Choosing something that we get exposed to frequently is a fair bet that we can adopt it fast and have it work for us in a reasonable amount of time.
The Right Job
Mobile applications have an unfair advantage of wider outreach and convenience. The ability for mobile frameworks to work cross-platform is, similarly, the biggest selling point that they have against native toolchains. As the sole developer or part of a small team, the right job often includes maximizing output and reducing maintenance costs. To have one framework that builds for both IOS and Android is a bargain that we cannot ignore. To relate to my example, I chose Flutter also because even if I started developing with the sole focus on IOS, it would be a breeze to account for the minor differences so that it works well on Android. An interesting point that I learned from the Shopee example is that sometimes tools can work together to generate greater yield. I have never thought of situations like isolating the support service into web pages(because of the significant number of custom service personnel that use it). If we can put more emphasis on our target audience and to find ways best benefit them, the user experience and the developer experience can both increase dramatically.
It is fascinating that we say to pick the RIGHT tool for the RIGHT job when there is no clear definition for what is RIGHT. Worse still, what is RIGHT is going to change in no time. My conclusion: do research, try things out, adapt and change when necessary.
P.S. This is repost of my writing assignment for CS3216.