By Chris Johnson @
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 11: Angular UI Routing Route setup file (AwesomeAngularMVCApp.js)
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
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 19: Typescript / Angular Product List controller (ProductListCtrl.ts)
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.
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 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
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.