Basically any application you are not hosting on your own server can be considered serverless. It should not need one of your servers as backend, of course.
Due to this, even desktop apps can be considered serverless, but, nowadays, the mainstream approach has shifted to have an application using a backend API in the Cloud. Desktop apps also have installation and security issues and have been replaced by apps loaded from a store that takes care (or at least should) that no malware can be installed on your mobile or desktop client.
This approach works well for commercial apps, but for custom business solutions the store overhead for registration with a store provider, additional costs of testing, is avoided by delivering HTML/JavaScript based single page applications (SPAs) to employees. Especially, if we are talking about internal business solutions.

These apps can either be loaded from a storage location in the Cloud, for example an Azure Blob, which even can be distributed world-wide via a content delivery network (CDN) for high-speed loading, or a web application hosted on as an Azure App service.
A favor for using an Azure App Service is the additional infrastructure regarding, development and deployment, easy scaling, security as well as monitoring, one gets from the Azure App platform service.

To develop SPAs profound knowledge of HTML and JavaScript and frameworks such as Angular, jQuery, React, to name just the prominent ones, is required, if you want to achieve good to great results.

This development process is also not as fast as it was, for example in the past creating business Visual Basic applications, which had other issues, of course.

In this light it may be interesting that there is a new Microsoft NET Core technology on the horizon called Blazor, which enables developers to code web applications in a combination of HTML and C# with a full roundtrip development experience in Visual Studio.
Blazer comes in two flavors or hosting models:

• Hosted in an ASP.NET app service, running as server-sider code sending rendered HTML pages down to browser client. SignalR is used for interaction with backend.(available right now with ASP.NET Core 3.0)
• Client app hosted in browser leveraging the new web assembly standard to be compatible wit all common browser engines. The local app can use web API calls or SignalR to communicate with the backend. (in the future available with .NET 5.0 – which includes ASP.NET Core – now in public preview)

Quite a bit of this new approach still is in the making, but what looks compelling to me is the re-use of C# skills in the UI layer in combination with the excellent tool support through Visual Studio. It also promises some reduction of complexity and dynamics looking at the fast changing releases of the JavaScript frameworks, which, quite often, makes it a challenge to do future-proof decisions for larger teams in longer lasting projects. Blazor, therefore also has the potential to improve development speed significantly!

There is a componentized approach coming with Blazor, as well, which was introduced long time ago in various Microsoft technologies ranging from VB to Office and also has been implemented by JavaScript frameworks such as React.
Razor components ( which is the preceding ASP.Net server-side framework) can be re-used in Blazor and, due to this, a real good 3rd party offering, for grids, chart and gauge displays, calendars, data and time pickers, and whatever one needs for an application, is already available.

We will see how it evolves, but the first impression with Blazor is quite promising.

Alexander