Moving from ASP.NET MVC to TypeScript

Introduction

This will help the ASP.NET / MVC developer gradually migrate their application to TypeScript, and / or decide on whether they want to move it all the way to TypeScript, or use a Hybrid Approach with Angular.JS.

By Chris Johnson @ intrin.sc

Moving from ASP.NET MVC to TypeScript

This article is about finally breaking dependence on a Version of Microsoft ASP.NET MVC, and moving towards an open sourced based MVC framework such as Angular JS.  I have to admit that I was asking a lot of questions about why we need to break away from using ASP.NET as a crutch but after researching this realized that performance would be further improved by using this technique.  At the same time, I was also further confused, as I just finished cresting a single page application using ASP.NET MVC as well as Angular JS.  I asked why we need to do this to several colleagues as well as to Google but couldn't really find a good answer.  I also was new to the single page app concept, even though I had created a semi - single page app using Web forms and Jquery previously. So, I simply delved into several examples on creating Angular JS / ASP.NET MVC apps and got to work.

The first thing I noticed, when comparing MVC only to an Angular.JS application using MVC, was that there was a duplication of routing on the MVC side as well as the Angular side.  I seemed to have created the same route twice and the rules (such as case sensitivity, etc.) were different for both client and server side.  I still wasn't grasping the concept of what the purpose of using Angular as well as ASP.NET was.  I didn't realize I was creating a single page app., and neither did any of the other developers on the team.  After I finished phase one of the application, I had some time to think about what I did.  I still didn’t quite grasp the concept, so I used my handy Web debugger to try to see what the difference in using just ASP.NET MVC vs using ASP.NET and Angular was.  Take a look at this MVC code and also the page transition and load data: 

Figure 1:  Standard ASP.NET MVC routing configuration

Figure 2:  Initial ASP.NET MVC controller for the Index and About pages

Figure 3:  ASP.NET MVC Index view

Figure 4:  ASP.NET MVC About view

 Figure 5:  ASP.NET MVC resulting index web page

 Figure 6:  ASP.NET MVC data load upon home page request

Figure 6 shows the data actually transferred from the Web Server to the browser when the user loads the initial view (index.html) on the browser.  As you can see, some of the data is rendered by the server, and is somewhat a mystery to the developer. 

I then simply clicked on the About link at the top of the page.  Here is the resultant web page along with the actual data loaded into the browser:

Figure 7:  ASP.NET MVC about web page

Figure 8:  ASP.NET MVC data load upon about page request

You’ll notice that each page request loads the same data except of course for the requested view (the about view in this case.).  Also note, that the page IS refreshed, so that means that all the data is transferred from the browser to the Web Server and Back.  Every page request results in almost 500KB of data as you can see from Figure 6 and 8 above.  This means that the data used to create the views is rendered on the server and sent to the browser.  This results in slower load times and a lot more data transferred back and forth between the browser and the Server than necessary.

Here is a similar size application, but using Angular JS U.I. Routing (see https://github.com/angular-ui/ui-router), as well as ASP.NET MVC:

Figure 9:  Angular UI Routing / MVC route.config file

Figure 10:  Angular UI Routing / Home Page controller (LandingPageController.js) file

Figure 10 is an angular.js controller file written in JavaScript.  It is somewhat small, but demonstrates the similarities between MVC’s viewdata and viewbag objects, in that they are used to transfer data to the views.

Figure 11:  Angular UI Routing Route setup file (AwesomeAngularMVCApp.js)

Figure 11 is the main application setup file.  This is written in JavaScript using angular.js and sets up the controllers and data services as well as the routing for the entire application.

Figure 12:  Angular UI Routing / MVC index.cshtml file

Figure 12 is the index.html file which essentially acts like a master page, or similar to the _layout.cshtml file in MVC.

Figure 13:  Angular UI Routing / MVC index web page

Figure 14:  Initial MVC / Angular Index page load

As you can see from Figure 14 above, there is a lot less data loaded, albeit they are different applications.  Even if there was the same amount of data that was loaded on the MVC initial index page as the Angular application, you are going to see a drastic difference between the two architectures on each subsequent page load:

Figure 15:  Angular UI Routing / MVC “State One!” web page

Figure 15 shows the browser after the ‘stateOne’ UI route was loaded into the browser.  Behind the scenes, the ‘StateOne’ view (which consists of several nested views, or UI routes as is called in UI routing) was loaded into the Index.html view creating the page as above.

Figure 16:  Angular UI Routing / MVC “State One!” data

You can see that on the 2nd page load and greater there is far less data being loaded into the browser.  Just to be clear, it was only the data BELOW the light grey line, so the ‘GET one’ statement and below.  And, of course, the browser was not refreshed.  Only about 435 Bytes were loaded!  That essentially makes it a Single Page App.  Only the current view's JavaScript and CSS is loaded and not the entire application's JS and CSS like the MVC only app. There is also no views that are rendered on the server, then sent directly to the browser, which also drastically reduces the amount of data sent back and forth.  Of course this will usually only work for small to medium size applications that act more like a desktop application with no page refresh.  An example application would be an email Web client.  However, it's possible to have several single page apps work together if you wanted to stay on the single page app architecture for a larger application.  Of course with every advantage, comes a drawback; you have to of course learn Angular.JS and you need to setup your client side routing and ensure it matches your MVC routing, so it makes for quite a bit more development work.  But, you can also see the drastic reduction in web traffic, so for those of you who know MVC and are concerned about performance, this is a great way to go.

My next project was creating an Angular application using TypeScript.  I was told that we wanted to NOT use ASP.NET MVC but simply Angular JS as the routing framework.  So, we had to break away from using ASP.NET as a crutch, so all Web UI code had to be JavaScript only.  This means no generated views from MVC, no convenient features like bundling, etc.  I researched this extensively as well.  Unfortunately there was no one around to ask about this particular combination of technologies, so I was essentially on my own.  The first thing to learn was TypeScript, as well as setting up routing without depending on ASP.NET and its ease of use.  Let’s also not forget the development environment most suited to TypeScript:  I used Visual Studio Code in the example application below.  This application has almost none of the ease of use of Visual Studio, but is ideal for creating client-side only applications.  Of course, if you are creating a Web Service or Web API service for the data, you probably want to use Visual Studio or something similar for all the backend development work, which may make things awkward if you have to go back and forth between the two environments.  In Visual Studio Code, there is no automated build system, but you can most likely get running out of the box fairly quickly, as long as you have all the development tools installed such as Node Package Manager, Typescript, TypeScript definition files, an easy to use Web Server, etc., etc., etc., etc.  That is of course grounds for another article, as it may be daunting to those unfamiliar with such a development environment.  After setting up the development environment, you probably want to start with a sample application, and also some good Angular.js documentation, as well as TypeScript documentation (see typescriptlang.org for a good start), as essentially you are going to be learning Angular.js, TypeScript, and JavaScript (if you don’t know it already.)  Note that some of the TypeScript files are essentially JavaScript like the app.ts file below in the example, so if you don’t know JavaScript, it’s a good idea to learn that first, as it’s quite a bit different from C# and Java.    

Getting back to my example application, I also had to create the project setup that would work well:

Figure 17:  Typescript / Angular Index.html page

Figure 17 is again an Index.html page, similar to the Angular example above.  See Figure 12 to view the similarities between the 2 applications.

Figure 18:  Typescript / Angular routing and application setup page (app.ts)

Figure 18 is using JavaScript to create the application setup file.  This again is similar to the Angular example above (Figure 11).  It adds the Angular controllers and services, (or factories if you have created any.)  Services and Factories are another way to create modules that connect to WEB API or Web Services.

Figure 19:  Typescript / Angular Product List controller (ProductListCtrl.ts)

Figure 19 is the actual TypeScript controller, which is quite a bit different from the Angular/JavaScript controller above (Figure 10.)  It is more like C# or Java with the interface and class.  Essentially the controller is still doing the same job though.  It is just passing data back and forth from the productListView.html page.  See figure 20 below:

Figure 20:  Typescript / Angular view (productListView.html)

Figure 20 is a view which is essentially the same as any other Angular view, since we are only using HTML and Angular.JS here.

This is a small application using Typescript and Angular.JS.  It is written in Typescript then ‘transpiled’ to JavaScript, so the actual code running in the browser is still JavaScript.  But, at design time, you have the full power of Object Oriented development, as there are now classes and interfaces, similar to what you would see in C# or Java.  In this case, the Index.html is acting like a ‘master’ page, and the productListView.html is loaded into the <ng-view> tag in the index.html page.  So, the Index.html is acting like the _Layout.cshtml page as you sometimes see in an MVC application.  Also, all the routing, and all the application configuration is run on the browser, and none of it is rendered on the server, then transferred back and forth to the browser.  This again results in less data being transferred back and forth to the server.   Let’s now see the initial view in the TypeScript application below:

Figure 21:  Typescript / Angular Initial index web page.

Figure 21 shows a typical scenario of a list view in a web page.  This was the result of all the Typescript code as seen in Figures 17 – 20 above. 

The Initial page load data is as follows:

Figure 22:  Typescript / Angular Initial index page load data.

Figure 22 shows the data loaded from the initial page load.  As you can see, Angular.JS is approximately 1MB in size, however, the minified version is only about 145KB in size, so this will be a non-issue in production.  That leaves the rest of the code to be about 300K, and the .js files are still not minified, so again, that will be almost a non-issue when it comes time to deploy to production.  Now, since this is a client-side only (JavaScript) application, you’ll again see another drastic difference between the data that is loaded on each subsequent page request:

Figure 23:  Typescript / Angular Detail View web page

Figure 23 is the resultant page loaded when the user clicks the link in the Product row as above in Figure 21.

Now, you are going to see something which is ideal in a web application:

Figure 24:  Typescript / Angular Detail View load data

As you can see from Figure 24, there is essentially no data being loaded from the Web Server, except of course for the image.  Since, the routing was entirely client-side, there is no data to be rendered on the server, or to be loaded into the browser, which makes this situation ideal in my opinion, as there is almost no server communication.  Of course, this now also removes our dependency entirely on ASP.NET MVC and its great features, like: ease of use, generated views using Razor syntax, Bundling, server-side routing configuration, and more.  And, you also now have to learn an entirely new language, which will make for a very steep learning curve for developers with only MVC experience, or with little to no JavaScript experience. 

Summary:

So, as you can see, this article compared and contrasted 3 somewhat different approaches to Web Development.  This article also eased the pain for those ASP.NET and ASP.NET MVC developers wanting to learn how to do away with server-side code as it relates to a Web Application.  It also shows the increase in difficulty level when trying to accomplish the feat of creating extremely high-performance web applications.  And for those trying to eliminate all crutches that ASP.NET currently provides, it shows a somewhat hybrid approach, when ASP.NET is coupled with Angular.JS to create a higher performance Single Page application. 

It is still premature, to simply jump on the TypeScript bandwagon, simply because it’s the latest and greatest thing.  I haven’t even gotten into creating advanced applications using Angular.JS and Typescript, which will be the subject of future articles.  So, once your application starts to become more complex, the difficulty in creating a TypeScript application, and the length of time it takes to create one may become another deciding factor on whether to use new technologies or simply go with a Hybrid approach using Angular.JS. 

References

- ASP.NET MVC starter project in Visual Studio 2013

- www.pluralsight.com/courses/angular-typescript

History

Version 1.0  -  Oct 7, 2015.