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 didnt 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

Youll 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 MVCs 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. Lets 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 dont 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 dont know JavaScript,
its a good idea to learn that first, as its 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. Lets 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, youll 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 clientside, 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 highperformance 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
its the latest and greatest thing. I havent 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.