Why I prefer a JavaScript framework vs. ASP.NET MVC

DZone 's Guide to

Why I prefer a JavaScript framework vs. ASP.NET MVC

· Web Dev Zone ·
Free Resource

There are five reasons from my perspective, good enough to prefer a mature and well designed JavaScript framework versus ASP.NET MVC. This is not performance related at all. I will not come with reasons like 'ASP.NET MVC is a server side development framework so it imposes and extra load on web server due to rendering (Razor Engine or ASP Engine) while Angular has an impact strictly on client machine'. As you noticed, my favorite JavaScript framework is Angular and that is not because it was developed at Google, it is because I find it to be a very elegant and comprehensive framework, this is a subjective opinion any way. I will start to present my five reasons from the most superficial to the most realistic.

First reason of all, mixed code...I really dislike it, I really do. Even after so many years of working with ASP.NET (WebForms and MVC) I still can't accommodate with it. The look and feel of server side code embedded into pages (chtml pages in my case) is a true pain for my eyes. I find it difficult to follow the code logic and navigate through it. Not to mention the fact that some people can be really inventive when it comes to what server side code generates in the page.

The second reason is, OK this is strictly my opinion so I might be wrong about it, client code is for clients and server code is for servers, simple as that. What has to deal with client side, is mainly related to how data is retrieved,  presented and how the end user interacts with it should be a client side code concern only (let the browser do its job). Same thing applies to server side, let the server side code handle all business logic, data persistence and all the another nuisance aspects, don't bother the server with concerns about how the information has to be presented and how the end user should interact with it. I always choose SOA approach for my applications which can be either SOAP either REST.

The third reason is, there is no way a designer (not sure if this is the most appropriate term for an HTML/CSS expert) will work easily on pages which have server side code embedded. The "why?" is quite obvious I assume. Unless you are lucky enough to have an experienced developer on both fields  (HTML/CSS and ASP.NET MVC). The server side code is way too intrusive from my point of view, compared with how Angular works.
The forth reason is, most developers do not pay same attention to both sides. How many times have you seen JavaScript code sprinkled in pages? How many times have you seen JavaScript functions flying around? How many times have you seen JavaScript code blocks without being encapsulated in a namespace? You know why? Because the main idea behind having server side code to generate UI is to cover the lack of strong skills related to client side development (JavaScript, etc).

The fifth reason is, you can't test it. Yes, you can't test the final result unless the server code works as it  should. Imagine that you want to check if your page always displays data in a strictly defined order. Or if amounts or dates for example are formatted correctly based on client culture. What will happen if there is a bug on server side code which doesn't allows you to build the project, or something goes wrong on data access layer? Are you going to be able to test your page? I think not. Same thing doesn't apply if you have the client and server as totally  separated tiers (as they should normally be, after all we are talking about client code and server code). You could easily mock the data needed in tests with JSON without carrying if the server is fine or not. You could easily do this sort of tests with Karma Test Runner for example.

If you enjoyed this article and want to learn more about ASP.NET, check out this collection of tutorials and articles on all things ASP.NET.

angular, asp.net mvc framework, dotnet, javascript, testing

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}