CTO Choices – What happens when you need to choose your Frontend technology stack?

Christopher Maneu

Building a robust technology stack from scratch is a challenging task. CTO Choices is a series of articles aimed at CTOs, Tech founders, and project creators. They help you ask yourself the right question to pick up your tools. We try hard to give you honest, enduring, and agnostic advice. That is why – to let our true self speak – the last section of each article will present a heavily opinionated choice. And you will have the right questions to assess if this choice is good for you.

Whenever you are creating the new top website, viral mobile app, or shiny IoT object, I can bet that your next project will have some form of UI. The number of possible choices in this domain is almost limitless: from Desktop Apps to static websites to Kotlin Android apps, including Apple App Clips or Progressive Web Apps. In this article, we will take a high-level look at the different kind of Frontend application types, and give you some pointers to have a great start for your first UI.

Do anything you can to avoid creating your own UI

Wait, you are here to give me advice about choosing a UI stack, and your first one is not to build a UI at all?

Yes. And no! In any development team I know, resources are finite. Building a great UI may take you more time than building the core of your app logic. We are inundated by UI all over our screens, so our brain tends to produce what we saw before: more UI.

However, there is a lot of techniques to help you not build a UI: using UI developed by others! You have two main ways to do this: – Integrate into another product UI – Leverage another UI for data input & display.

There are plenty of personal & business apps that are already used by your target users. So let’s leverage it! You can create a chatbot in Messenger or Teams, you can create a pane in Excel or Outlook. By doing so, most of the UI is both smaller to create, and probably multiplatform. You can also use the existing UI as is and integrate it with your backend. Do your users already use an app with a webhook feature you could use? Can you use tools like Google Forms or Microsoft Forms for your data input, and just hook into it with automation tools like Power Automate or Logic Apps? If so, do it! Yeah, at some point, you will probably want to implement your own UI. Just use the available UI as long as you can.

The last piece of advice I usually give is to widen your vision of what is a UI. About a year ago, I’ve developed an app for a sports club to let trainers know who is coming to the next training session only with emails. By leveraging technologies like AMP Email and Outlook Actionable messages, you can send rich emails that auto-update their contents and even provide quick actions to the senders.

Chatbots, emails, push notifications and existing UI are not only a way to speed up the development of your frontend, but also an opportunity to craft a better experience for your users. Ultimately, you will probably need to build your frontend app. Let’s see which criteria you should consider settling on a Frontend technology stack.

Define which platform you should target

I’ve helped hundreds of developers pick the right platform for their next project. I always start these kinds of conversations with two questions: which languages & frameworks your team master, and which platforms are you targeting in the next two years?

The first question is quite important. Because learning a new language and a new framework can be a daunting task, the best choice of frontend framework for me may not be the best choice for you and your context. Learning a language also requires learning an entire ecosystem of tools, package managers, and libraries. Following the latest trending framework may not be the best choice either.

The next question is about your target platforms. My experience tells me that this question is most of the time overlooked by project creators. Most of them tend to say that they are creating a web app, and if they have to do something else, they can still create an Electron or Cordova app. Adjusting for such a change after months of development will probably imply quite a refactoring and a lot of hurdles.

What about hybrid mobile apps? I’m not fond of hybrid apps, for several reasons. First, hybrid apps are leveling the features of the different platforms. Even if almost all hybrid mobile frameworks allow you to bind native components – and thus virtually access any native API – you’ll either need to know how to do native development or be dependent on the framework or its community. Some of them are very active, but it’s something to bear in mind.

Then there is the “code reuse” advantage. I’m doing cross-platform development for more than 15 years, and I can tell you that there are very few platforms out there that can offer great cross-platform code sharing. Let’s take the popular React Native framework. It allows you to share code between mobile platforms (and to some extent on Windows and Mac), you may need to use React(js) for your web app. There is still a benefit from leveraging a similar toolchain and ecosystem. The truth is creating cross-platform apps is hard.

I’m also not fond of the usability versus complexity ratio. Distributing such apps needs you to go through the different App Stores process. This is a complex process. It’s a good tradeoff if you’re leveraging a great integration with the target OS. But most of the hybrid apps I’ve seen don’t provide a great app UX, most of them don’t work offline and few ones require one of the OS features that are not completely wrapped into the hybrid shell.

That’s why I tend to default to Progressive Web Apps (PWAs) instead of hybrid mobile apps (you should try PWA Builder). However, I don’t rule them out entirely: remember my first question – if you know JavaScript and Vue, maybe Ionic is a good choice for you – and as the web space in general, the hybrid space is moving fast!

When I’m designing backend infrastructures, I have this saying: “Deploy for 1x, Implement for 10x, Design for 100x”. The main idea behind this sentence is that architectural choices are the most complex to change over time. So, while building your product, you may not code all the foundations for a time where you will have to support 10 platforms, but you can lay the land to add support for a new platform without a huge refactoring.

Then, narrow your technology choices

When you have your target platforms, you can go on evaluating other criteria. You will have your own criteria of course, but as a reference, here is some I have for a Frontend framework: – Doesn’t lock you in a specific UI style (= bring your own design / support platform-native design) – Allows several architectural patterns (MVVM, Component-style, etc…) – CD/CI support – Support platform-native distribution model (ex. on mobile, should be able to deploy it on all stores) – Support accessibility features

You can still have a rather long list of frontend stacks after reviewing these criteria. That’s where I tend to list all the platform features are needed that could rule out a web (in-browser) app: do you need to access to USB or sensors (it may also come to your browser)? Do you need an app that works offline (and can’t use service workers)? Today, there are fewer and fewer requirements that prevent you from creating a web app.

That’s usually when I’m looking into these general criteria:

• language support,
• being able to develop easily and within a remote container,
• choice of deployments,
• extensibility,
• performance,
• long-term maintainability

When you architect your app, think about the day you’ll trash your frontend

What if choosing your frontend framework is not that important? When I was working at Deezer, we started our Windows apps for Windows Phone 8, then ported our app to Windows 8, then ported it again to Windows 10 and a last time on the Xbox One platform. For each of these ports, a huge part of the front code was rewritten from scratch. What about the core app (storage, HTTP Requests, DRM, etc…)? Almost no change! I’ve seen this story many more times, including one time where developers were creating an Angular frontend for…en AS/400 app!

The fact is, for a lot of reasons, the frontend of your app is probably the next component that will get rewritten. You should carefully think about which business logic you’re embedding in the UI versus other parts (backend, database, workers, …).

In modern apps, you will have to code some business logic in the frontend. And this code should be well documented and unit tested. When choosing your framework, it’s then important to spend time evaluating (and testing) testing frameworks and even refactoring tools.

An opinionated choice – Blazor, AlpineJS, Tailwind & Xamarin

Disclaimer: I’m working with the .NET ecosystem for more than 15 years, and now works for Microsoft. Yes, it’s an opinionated choice :).

During the last year, I’ve kickstarted at least 10 new different projects. They are rather small compared to the projects I worked on during my career but having gone creating the same building blocks with this set of tech consolidated my opinion: Blazor, Tailwind CSS, AlpineJS, and Xamarin.

Blazor is a web framework to create web front end applications using C#. You can either host them on a server – and all the communication happens through WebSocket – or build it into a WebAssembly package and so having your C# code being executed in the browser. Building apps with Blazor – even if this product is relatively new – made me happy again to build web apps. The different types of execution models allow to simply create SEO-friendly websites or powerful offline PWAs applications. As I can share easily my code between my backend and my frontend, it’s yet another issue I don’t have to deal with: I can issue a get request to an API asynchronously, parse the result as a JSON document and get a typed object in a single line of code!

As Blazor is simply outputting HTML, then you need some CSS. Bootstrap CSS is widely used, and I have it on several projects. However, when it comes to creating your unique UI, I always had a lot of trouble customizing Bootstrap styles. I know it’s feasible, and I’m probably not savvy enough in CSS :). TailwindCSS is what we call a utility framework. That means it provides building blocks for creating a UI, but no components. There are no “Tailwind Buttons” (except on a paid component collection). With Tailwind, I can now build my custom UI within minutes. Combined with Blazor components, I’ve found a rather productive and enjoyable way of building web UI.

Even if I favor Blazor for a lot of things nowadays, some web pages don’t require such power. In this case, I’ve found AlpineJS to be an interesting alternative to the established frameworks (React, Angular and Vue). It’s very light, doesn’t require me to put my hands into Webpack or yarn, and offers a quite simple syntax. In a way, I see it like _the new, modern jQuery _. It may not be the right platform for building a huge web app, but can be a great choice for adding interactivity to small pages & sites.

As I said before, I’m a mobile developer at heart. I’m still creating small mobile apps. For these apps, I tend to default to Xamarin. If you don’t know, it’s an open-source app platform for building Android and iOS apps with .NET and C#. It allows me to create mobile apps very easily – the last one I prototyped even had support for Android TV – while still sharing code with my backend.

I said it, all this is an opinionated choice. The fact is I still didn’t found a tech stack outside of .NET that allows me to create all sorts of apps, from WebAssembly to mobile, from backend to data science. Building apps with Blazor, Tailwind, Azure Functions, and Xamarin Forms in the last months was an enjoyable and productive experience. As long as you’re able to create enduring apps while enjoying it, your opinionated choice is probably as good as mine ;).

What criteria are YOU using to pick your frontend stack?

Creating Startups DevBlog is all about sharing real-world experiences. So we want to hear from you! Do you have another approach for choosing your tech stack? Do you use other criteria to refine your choices? You should share them in the comments sections!

Christopher Maneu Startups Cloud Advocate, Cloud Advocacy

Follow