C# to HTML (or Windows vs the Web) Part 1

If you’re used to developing for Windows (or MacOS or Linux or really any desktop OS) and you are contemplating a Web version of your application, there are a variety of things to consider. Moving from C# to HTML is more than just learning some different syntax and related frameworks. It's a whole new world.

It may be obvious, but let me state it anyway: the Web is not Windows.

This is the first in a series where we’ll review some fundamental differences and discuss how we address those with WebMAP’s application architecture. That architectural pattern may take a little getting used to, but in the long run I think you’ll find it makes your life simpler when you go to maintain or improve your Web application. Many thanks to our own Chief Rocket Scientist Mauricio Rojas for pulling a lot of this together.

Note: some of this discussion may be a bit basic for some readers, but in order not to leave people behind I’ve chosen to cover some fundamentals before moving into advanced topics. (That’s why there’s a Page Down key on the keyboard.)

Objects

In .NET we’re very familiar with something like this:

public class Autos
    {
       public string Name { get; set; }
       
    }
static void Main(string[] args)
        {
            Autos jetta = new Autos();
            Autos camry = new Autos();
            jetta.Name = "Jetta";
        }

In Windows your application is a process in the operating system and, when you create an instance with the new operator the OS allocates some memory for that object based on its type. In the sample above, when the line

Autos jetta = new Autos();

Is executed by the application, Windows allocates some memory to instantiate the object, then when the line

jetta.Name = "Jetta";

is executed it actually writes the string “Jetta” to the memory location it created with the new operator.

Methods like get() or set() read or write that memory location. That’s all possible because Windows knows who owns the memory (the process) and as long as the process is alive the memory will be too, until the object is destroyed and the garbage collector frees the allocated memory. That might be when the object goes out of scope or when you terminate the process (ie close the application).

Back in the stone age when we wrote programs in C or C++ we had to do stuff like malloc() and keep track of object memory ourselves but .NET manages all that infrastructure & bookkeeping for us, leaving us free to focus on what the program is actually doing.

Basically none of this is true for a Web application.

Note we’re talking about a Web application, not a Web site. (In a Web site, the Web server receives a bunch of requests for Web pages (discrete chunks of HTML code) via HTTP GET messages, which it returns to the requestor via HTTP. Pretty simple.) In a Web application, on the other hand, you need to replace the familiar Windows UI (Windows forms or WPF) with controls written in JavaScript, HTML, CSS, and which run inside a browser. Instead of a rich runtime (the .NET classes) to handle communication between the UI and the code, you have to rely on sending data over an open network to a distant server. Recall that neither the Web nor HTTP was intended for what we use it for today; in consequence this stuff can get complicated. So moving from C# to HTML can be tricky.

State

In a windows desktop application the concept of state is so transparent to you as a developer that you hardly need to think about it. Your application knows it only has one instance and one user to deal with; state becomes basically the in-memory footprint of all the objects in scope at any given moment. If you set the value of a string to “foo” you can be comfortable that it will stay that way, available for retrieval through a “get” method or modification through a “set” method.

The lifecycle for an object in Windows is short and sweet:

1. Object instance is created and initialized
2. Object is used
3. Object is destroyed in memory
4. Clean up or finalization code is executed.

A Web application is quite a different kettle of fish. Chief among the different fish species is the fact that each Web application user doesn’t own their own process space on the server, rather their code is just a separate execution thread. This rather handily lets you use one server for multiple user sessions, instead of having a single server dedicated to every user session. The downside is you can’t own memory--you have to share it like kids with a playground slide.

The lifecycle of an object on a Web server looks more like this:

1. Receive a request
2. Instantiate and initialize the object
3. Object is used and response is sent to requestor
4. Object is “suspended” while other threads execute
5. Object is cached or stored externally
6. Memory is freed
7. Requestor makes new request
8. Object must be recalled from cache or external store, but not reinitialized
9. Object is used, response sent to requestor
10. Object is suspended and memory is freed
11. And so on…

Another key difference to keep in mind is that Web servers basically sit and listen for requests. When they get one, the first thing they need to ask is “Do I know you?” If five different app users all press “submit” with a request to fetch data from the SQL database and return it to a control on a form (like a list box), the server has to keep straight:

• whether all those user sessions are ALLOWED to access data from the database (ie authentication)
• which data they have asked for (ie the business logic)
• how to serialize it and return it so it will be usable by the requesting client (the model or viewmodel)
• what the state of the client session is so the server can know how it has changed.

The server, in turn, has to also be performant, so it needs structure and tools to minimize the delays in processing requests as well as make load balancing and scaling efficient. Given that a typical Web application is accessed over a public network, inherent latency in the network transport layer already puts a performance burden on this application model compared to a desktop app running on a fast PC. Slowing it down further by poor server implementation could make the user experience untenable.

Running down the list

Some key differences between Windows and Web applications:

• State persistence: as discussed above, state on a Windows machine is usually something you just take for granted if you think about it at all. But given the frequently non-continuous nature of a session between a client and a Web application server, state is something that has to be maintained through some sort of serialize-and-store process. Why? Because each user session can’t always send all its state with every request to the server. That would tank the performance and load the server tremendously. So the server has to have some way to recall everything it knows about the client whenever the client makes a request. Then the server can just send the client the change in state from before to after the request is processed.
• State transfer: Again, since this is an n-tier system, there has to be a way for the server to update the state and send it back to the client tier, which in turn has to understand the delta or state changes and render them in a view.
• UI/View management: Windows has a rich set of classes and tools for creating a user interface (Windows Forms and Windows Presentation Foundation). MessageBox.Show() doesn’t exist in HTML, so you have to use some combination of JavaScript, HTML, and CSS to build and manage the application view for the user. Fortunately there are some excellent JS frameworks like AngularJS, KendoUI, and Knockout that make this a lot easier.
• Event delegates: In .NET you can attach delegates to events so they can act on them. While simple in Windows, it’s very difficult to replicate this functionality on a Web application because of the need to suspend the state and somehow save the delegates.
• Modality: In Windows you can force a synchronous event, such as a modal dialog box, which suspends execution until the user completes a task or takes an action. On a Web server you can’t force the execution of a thread to stop and wait for an event.
• File system: The file system in Windows is private to the logged-in user; it’s trivial therefore to read and write to the local drive(s). In a Web application the  server file system is shared and more complicated to use; it is possible to access the client file system ("c:\") through some browser extensions but generally this breaks the sandbox concept of a Web browser.
• Local configuration: Windows apps frequently store user-specific configuration information in an .ini file or the Windows registry. These don’t exist in a Web application. The alternative is to build a database the server can access and store information about authorized users there.
• Using other applications: Some Windows apps take advantage of the existence of other applications, such as Microsoft Word or Microsoft Excel. Both of those applications can be addressed through interfaces exposed as a part of Windows. However in a Web browser connecting to the services that are available on local installed applications is not possible. Running those applications on the Web server may violate the license on the app; for example Microsoft Office is not licensed to run on a server.
• Devices: Windows makes it easy to interrogate for the presence of physical devices (printers, scanners, cameras, etc.) and access them through Windows services. Usually a Web application has no such capability, nor can you depend on the existence of devices when your app might run on a browser on any compliant device (laptop, desktop PC, Mac, smartphone, tablet).

You can use our analyzer to tell you how ready your C# app is to migrate to HTML.  In the next installment, we'll discuss how to create a loosely-coupled architecture for a Web application.