Few platforms draw the same amount of ire as ASP.NET (or .NET in general) from the development community. While there are certainly valid criticisms of the platform (what platform doesn’t?), the majority of negativity comes from those who haven’t spent any time with .NET. Those developers typically rely on misconceptions or flat out hatred to base their opinion, and they do a disservice to others looking to learn a new technology and to the platform itself. So, let’s examine these excuses and add a dose of reality on why you shouldn't listen to the rabble and give ASP.NET a try.
It’s Made by Microsoft
This is probably the #1 reason for all ASP.NET hate.
Microsoft is a massive software corporation, and like all other corporations, they’re in business to make money. Duh, right? Unfortunately, this is probably the #1 reason for all the ASP.NET hate: it’s a Microsoft technology, and the “evil” taint still lingers over the giant in many people’s minds. I’ve always found this interesting because the other major technology companies, such as Google and Apple, are just as “evil” as Microsoft, but the zealots fans of those other companies typically turn a blind eye (or are in denial) to those “evils.” I personally think the majority of people are normal minded people. They don't really care who makes a product as long as that product works well.
But I'm not talking about normal people, right? Normal people don't see a headline containing "ASP.NET" and have an automatic urge to make an inane comment. Instead, I'm talking about the developers (and geeks) that treat technology, and/or the company that creates it, as a religion. I'm not kidding—find any article or tutorial on X platform, and chances are good you’ll find comments stating “X Sucks! Y Rules!”
It’s as if these people are on some weird crusade to defend their chosen tech/company to the hilt and bash the competition in an attempt to bring the unwashed masses into their fold.
It's sad that the technology = religion mindset exists. Technology is a just tool, and a real developer is going to try multiple tools in order to find the right one for the job. That’s not to say that someone cannot dislike a technology, but to echo our parents, "you don't know you don't like it until you try it." In order for someone to truly dislike something, that person has to try it. So don’t listen to the rabble—they haven’t tried it and haven’t formed an informed opinion. If you decide you want to try it, they’ll attempt to dissuade you by saying it costs too much.
Misconception: It's Expensive
Find any article comparing ASP.NET with any other platform, and you’ll read, either in the article or in the comments, “ASP.NET costs more than [insert any other server-side tech other than ColdFusion here].” Before discussing the actual cost of something, it’s important to put the term “expensive” in context, as what is expensive for personal use can be considered cheap in a business environment. In business, there are many factors that make up the “cost” of a product. The initial price obviously needs to be considered, but the benefit of the product is also factored into the overall cost.
If a product is $10,000, but it saves the company $1,000 a month, the purchase decision is a no brainer. But on a personal level, it would more than likely be difficult to justify the initial $10,000 cost.
So when talking about cost, it’s important to keep things in perspective according to the context in which it will be incurred. To keep things simple, I’m going to assume that if you’re reading this, you’re more concerned with the personal cost than the business cost (if I’m wrong with that assumption, I’ll make this very easy for you: if you have a Windows environment, ASP.NET is cheap).
You don’t actually need Windows to develop ASP.NET apps, thanks to the Mono project.
Let’s get the biggest cost out of the way: the Windows operating system. You don’t actually need Windows to develop ASP.NET apps, thanks to the Mono project (more on this later), but Mono typically lags behind the official .NET Framework coming out of Microsoft’s ovens. So, if you want all of the latest features and .NET-goodness, you’ll need Windows. Most OEMs (companies like Dell, HP, Acer, etc) ship their computers with Windows already installed; so, if you buy your computer from an electronics chain store like Best Buy, chances are pretty darn good that the computer will have Windows. If you’re more of a power user and build your own computers or plan on run Windows in a virtual machine, you will have to purchase a copy of Windows. An OEM version of Windows will run you anywhere from $99 to $189, depending on which version of Windows you buy. You don’t need to have Professional ($139 OEM) or Ultimate ($189 OEM), but if you’re a power user, you’ll more than likely want to opt for one of those two versions (OEM versions are cheaper than retail versions, but they are tied to the hardware you activate them on).
Development Costs
With that out of the way, let’s review development costs. ASP.NET development is thought to be expensive for two reasons.
-
It’s Microsoft. They supposedly don’t give anything away for free, but that’s exactly what they do. Everything you need to develop ASP.NET applications (or .NET apps in general) can be obtained without spending a dime.
Beginners: First, Microsoft gives away WebMatrix, a development environment targeted at beginners. It combines an integrated development environment (IDE) with a built-in web server (IIS Express) and a database engine (SQL Compact Edition). It also has tools to help users deploy their websites to a remote host.
Advanced Users: For more advanced developers, Microsoft makes available the Express editions of Visual Studio. Like WebMatrix, these trimmed down versions of Visual Studio are free, but they offer some of the features and abilities found in the full versions of Visual Studio. The web-focused Express product is Visual Web Developer Express (VWD), and it, too, has a built-in web server. It doesn’t have a built-in database engine, but Microsoft gives away SQL Server Express, a trimmed down version of SQL Server, that you can use for development (and even some deployment situations). If you later decide you like Visual Studio and want to purchase the full version, the projects you developed with VWD can be opened with Visual Studio.
Students: And if you're a student, you can get lots of Microsoft software (Visual Studio Pro, Windows Server OSs, and Expression Studio to name just a few) for free through the DreamSpark program.
-
Secondly, Windows-based hosting is thought to be mucho expensive-o. Ten years ago, that argument held some weight. Today however, you can find no shortage of reasonably priced hosting for ASP.NET. DailyRazor (the company I use) starts plans at $2/month, and you can find other hosting providers that sell their services at low prices.
So cost isn't really a problem, but naysayers will then say ASP.NET is only suitable for enterprise-class websites as opposed to your personal site(s).
Misconception: It's Horrible for Small, Personal Websites
One only has to look at the .NET Framework’s class library to get the “this is for enterprise” feeling.
It’s actually easy to get into the mindset that ASP.NET isn't suited for anything but large-scale sites. Microsoft is a platform company, after all, and their products are primarily focused towards business solutions. .NET isn’t really different in that respect; it's huge in business environments, and its foothold continues to grow as Microsoft expands new and revitalized products like Azure (Microsoft’s Cloud platform) and Windows Phone, respectively. One only has to look at the .NET Framework’s class library to get the “this is for enterprise” feeling. It’s almost as if the framework guides developers to a mindset that (ASP).NET applications needs to be highly structured masterpieces of object oriented design. A lot of .NET is complex, and doing simple things isn’t always as simple as it should be. It sounds like I'm making the naysayer’s case, doesn't it? I kind of am, but there two things to consider.
Simplicity
First, Microsoft wants you developing on their platform, and they’ve recognized that it needs some (perhaps a lot of) simplification in order to grow. After all, PHP is as popular as it is specifically because of its simplicity, and that’s the primary reason Microsoft released WebMatrix: to offer new developers (either to .NET development or web development in general) a simplified approach to writing sites with ASP.NET.
Not only is the all-in-one IDE easy to use, but Microsoft created a simplified API to make ASP.NET development easier and less complex.
Multiple Approaches
You can also build sites with the same kind of “scripting” mentality that thrives in PHP.
Second, you don’t have to fall into the “highly structured or die” mentality. There are many approaches to ASP.NET development. If you want to create highly structured masterpieces of object oriented design, you can. But you can also build sites with the same kind of “scripting” mentality that thrives in PHP. The point is, ASP.NET development is flexible enough to fit your needs, and you can choose the development approach that best fits you.
Oddly enough, there’s a somewhat prevalent idea that ASP.NET isn’t suitable for enterprise-class websites. o.0
Misconception: It's Horrible for Large, Enterprise-class Websites
I honestly have no idea where this comes from because, as mentioned earlier, ASP.NET excels in the enterprise space. But don’t just take my word for it; let’s examine a real-world website (well, a network of websites) that run on ASP.NET.
Have you ever heard of StackOverflow.com? You probably have, and if you haven’t, it’s a Q&A website for developers (regardless of technology). Its an invaluable resource, and one I find myself visiting quite often.
StackOverflow is a member of the Stack Exchange Network, a network of Q&A websites for a variety of topics: servers, databases, legos, sci-fi, cars, and so on, and so on. There are currently 71 sites in the network, and it continues to grow.
The folks at the Stack Exchange Network are pretty open about their network. Much of the code running on the site is open sourced, and they often provide information regarding the network in general. In a March 2011 blog post, Kyle Brandt provided an overview of the technology powering the Stack Exchange Network, as well as the traffic the network gets. Keep in mind this information is regarding the entire Stack Exchange Network. It gets 95 million page views a month and handles 800 HTTP requests a second, and those requests are handled by twelve (yes only twelve) Windows web servers, two MS SQL Server servers, two Linux load balancers, and two Linux caching servers (fail-over hardware is not included in that count).
Reread those stats—I'll wait. Phenomenal, right? It’s amazing that only twelve servers, serving many different websites, handle that amount of traffic. It’s a testament to just how good Microsoft's server and application architecture is.
It's Statically Typed
Dynamic languages rule the web. Be it on the server side, where languages like PHP, Ruby, Python, and Perl live, or in the browser with JavaScript, dynamic languages are the backbone of the web. It's not that these languages are better, but they are quickly adopted because dynamic languages are typically easier to learn and understand than statically typed languages.
So what we essentially end up with is a massive community of developers who have only used dynamic languages, and that community almost has an aversion to static languages.
I fully understand the mindset. I used to be one of those people, and I understand the desire to stay within one's comfort zone. After all, dynamic languages are lenient, and there is some comfort found in that leniency.
Static languages have a strict type system.
But there’s a bad side to that leniency; it is extremely easy to introduce bugs into your app if you’re not careful. You’ll typically not find that bug until runtime, and a common cause of bugs is the assignment of a different and unintended type of value to a critical variable. This is where the primary benefit of static languages comes in: type safety. Static languages have a strict type system, in that a variable can only contain one type of value (eg: a variable declared as an integer can only contain integer values; it cannot contain a string or floating point numbers). If you mistakenly assign a string to a number variable, you will immediately know of the error when you compile the code because the compiler with halt and alert you to the error.
Type safety can also alleviate the type checking you need to perform in dynamic languages. For example, how many times have you written code like the following to ensure the data a function accepts is of the expected type:
function add($a, $b) {
if (is_int($a) && is_int($b)) {
return $a + $b;
}
// throw error
}
This is a simple PHP function that adds two numbers together. In order to ensure predictable results, checking if the supplied values are of the appropriate type is imperative (admittedly, the type checking here isn’t complete; there are numeric types other than integer); otherwise, your app could break at unexpected times. In contrast, let’s look at the C# equivalent code:
int add(int a, int b) {
return a + b;
}
This code defines an add() method. C# is the most popular .NET language, and it is purely object oriented. There are no functions; only methods of a class. This method accepts two integer values (denoted by the int keyword before the a and b identifiers), and it returns an integer value as denoted by the int before add. Because C# is a static language, the type checking is performed by the compiler—not by you. So, if you were to call this method, pass a string as one of the arguments, like add("hello", 123), and attempt to compile the code, the compiler will stop the build process and alert you to the error. Chances are, however, you wouldn’t even try to compile the code because Visual Studio performs its own type and syntax checking; the IDE will warn you of errors before you even try to compile (see the below screenshot of Visual Studio 2010).
Also consider that Microsoft continually updates and improves the C# language. In the first two versions of the language, you had to identify a variable's type when declaring it like this:
XmlDocument document = new XmlDocument();
This code creates an instance of the XmlDocument class by declaring its type prior to the variable's name. Admittedly, this syntax is rather cumbersome and adds far more typing, but as of C# 3.0, however, you can simply use the var keyword to define a variable, like this:
var document = new XmlDocument();
There are .NET-enabled versions of PHP, Ruby, Python, and PERL.
The compiler is smart enough to infer that the document variable is an XmlDocument. This syntax sort of blurs the line between dynamic and static languages. You get simple, typeless variable declarations with the benefits of type safety... a win-win in my book.
But if I still can’t persuade you to give C# a try, ASP.NET sites do not have to be written in C# (or even VB.NET... but who would want to do that?). There are .NET-enabled versions of PHP, Ruby, Python, and PERL (and others) that you can use to write ASP.NET sites with, and they are just as dynamic as usual thanks to the Dynamic Language Runtime, a feature of .NET 4. So while I recommend anyone picking up ASP.NET to learn C#, you don’t have to leave your comfort zone if you don’t want to (but if you do the benefits are worth it).
It's Compiled
The same dynamic languages that rule the web are also interpreted, and there is a certain benefit that comes with interpreted languages. Unlike compiled environments like ASP.NET where you typically write your code, compile it, and upload it, interpreted environments let you simply write your code and upload it. The common idea being that compiled environments require an extra step in development, and that wastes time. But it really doesn't. The compiler gives us many benefits that you just cannot get in an interpreted-language environment.
First, the compiler checks the code and can give you warnings. Warnings are just that: a warning. It's something you've done that may be a bug, but it won't stop the compiler from compiling your code. Let's look at the following code that would cause a warning:
string DoSomething()
{
var foo = "Hello";
var bar = "World!";
return foo;
}
This code defines a method called DoSomething(). Its body creates two string objects, foo and bar, and foo is returned to the caller. The bar variable is not used, so the compiler would issue a warning stating that bar is assigned but its value is never used. It may be that I created bar and forgot about it, or that I ended up not needing it. But it could be the source of a bug if I forgot bar already existed and used it elsewhere in the method. The compiler brings it to my attention so that I may address it and avoid future bugs. Here's a screenshot of what Visual Studio tells me:
Do you want another example? Sure you do:
void DoSomethingElse()
{
var foo = true;
if (foo = false)
{
// this code will never execute
}
}
In this method definition, a boolean variable, foo, and defined as true. It is then used in an if statement, where it is assigned a value of false. That may be exactly what I intended (although I would argue that I should never do that), but chances are I meant foo == false (yes, the logical not ! operator would be better here... but it doesn't work for my example). It's not an error, however, so the compiler will compile the code. However, it will issue a warning asking if I meant == instead of =. These are issues that I would have found an in interpreted environment, but I would have needed to run the app and test it in order to find those mistakes.
Second, the compiler checks the code for errors. Naturally, a compiler cannot catch logic errors, but it can type check and check the code's syntax. Although, a decent IDE will do these things for you without needing a compiler, and Visual Studio does.
Last, you get a performance boost. Compiled code runs faster than interpreted. Admittedly, .NET isn't a truly compiled environment. Our code is compiled into an intermediate language (IL), which is then just-in-time compiled by the .NET runtime. The IL, however, is optimized, and the .NET runtime executes it. But it's still very fast.
Misconception: It’s Closed
Microsoft makes the source code for the .NET Framework available for free.
Microsoft is a company that sells software, and they are naturally very protective of their products’ source code. So, one might think that ASP.NET (and .NET in general) is closed source, but that is not the case. Microsoft makes the source code for the .NET Framework available for free, and you can step into the code while debugging your own apps. You can even build your own personal version of the .NET Framework.
Microsoft also gives you access to the source code of ASP.NET releases, like WebForms and MVC, via CodePlex; giving you the ability to test new features and provide feedback to the ASP.NET team. I encourage every developer using .NET to download these free resources and study them. You’ll gain a greater understanding of how it works under the hood, and you can apply that same knowledge when writing your own code.
It’s Windows Only
Microsoft’s openness with the .NET Framework is what helped birth the Mono project, a cross-platform version of the .NET Framework. While Mono isn’t officially supported by Microsoft, the project has been publicly acknowledged by Microsoft. Mono isn’t going away; in fact, it’s growing in popularity Regardless of what your favorite platform, you can probably use the .NET Framework and C# to write apps for it (you can even write iOS apps with Mono!).
It's Not in Demand
Lastly, it's often espoused that ASP.NET is not in demand, and that simply is not true. Demand is somewhat subjective because different areas of the world and in the country you live have different job markets. For all intents and purposes, .NET has been the development platform for Microsoft Windows environments (both for the desktop and the web) over the past ten years.
Most software developed for Windows uses the .NET Framework, and so there is a huge opportunity for new .NET developers to find work.
The Mono project also factors into demand. Mono is huge, and the community is just getting bigger. With its wide breadth of OS support, you can write apps for any of the big OSs, including mobile devices. There is opportunity galore, regardless of OS!
Conclusion
So where does all this leave us? Well, the haters and naysayers are wrong, and ASP.NET is a technology that you should try and get to know. After all, successful developers are polyglots—able to write applications in different languages for different platforms. So give ASP.NET a try. What do you say?
Comments