Building desktop applications with C# and WPF is still a rich and active area of development, but if you're looking to the future of either a current project or a new endeavor, you need to evaluate what web development tools, languages, and frameworks are the right investment. Migrating from a desktop development environment to a web development toolset is a decision that requires, among other things, planning, retooling and rethinking, and potentially adding or training staff.
There are many advantages to adopting a web development environment. First, the user doesn't have to download anything. This is one of the most appealing features of a web application. If designed correctly, websites can be built to be mobile compatible — compatible for just about any operating system or device. This eliminates the need to write a separate platform-specific applications.
Compatibility across desktop, mobile and different operating systems can greatly reduce the development cost of an application. As I'll explain in more depth later, current web development tools and frameworks offer real opportunities for code-once, run everywhere scenarios.
With web apps, you get centralized updates. Rather than having to distribute updates individually to all users of a desktop application, or include some kind of auto-updating process, a web app typically offers a centralized point of update — the web server itself — for both the front-end user interface (UI) and the back-end business logic. That means easier incremental updates, too. Updating a desktop application, even for a small bug fix, often requires updating the entire application or, at best, providing a patch.
Adopting web development practices sometimes results in a cleaner architecture, as the UI elements (view, view controller, and view model) are typically implemented on the client- side while the business model, data persistence and other logic are implemented on the back end. This enforces a certain architectural discipline.
Perhaps most importantly, modern web apps offer an enormous array of capabilities. These aren't static web pages anymore. HTML5 — or perhaps more accurately, W3C standards implemented by most modern browser releases — offers some fairly sophisticated capabilities right out of the box including rendering a wide range of video, audio and image media, geolocation, Scalable Vector Graphics (SVG), offline events and data persistence, websockets and more. The ability to plug in functionality via HTML elements, components, or even scripts that call out to external APIs and services makes almost any capability available to your web app.
Keep in mind that it's not all a trip down easy street. I'd be doing you a disservice if I didn't discuss a few points on the potential challenges of moving to a web app paradigm for development.
The problem you're likely to run into first is that there are many different web frameworks and architectures to choose from. New flavor-of-the-moment frameworks are constantly being introduced. Many are open-source, and many also see regular updates, bug fixes, and new versions. It's important to make sure your framework of choice is actively supported. It's also important to know whether version upgrades have introduced breaking changes and how the vendor or development community has communicated and supported those changes.
Interfacing with the hardware layer offers some complications, but is not impossible. For user security, browsers make access to some local hardware resources dependent on user settings, and other resources are off limits entirely. There are, however, development frameworks that let you write native applications that have full access to local hardware, storage, GPUs and so on.
Connectivity is probably a significant concern. If the server goes down, or the Internet itself, your web app doesn't work, right? We've all experienced this! Bandwidth can be an issue. It takes planning and monitoring to ensure that web page and data rendering is fast. Data compression, streaming, and local caching/storage are some tools to reduce the amount of data that must be sent down to the client. And then there are Denial of Service (DOS) attacks (and other hacking attempts) that can cripple a website and compromise its security and, therefore, the privacy of your user's data.
For teams considering moving from development with C# and WPF to a more web-centric environment, you don't have to throw out years of experience and code. Instead, using some relatively new but battle-proven web frameworks, you can bring your existing .NET Framework skillset into the web app world.
Blazor takes this one step further -- as a feature of ASP.NET, you can write web apps in C# and Visual Basic, sharing code and libraries (with limitations) between the client and server. Under the hood, Blazor leverages WebAssembly, a binary instruction format virtual machine, to create a client-side .NET / C# environment. C# or Visual Basic code is compiled into normal .NET assemblies, downloaded and executed in a web browser using the WebAssembly-based .NET runtime.
There are performance considerations — while the .NET runtime is compiled into WebAssembly, your application assemblies are not — they are interpreted, not compiled, at runtime on the client side. This can easily result in performance issues. A pre-compile step into WebAssembly may be developed in the future.
One of the interesting things about Blazor is the ability to configure it to use SignalR, a real-time messaging framework, to communicate between the client and server. Client-side UI events are actually sent back to the server, processed, and data changes are sent back to the client and merged into the DOM to update the UI.
Xamarin is another toolset that developers often associate with cross-platform mobile development, but actually supports a much larger world of potential application platforms. Originally Xamarin was created for writing native Android, iOS, and Windows apps with C# and the .NET Framework. As the toolset has matured, however, it's become possible to write Xamarin-based apps for Mac and even the web.
If you're starting a greenfield development project or porting a desktop application where little code reuse is possible, it may be a good time to consider embracing the web development stack.
Another advantage of a webview is that the application can easily run offline (assuming you don't have other constraints such as cloud-based databases). As an application, the webview can provide all the scripts necessary to run the application. This also significantly reduces load times. A webview application can synchronize the scripts with a server as necessary.
If you're thinking of moving from traditional desktop app development with C# and WPF to a web development paradigm, there are many options, frameworks and tools to choose from ... and it seems like more arrive every day. Evaluating these options is a difficult process.
Starting from "where you are" with a desktop application is probably the best way to figure out "where you want to go." Particularly when considering migrating a desktop application to a web app, it's better to focus on your existing desktop application requirements first and then decide what web technologies best meet those requirements.
If you have any questions, please leave it in the thread below!