Why Angular when there is already ASP.NET MVC

This was a question I was asked by a colleague recently. He is new to the webstack, so it was interesting how new people see the things.

In ASP.NET MVC I have routing, view, controllers, ... and in Angular I have these thins again... why the redundancy?

So I tried to explain him that the frameworks are not the same.

First the main difference is that ASP.NET MVC is executed on the server-side and Angular is executed on the client-side. If you want a fancy, interactive and desktop-like webapplication you can not get around a framework like Angular.
At the moment you use Angular you mostly do not need the M and the V of ASP.NET MVC anymore and you end up with something like ASP.NET Web API. The M and the V moved to the clientside represented by Angular which is now responsible for the rendering of the UI. ASP.NET Web API is for providing and manipulating the data to and from the Angular UI.

Pros

• no serverside rendering of HTML
• no postbacks to the server and fullpage re-rendering
• requests to the server with a small footprint using ajax
• the full power of javascript
• fast and responsible application
• caching of static javascript and html templates

Conclusion

In a world of thousands of frameworks around it sometimes isn't clear which framework is responsible for which tasks. Back to the example you may realize that Angular replaces a part of ASP.NET MVC if you code a fully fledged webapplication.

Creating a problemMatcher for gulp-tslint in Visual Studio Code

Recently I came up with the idea to parse the output of gulp-tslint to display it within Visual Studio Code to gather all errormessages at one single place. As Visual Studio Code does not provide an $tslint problemMatcher I created a custom one by adding a regular expression

Here you can see the regexp (line 18) to identify the lines in the console.log containing tslint messages. Line 19-22 are to map the capture-groups to the properties of Visual Studio Code error messages.


Its important to run tslint in full report-mode to capture the full path to the files. This enables Visual Studio Code to jump directly to the TypeScript files when clicking on the corresponding error messages.

You can find more information on this official page: Defining a problem matcher