.NET, C#, and ASP.NET for Javascript developers: Part 1, The Ecosystem
I’m imagining a scenario ...
You have been using Javascript for the past X years to add interactivity to web sites and applications.
You might be using VanillaJs or a library like jQuery, D3, Moment or Lodash to help you add some spice to your web apps.
And maybe you’ve been using a library/framework like Backbone.js AngularJs, React, or VueJs to let you manage the browser like a platform, creating rich client applications that manage and maintain state between clicks, form submissions, navigations and XHR requests.
Now you’d like to take some of that knowledge you’ve gained and the design pattern skills you’ve learned to the backend. You’d like to connect to databases, payment providers or caching layers. You’d like control over things that the client side normally has to rely on SaaS products for. You want to build server side rendering or an Api.
Awesome! Since NodeJs lets you write Javascript server-side, this shouldn’t be a problem — in fact, the internet is always a-buzz with the greatness of NodeJs as a platform.
Unfortunately there is a problem. Your company’s backend developers write everything in C# running on .NET. They don’t know Javascript that well and they certainly can’t afford to take a gamble on supporting an entirely new platform like NodeJs.
But you’re smart! You know if you show you understand how to translate your skills as a Javascript developer for the browser to a C# developer on the server, you will get a better response from the powers-that-be.
Just like the Javascript world there are a lot of options to how you can build C# applications running on .NET, so let’s discuss what some of those options are and define some terms and lingo you might encounter.
You’d like to connect to databases, payment providers or caching layers. You’d like control over things that the client side normally has to rely on SaaS products for. You want to build server side rendering or an Api.
What is C#, really?
C# is a multi-paradigm programming language. It has functional, object oriented, imperative and declarative features. It’s flexible enough to handle most use cases really well — jack of all trades, master of none — but for day to day software development this is a good thing!
C# is primarily object oriented. So, it’s based around classes (everything has to exist in a class somewhere) as templates of behavior and creating instances of those classes to encapsulate state, similar to Javascript’s new class syntax. It’s also strongly typed. All variables and parameters have a type. For example a type could be a class, a primitive (string, integer, boolean), or an interface (defining only the Api of an object, not any implementation).
Unlike Javascript, this class and type information stays with the program at runtime and can be accessed by the running application through a process called Reflection. This feature of the language is extremely powerful and allows for some really amazing flexibility in software design.
Imagine, with minified Javascript code, printing out at runtime the original property name of an object passed to you, determine if its a function, what kinds of parameters it expects, and any metadata (attributes) applied to those properties and parameters. All that meta information is baked into the application available for the developer to utilize.
Developed by Microsoft, it has changed a bit since it first appeared publicly in 2002, adding new language features at a consistent pace and adapting to popular software development and language design patterns.
Javascript developers of the past few years will be very familiar with changes in versions of the language with recent yearly releases of ECMAScript (2015–2018) and configuring tools like Babel or Typescript to transpile newer language features to be supported in older browsers.
Traditionally the version of C# developers used was directly tied to the version of Microsoft’s popular (and for a long time, required) IDE Visual Studio. A new version of the language came out with a new version of the IDE. If you opened up an old application in a new version of Visual Studio, you can start updating your code to use the new language features.
Things are different now that the open-source C# compiler, Roslyn, exists independent of the Visual Studio. This is very much like the current world of tooling for Javascript — language services, code analysis, transpilation tools, polyfills that live with each project. Roslyn can be added to a C# project as a package and so the version of C# a developer can use is, in general, not so dependent on the version of Visual Studio they have installed. But, in practice, developers typically update their version of Visual Studio to get the latest and greatest language features and tooling.
C# is a multi-paradigm programming language. It has functional, object oriented, imperative and declarative features.
What is .NET, really?
.NET (or .NET Framework) is the core language framework. It’s a set of libraries that Microsoft has created for developers to help them get their work done and to make their lives easier.
There isn’t a great corollary for .NET in the Javascript world, and that’s because of Javascript’s origins in the browser as a way to interact with the DOM. NodeJs has filled in some of the gaps, giving access to things like the filesystem, network stack and a process model but to really wrap your head around .NET we need to compare it to things a Javascript developer might be familar with.
Imagine a highly curated subset of Npm. These packages are built into your operating system, designed to all interoperate (no random internal breaking changes) and be updated in large incremental updates. They are maintained by one organization, and this set of packages is designed to provide strong support to developing both rich client applications and server side tools and services. Picture a world where Express, Pug, Angular and fs/fs-extra (among a ton of other things) are all controlled and built by one company.
With this comparison to Npm and the Javascript community, a question quickly arises. Is there anything .NET outside of Microsoft?
Yes! Before the days of Stackoverflow, Github, and social software development .NET code and libraries were distributed as source code and .dll files (think .min.js) downloadable off websites. Now .NET developers use NuGet, which was introduced in 2010, for all package management needs.
NuGet, at the time of this writing, hosts about 125,000 different libraries and pales to Npm’s 700,000. This is mostly due to .NET as a framework providing so much to developers out of the box that there wasn’t a need for the community to create as much.
There is a command line application just like Npm, called the NuGet CLI, that can be used to download and install packages, but like most things in the traditional .NET world the UI in Visual Studio tends to be the mechanism developers use to add packages to their applications.
.NET as a framework is a bunch of libraries built to run primarily on Windows operating systems. That library code (and the developer’s application code) runs on the CLR (or Common Language Runtime). This runtime/virtual machine is pre-installed along with the .NET Framework on all Windows PCs.
Notice that I haven’t mentioned C# once in this section. That’s because none of this is specific to C# the language. The .NET Framework and the CLR support many languages — some supported and developed primarily by Microsoft (C#, VB.NET, Powershell), some supported and developed primarily by the open source community (PeachPie/PHP), and others are collaborations (F#).
These various languages all compiling down to something that runs on the CLR is kinda (lots of handwaving here!) like ClosureScript, CoffeeScript and Typescript, all being compiled down to run on the Javascript runtime in the browser/NodeJs (actually it’s a lot more like languages compiling to WebAssembly).
Everything I’ve mentioned so far has left out some major developments over the past 4 years in the .NET ecosystem — specifically .NET Core …
.NET (or .NET Framework) is the core language framework. It’s a set of libraries that Microsoft has created for developers to help them get their work done and to make their lives easier.
What is .NET Core, really?
.NET as a framework and a runtime has been around for awhile. It was designed to run on Windows PCs as a monolith of libraries and infrastructure. There is a bit of an impedance mismatch between those principles and the goals of Microsoft’s cloud hosting Azure. To reach the widest audiences, Azure needs to support “Any Developer Any App Any Platform” (their words, not mine). A programming paradigm that has been designed in large part for desktop PCs does not help Microsoft fulfill that vision. This is, partially, where the impetus for .NET Core came from.
There was always Mono, an open-source implementation of the .NET Framework and the CLR that ran cross-platform (primarily Linux) but it was not a Microsoft supported or even sanctioned project. Mono also never had access to the resources that implemented .NET on the Windows side and so it always lagged behind or had limitations.
.NET Core is Microsoft’s reboot of .NET, focusing on being cross-platform (Windows, Linux, OSX and even Raspberry PI!), modular (bring in only what you need to use), open-source and design (want to see the source code? Core CLR and Core framework), open for contributions (you can open a PR if you want!) and optimized for a present and future where applications are deployed to the cloud.
The move from the traditional (now called Full) .NET Framework to .NET Core isn’t as difficult as the move in front-end development from building jQuery apps via a <script> tag in the page to SPAs, Webpack, Typescript and CSSModules — but it is a migration that a lot of teams and developers are in the process of understanding and solving.
Keeping that in mind, greenfield apps are likely going to built with .NET Core and that’s the place you should start. If you are searching for answers, code and documentation, check the dates on the content and know that anything written pre-2015 is for the Full .NET Framework. Assume anything written post-2017 is for .NET Core.
Currently the latest version of the Full .NET Framework is 4.7.2 and the latest version of .NET Core is 2.1.3.
Note: While I’ve only mentioned Visual Studio as the development platform/editor/tools for building .NET applications, for .NET Core apps you can also use VS Code on Windows, Linux and OSX and Visual Studio for Mac on OSX.
You can also use a standard text editor and Microsoft’s build tool, MSBuild, from the command line but I wouldn’t recommend it for a developer new to .NET.
.NET Core is Microsoft’s reboot of .NET, focusing on being cross-platform, modular, open-source and design, open for contributions and optimized for a present and future where applications are deployed to the cloud.
What is ASP.NET, really?
ASP.NET is the set of web development tools, libraries and features within the .NET framework.
ASP.NET got its name from another Microsoft web technology called ASP (Active Server Pages), which existed before .NET and is very similar to PHP. It allowed for code (written in primarily VBScript) and HTML to be intermixed, executed on the server, and the resulting HTML/Javascript response being sent back to the client.
These days ASP.NET is really anything related to creating internet based services (HTML/JSON/XML/Web Socket) with the .NET Framework. The ASP related technologies are gone in ASP.NET and all that remains is the branding — just think of the ASP in ASP.NET as a family of web technologies rather than an acronym.
ASP.NET, like the rest of .NET, now exists in two variations — Full Framework ASP.NET and ASP.NET Core.
My previous comments about finding content and starting greenfield projects apply here as well.
ASP.NET has, for the past 10 years, often been associated with ASP.NET MVC, a Model-View-Controller architecture (similar to Express.js) for rendering HTML on the server as web pages. ASP.NET MVC was heavily influenced by Ruby on Rails and is still the primary way for building web applications in the .NET world.
Prior to MVC the focus was on a different paradigm that attempted to bridge the gap between desktop .NET Forms UI development and the web — this is called ASP.NET Web Forms. It’s still a supported technology but no greenfield development is being done here and more importantly it’s not part of .NET Core, while MVC most definitely is.
ASP.NET MVC brings together architectural patterns like routing, request/response pipelines and HTML view rendering to help .NET developers build robust web applications. MVC has its own special templating language called Razor which lets developers interleave C# with HTML to do many of the things you’ve come to love about SPA frameworks like React, Vue and Angular.
Razor supports creating repeated content from a loop, conditional rendering and content encapsulation (kinda like server side components). It’s a great developer experience and still the main rendering technology in ASP.NET Core.
There was a time when if you wanted to build a web service (aka an API), you needed to either use WCF (Windows Communication Foundation) and build a SOAP/XML API (overly complex, not fun!), or force MVC into rendering JSON instead of HTML for Javascript clients (technical gymnastics, not fun!).
Microsoft saw the writing on the wall and developed ASP.NET Web API, a new way of thinking about HTTP based web services. ASP.NET Web API looks a lot like Full Framework ASP.NET MVC but it actually laid the groundwork for .NET Core, separating pieces of the application from being tightly coupled with the .NET and Windows components that ASP.NET had been reliant on in the past.
Now ASP.NET Core includes both the MVC server-side HTML generating technology and Web API HTTP based web services technologies. If you start a new ASP.NET Core app you can do both in the same application very flexibly.
ASP.NET is the set of web development tools, libraries and features within the .NET framework.
Wait, that’s it?!
I bet you feel like I’ve covered a lot — maybe even everything there is to say about C#, .NET and ASP.NET… but that’s definitely not the case.
If you want to know the more detailed (and very very interesting) history of .NET at Microsoft you can listen to this episode of .NET Rocks, a podcast covering .NET (and programming in general) going back 1500 episodes and about a decade and a half.
If you want to learn more about
- How C# compares to Javascript as a programming language in terms of features and design principles
- How .NET and the CLR compare to the Javascript runtime and the Npm ecosystem
- How a sample web application with C#/.NET looks and works
… then stay tuned for the followups to this Part 1.
If you have any questions or requests for clarification, leave them in the comments and I’ll either respond or try to address them in one of the later parts of this series.
