Web Design Questions: Linux or Windows? Client or Server?

An Overview of Web Technologies

If we are going to develop applications for the web, we’ll need two fundamental things: a web server and a browser. Fortunately, the browser is ubiquitous and so we don’t need to make decisions there. However, we do need to decide which web server to use; and if we are creating web services (and we almost always will be doing so); we’ll need an application server.
Click here to Toggle Sidebar: Keep It Simple

With the objective in mind to “keep things simple”, let’s look at the Linux vs Windows discussion.

Which is better for Web Development: Windows or Linux?

So let’s answer this question right now….it depends.  Frankly, in the final analysis, both platforms will do everything that we, as developers, need them to do. But here are some things to consider:

  • Where will the solutions be deployed?  Linux and the associated LAMP technology stack are open-source and so there are no/little license fees associated with them. When we compare the costs of Web servers on Amazon’s Web Servers (“AWS”), we find that the current pricing  to host the server on Linux on their “m4.large” distro is ten cents per hour.  Windows is almost four times as much at .384 per hour.  So outside our corporate network; it appears it makes more sense to use Linux and the LAMP stack.
  • However, if our solution is to run inside the firewall on our corporate network that is comprised primarily of Windows servers, then we really have little choice but to use Microsoft’s Internet Information Server (“IIS”) and pay the freight of Microsoft’s licensing.
  • Another consideration is the skillset of your or the team.  If you are a .NET developer who is familiar with Microsoft SQL Server, and Microsoft Windows as a platform; then, it would make more sense for you to do your development where you have the knowledge and experience; unless you want to learn a different technology stack and platform.  However, in today’s development world, the technologies are so similar, that it’s relatively easy to move from one platform to another; and so this should be a minor consideration in the final analysis.

Where Should we Do Our Programmatic “Heavy Lifting” — on the Client (browser) or Server (back end/web-server)?

In the early days of the web, before we had javascript running inside the browser, we had only one choice:  do all of our programmatic work on the server side and just emit html to each client.

Since I was employed at Microsoft at this time, I’ll focus on Microsoft’s history in this area.

The first Windows web server side development platform was C/C++ applications running as “extensions” or “filters” on the server, called ISAPI applications.  It was non-trivial to build and test a filter or extension and in the early days, this required a rather extensive knowledge of web and network technologies and programming.

Later, Microsoft released “Active Server Pages” or ASP applications that could be written in Visual Basic (“VB”) or JScript (Microsoft’s own take at JavaScript).  Using a language such as Visual Basic opened up web programming to the larger universe of experienced VB programmers. However, as with ISAPI programming in C/C++, the work was done exclusively on the server which simply returned html to the browser.

The next iteration of functionality was the ability to run programs inside the browser.  Java applets and ActiveX controls (basically, embedded Microsoft “COM” objects which required the browser to be hosted in Windows) were able to be executed inside the browser. This migrated  some of the work to the client side of the pipe; that is, inside the client browser. However, for both Java and ActiveX, security issues quickly destroyed any functional benefits and these are almost never seen today in new apps; and are quickly disappearing in older web apps.

When Microsoft released .NET, they upgraded Active Server Pages to “ASP.NET”; but effectively it was the same platform.  In the early days, ASP.NET emulated ASP pages by doing almost all of the work on the server and just sending back HTML to the client browser. However, with the introduction of more powerful browser based JavaScript engines in the browsers, and competitive realities, Microsoft released a “cludge” of AJAX and ASP.NET.  In my experience, it was/is a disaster and should be avoided if at all possible.  In fact, I find ASP.NET to be problematic since, from my experience, the look-and-feel and functionality can change from release to release and from browser to browser.  Therefore, it’s a pain to support.  At one time it was argued that as long as the application would run inside the corporate firewall on Windows machines and on Windows browsers (IE, Edge, whatever), that it was OK to use ASP.NET.  However, given Microsoft’s ever shifting browser support even on their own Windows platform, this is a non-starter.

Given the limitations and problems of ASP.NET,  I purposed some years ago to never use ASP.NET or ASP for any web based development project I had a say in.

So what’s the alternative you might ask?
Simple AJAX technologies using browser based rendering and server based data distribution.

Conclusion

So these are my personal biases, based on almost three decades of web development work and deploying a number of commercial web applications:

  • If you must use Windows (for example, a corporate environment that doesn’t support or allow Linux) then use Windows.  If not, use Linux and LAMP.
  • Use JavaScript and one or more of the available JavaScript libraries (such as JQuery) to do your server communication and rendering – on the client; that is, in the client browser.
  • Keep things as simple as possible on the server.  In the next few lessons; we’ll look as some hypothetical use-cases and walk through development of web solutions on both Windows and Linux.  In each case, the server side programming is computationally expensive; but scalable due to the simplicity of the server solutions.

Leave a Reply

Your email address will not be published. Required fields are marked *