Choosing the Tech Stack

Delayed Decision

Now we have come to the implementation details of the app. In the previous exercises, we were only dealing with the abstract design, without specific reference to a particular programming language, or UI framework or datastore mechanism. That was so that we didn’t have to make a decision so early in the development process, regarding the actual tech stack to use, and focus on ironing out the critical details such as user interactions and system architecture.

I’m not sure about the general engineers public, but I can fall into analysis paralysis when it comes to choosing what framework to use for my app. Should I use my most familiar framework so I can build it fast? Or should I pick up a new framework I’ve always wanted to learn but risk delaying my launch? If I have started with choosing a framework at the outset, I might have spent too much time agonising over the choice of framework, and wasted the opportunity to work on the straightforward part, which is to design the actual app. (In fact, I spent half a day researching the various frameworks while writing this very article.)

Having said all that, now we have no choice but to agonise over which framework to use for the app I’m going to build. But we don’t just decide which framework to use based on preference and familiarity, let’s do this exercise methodically by going through the limitations and determine which framework can both satisfy the requirements and accommodate the limitations.

The Limitations

Most modern-day apps today are built as web apps or mobile apps. But I have a few limitations on the app that building it as a web app or mobile app may not be feasible.

Where to Store the Data?

Since this is a finance-related app, data privacy should be handled carefully. Honestly, as an individual engineer, I would not have the resource or expertise to deal with the strict laws of data privacy for my app. As much as possible, I want to avoid the responsibility of safeguarding user data and making sure there is no breach.

For this reason, I would likely want the user to have full control of the data. This is not possible with a web app, where the data will need to be hosted on the cloud, even if it’s under a third-party service like AWS, I’m still responsible for making sure I’ve set up the network security properly such that data breach is unlikely.

That leaves us with the other popular alternative, which is building it as a mobile app. With a mobile app, offline data access is possible. There’s no need to store the data on the cloud, and all data live on-device. The only way the data will be breached is when the user’s device is compromised, which is beyond the scope of my control and responsibility.

User Experience on Mobile

Now that we are considering building a mobile app, let’s see how well the user experience will go on mobile. Recall that the app is heavy on data entry and file generation. While these are not impossible on the mobile app, the user experience may not be very smooth and fluid.

For example, making data tables responsive is not an easy task. How to render a row with too many columns on a narrow viewport? On one hand, I’m not an experienced UI/UX designer to be able to solve this problem easily. On the other hand, as far as I know, even the experienced UI/UX designers still have not solved this problem fully. (In my other article comparing Vuetify2 and Vuetify3, I mentioned that the data table is not fully responsive on mobile.)

What? Desktop App is Back?

So, that leaves us with the only option we have not considered earlier, which is to build a desktop app. As far as I can remember, the last time I touched a desktop app was more than 10 years ago, when I was building a school project using .NET framework.

Should I use a desktop app framework again to build this app? It’s not impossible, I just need to spend some time to learn the syntax and toolkits, right?

What About Cross-Platform Support?

Okay, so we are more or less set on building it as a desktop app. Let’s step back a little and think about why web apps have been so popular in recent years. For me, I think the reason is because of its portability. You can view a web app on Windows, or MacOS, or Linux, or iOS, or Android, or any mobile device that has a web browser.

So, if we were to build a desktop app, we must at least be able to support viewing it on Windows, MacOS and Linux. Which means, we need a desktop app framework that has cross-platform support.

Let the Search Begin

We have identified the need to use a desktop app framework that has cross-platform support. Let’s input this keyword exactly in Google Search and see what we get.

Cue Google Search Results

After going through at least 4 pages of the search results, here’re a few frameworks from a couple articles I’ve shortlisted to be relevant:

Framework	Cons
Tauri	Require learning Rust
Flutter	Require learning Dart
Xamarin.Forms	Require learning C#
Electron	Resource intensive and large app size
Neutralinojs	Relatively new and small community
Wails	Require learning Go

Notice that I only included the Cons in the comparison table, because I’m sure they all have their strengths and can do the job that I require them to, so the only differentiating factor I’m looking at is, “How bad is the Bad?”

Tauri, Flutter, Xamarin.Forms and Wails are all established frameworks with a large community, but they require me to learn a new programming language to use their toolkits and APIs. I’m not against learning something new as it’s part and parcel of being in the ever-evolving tech industry, but I have a time constraint which is to (hopefully) build the app within 1 month. If I were to use these frameworks, then I need to spend more time figuring out how to use them, rather than figuring out how to build the logic.

Electron is an extremely popular framework, with a very large community. It allows me to use the good o’ HTML/CSS/JS stack. The only downside is that every Electron app comes with an embedded Node.js and Chromium engine, making it a rather bloated solution.

Interestingly, I found out that there’s actually a lesser known Electron alternative called Neutralinojs. It’s very lightweight because it uses native web browser library on the OS, instead of embedding the browser engine in the app. The only problem is that it’s a relatively new framework, and the community is very small compared to Electron’s.

And The Winner Is…

In the end, I decided to choose Electron to support my cross-platform desktop app. Yes, I decided to take the easy way which is to not learn a new programming language and stick with the familiar HTML/CSS/JS stack (not that frontend development is my specialty to begin with, but that still beats an entirely new language, right?)

Electron still has a pretty big downside, which is its bloat, but I still chose it over Neutralinojs because of a larger community. I’m already not very familiar with frontend development, if I had to dig around a lot to debug an issue, that will make my development time even longer.

Having said that, I hope one day I can give Neutralinojs a try, so that I can use it for future projects.

The Big “But Then”

Disclaimer time. Everyone may have a different opinion on what is critical and what’s not when deciding what framework to use. These are my own criteria (actually dangerously close to being preferences) and limitations, and may not be applicable to another person. Whatever the reason for choosing a framework is, at the end of the day, I’m the one who is going to use it to build the app, so I will have to bear the consequences of having chosen the wrong option. But we always learn from our mistakes, right? The pitfalls I experience in this project will form the guiding principles for my next project’s choice of framework.

Anyway, you think choosing a framework is the only thing I dread? No! I think choosing a name for my app is a bigger problem. But I will spare you the agony of reading through my name-picking process, because that is neither technical nor methodical.

For now, we can conclude this series of articles about the process of designing and building an app from scratch. Once I start development, I might have new insights or findings to write about, and I will publish them when it happens. I thank you for your patience in reading through all 10 articles and have come this far. Even if you’ve only read this one article, I still thank you for your 10 minutes of attention.

Stay tuned for the launch of the app!