Airbnb, JIRA and VSCode — would you build these apps in the same way?
Different types of Frontend apps require different approaches. Understanding this distinction is important for setting the right priorities as well as for making good technical decisions. In this article, I talk about the specifics of these Types and the differences between them. Also, I share some advice and handcrafted memes.
There is More Than One "Frontend"
Nowadays, we have hundreds of Frontend practices, patterns, libs, frameworks, and architectures. But not all of them are suitable for every app. Using even the best tools for the wrong purpose will cost you and your team tons of time.
From my experience and observations, most of the Frontend apps, from a perspective of "what it is for", fall into one of these groups:
Selling stuff — "Retail Frontend".
Providing UI for web services and data storage — "Facade Frontend".
Solving problems on its own — "Tooling Frontend".
Of course, Apps are rarely "pure": different parts of a Frontend app might belong to different groups. If we'd try to mark some of the well-known products by the group they belong to, we would get something like this:
| App Type | Example | Type of Frontend |
| Project Management Tool | Jira | Facade, Tooling |
| Hotel Search And Booking App | booking.com | Retail, Facade |
| Code Editor | Atom | Tooling |
| Whiteboarding App | Miro | Tooling, Facade |
So from this perspective, JIRA mostly is a Facade, but its text editing capabilities and its interactive search query composer are Toolings. Miro is mostly a Tooling, but it manages different boards and operates with different data underneath, which are elements of Facade. The client app of Booking.com is a clear Retail, but the part where you view your bookings is rather a Facade.
Dangers of Mistreating Your Frontend
The problem is that very often developers don't reflect much on the actual needs of their app. Instead, people tend to bring in things they learned from their previous projects or things they have found on the Internet — cause it's something familiar to them or cause they want to try things out.
Sometimes there'll be nothing wrong with it. On average, this will improve some areas that didn't need improvement. The worst-case scenario is that this will overcomplicate the application and make further maintenance more expensive.
Examples
Case 1: year 2016. A developer from my company is asked to create a simple one-page mobile-first landing. Instead of just creating an HTML+CSS page with a native form for contacts, a few days were spent on setting up React app with Routing and State Management.
Case 2: A very concerned developer raises the "big problem": "Our State Management approach will not be compatible with React Server Components! And they are coming!". There were neither the reasons nor the plans to even consider such a migration.
So to avoid wasting time, to correctly set technical priorities, and to pick the right tools and approaches, it is very important to understand the difference between the needs of different types of Frontends.
Retail Frontends
As I mentioned, Retail Frontends (or simply — "Retails") are dedicated to selling things to people. Sometimes, visually, they might look very similar to Facade Frontends, but fundamentally they are very different. The main needs of Retails are the following:
Retails have to be discoverable on the Internet, so Retails have to be SEO friendly. So at least partial Server-Side Rendering is a necessity.
There can be no special requirements for user devices — Retails must work on any browser and device. Retails have to be mobile-first, and the memory consumption shouldn't be too high.
Retails should be accessible even on weak and unstable networks, so developers have to be mindful of the size of the scripts and assets they transmit over the network as well as of corner cases such as lost connection.
Retails have to respond to user actions as quickly as possible — poor performance might lead to user churn.
Retails have to be accessible to people with disabilities.
Retails might need flexibility with projections of data, so REST API is not always a right fit.
Retails are not always huge codebase-wise, so the problem of codebase scaling might not be that important.
💡
Regarding codebase size: Retail App usually is accompanied by other internal apps - to manage inventory, logistics, people, etc. These can be huge, but these would be Facades or Toolings.
Retails usually have many active competitors, so go-to-market speed is a crucial factor.
Retail Apps aren't always rich in interactions (they tend to be as simple as possible for users' convenience), so using State Management is not always a good idea.
Facade Frontends
Facade Frontends (or simply — Facades) are basically interfaces to manage data and interact with complex Web APIs, in a human-friendly way. There are many similarities with Retails, and it is fair to say that some of Retails practices would only make Facades better; and yet the focus there is different:
Facades content is rarely facing the Internet, SEO is not an issue. Some marketing pages, registration pages etc. — these would be Internet-facing, but they would be Retails.
Many Facades (if not most of them) are used in offices, by people with relatively decent PCs, so performance optimisation is not that crucial. Usability on mobile devices is usually necessary, but it's rarely prioritised.
Facades are rarely expected to be used with unstable connections, "airport lounge internet" would probably be the most extreme usage conditions.
People who use Facades will not churn because of a page load time (as long as they can perform their tasks within the app), so the size of delivered scripts and assets shouldn’t be a primary concern.
Blazing-fast app performance is only a "nice to have" for Facades. As long as the app is not very slow and the job can be done, it is not a priority.
Any modern app should be accessible, but as the user base of Facades is much smaller compared to Retails, the demographics might be predictable. So sometimes rich accessibility is deprioritised if the business rules it out as not important.
Contrary to Retails, Facades may grow huge, so proper app architecture might be a very important thing and it is worth the time investment.
Facades may have tons of interconnected features, so State Management is usually needed.
Tooling Frontends (or simply — Toolings) is probably the most interesting group from the engineering perspective, as they usually go out of the scope of the usual List-Form-Modal routine we have in Retails and Facades. They usually require a completely different skill set compared to the usual Frontend development.
💡
Don't believe me? Go check out the codebase of
VSCode.
The main difference between Toolings and Retails/Facades is that Toolings don't rely much on logic implemented on the backend, they implement logic and business rules on their own. So the approach to Toolings must be completely different:
The separation between View, what you render, and the App Logic, is a must. State Management is a must.
Functional Programming usually would not be a good approach, as its primary strength is data processing, which is rarely what Tooling needs. Stay away from Redux.
Proper architecture is one of the main values for Tooling, as the feature set might be enormous.
As such products are not something people develop daily, there is little to no guidance to approaching them on the Internet.
Performance is important as users tend to spend a lot of time in such apps. The sluggish UI will annoy users.
Relying on Software Engineering fundamentals is the only way to survive unless you are a genius.
Advices
No one knows the problems and specifics of your app better than you, not even me — unless I work with you. However, I'd like to offer you some pieces of advice from my experience.
Mix and Match
Apps are rarely just purely of one type. Some problems might be better solved using approaches meant for them. For example, implementing complex behaviour with just React API "cause your app is mostly built that way" usually very soon starts to be the source of regrets. Or the opposite, doing simple repetitive things with something sophisticated is usually not the best way to spend time.
For example, it's not a bad idea to introduce State Management like MobX/XState only for a small part of your app which would benefit from it. Or to pre-prender the home page of your app. In simpler terms — be creative.
App Needs >> Your Preference
You might be a member of the Next.js fan club and might have the face of Dan Abramov tattooed on your shoulder. You might have a medal of honour for developing React applications and you might be a veteran contributor to React Router. But sometimes using things like Vue or Angular might be a better choice. The opposite might also be true. Stay open-minded.
Be Careful With Influencers
An interesting fact: most of Frontend's well-known speakers, bloggers and other public figures are from Retails world. They are great people and their work pushes the industry forward, it makes our lives better. And if you work with the Retails yourself, I envy you — things like Next.js, Remix, and Qwik are truly great.
But their experience, their priorities, it's all Retails-first. If your Frontend is not Retail, repeating the same things they do or recommend sometimes might result in something very distant from what was intended.
💡
Many times I've seen a story like this — people start Facade as Retail (cause they are confident that this is the only right way). Then, they create a mess and leave the company for something else, "cause it's all legacy code", leaving the matter of dealing with it to their successors.
Always keep your critical thinking "on". No one can know what your app needs unless they work with you. You are not obliged to jump on anything new and shiny unless you really need it. Even if "everyone is using it".
💡
I am not saying though that you shouldn't listen to top-people in Frontend, quite the opposite — follow them on socials, buy their courses, watch their conference talks — learn from them, just don't follow blindly.
Closing Points
The main message here: be aware of the key features of each Frontend type and classify things you already know and the new things you learn by "where do they fit best". Then, in a time of need, you will be able to make decisions that are strategically right.
A few additional notes that go slightly out of the scope of this article:
Hypothetically implementing all the good parts from all types of Frontends in one app (regardless of the type) is a good idea. Realistically it will always cost a lot, and not every business will want to bear the cost.
Some parts of non-Retails might be meant to delight the user. For example, this might be some new feature that is meant for attracting new users or preventing churn. So even though they might not be selling anything, they might need the same attention as Retails.
For Hiring, when screening the candidate's experience, domains they worked with (like "automotive" or "finance") are not as important as the type of Frontends they worked this. An absolute match is not necessary, but it's an important factor to take into account.
That's all, folks. Thanks for reading, and if you think I’m missing something important, or if you have better ideas for names of Frontend types – let me know in the comments or contact me on socials.
Like, share and follow if you liked this article, and check out the other ones!
Also, subscribe to my newsletter and feel free to connect:
