Is there much point to using angular js on top of asp.net mvc since they're kind of both doing the same thing? What are the advantages to using angular over asp.net mvc + jquery? What kind of scenario would you pick angular in? If you do pick angular in a microsoft environment, what would you run on the server side? Would it be something like Web API? Or is there still benefit of using traditional asp.net mvc?
This question is a bit subjective, however here was our reasoning.
Let the client handle rendering of pages, free up resources on the server.
Leverage built in caching of cache servers since we are just dealing with <html/> content.
Since the pages are cached the only traffic back and forth is json payloads.
We have been using NancyFx, but WebAPI or Service Stack would work just fine.
We wanted to build a responsive single page application and AngularJs fit the bill for testability as full feature rich framework.
AngularJs forces you into a pattern that we needed for JavaScript, in the past our jQuery heavy applications turned into functional spaghetti (That was our fault but being guided by Angular helped out a lot).
As with all frameworks pick the one that suites your needs
On my site http://www.reviewstoshare.com, I am using AngularJS along with ASP.NET MVC. The main reason I did not go all the way with AngularJS was that SEO is not easily achieved with AngularJS.
Keep in mind that my site was already built using ASP.MVC + Jquery for in page interaction as needed.
On the other hand there is still some "Ajaxy" nature to the site like comments, voting, flagging etc. Not too different than Stackoverflow itself. Before AngularJS it was a mess of Jquery plugins and functions within $(document).ready() callback, not to mention the JS code was not testable much.
In the end, I went with both.
If you fancy using Java Script framework then Angular JS rocks.
SEO could be the issue. You need to have deeper understanding of DOM and Java Script as compared to other famous JS Frameworks.
I ve developed a Proof of Concept - using Angular JS with Require JS using ASP.net MVC
You can have a look at it at the below given link
http://angualrjsrequirejsaspmvc.blogspot.com/2013/08/angular-js-with-require-js-front-end.html
Related
I want to create a largish ASP.NET MVC Web application. On some pages I would like to utilise AngularJS.
This app will not be a SPA.
At what point does this become a problem? For example at what point does running effectively two MVC paradigms become a headache?
Or is it a case of as long as you have clear delineation between what's using ASP.NET MVC (standard action methods etc) and what's using Angular JS then the two run side by side ok without giving you massive code organisation/maintainability headaches?
Cheers for any wisdom.
I'd love John Papas opinion!
Andrew
Since you are only asking for opinions, I will be happy to share my experience. The two do mix very well, and I think in most cases (at least most of my own development) the .NET side becomes very light weight.
Your .NET Web API Controller becomes a simple call to the Data Layer to populate a model or List(Of T) models. This gets returned as JSON to the Angular service.
From there, Angular takes over all of the logic until you need to perform another CRUD operation. Manipulating, validating, etc. all happens client-side in either the model (for me the Angular service acts as the model in MVVM) or the angular controller (which is really a ViewModel).
It's best if you let your model (Angular service) handle as much business logic as possible and restrict the Angular controller to responding to clicks, input controls, etc.
To sum up, let your .NET server side be very light. Just transport data back and forth to the Data Layer. Let Angular do the heavy lifting. You definitely do not need to be building a SPA to see the wonderful benefits of a JS data binding library, of which Angular is arguably the best of breed.
An excellent blog post that contains [ details of what I've discussed here ].
Good luck!
I use ASP.NET MVC alongside AngularJS for a fairly large in-house application. We don't really use many features of ASP.NET MVC beyond the basic page template and script bundling - so everything from the client-side is controlled by AngularJS and client-side routing - except for some distinctions we've made between 'modules' of the app where we wanted a different ng-app for each, along with different script dependencies.
If you're looking to take advantage of AngularJS on a page-by-page basis then I think you have no problem at all. As long as you reference the scripts (both core AngularJS scripts, and your AngularJS scripts for modules, controllers, etc.) correctly then you can just begin decorating elements with ng-app, ng-controller, etc. and it will just work. You could insert the relevant AngularJS scripts for relevant .cshtml pages using a #section declaration.
It will only be more complicated if you need a mix of server-side and client-side routing. Then it will be a case of carefully constructing ASP.NET MVC routes to deliver the SPA functionality where needed.
I see this term Full-Stack Framework, when dealing with Web Application Framework, but there seems to be different opinions on it, and would therefore like to hear your opinions.
I've read this thread on stackoverflow (What is Full stack mvc framework? How Grails is full stack framework?) but, it doesn't clarify the UI part enough?
In the Laravelbook (http://laravelbook.com/laravel-architecture/) it says:
"Laravel is referred to as a “full stack” framework because it handles everything from web serving to database management right down to HTML generation."
So by this definition ASP.NET MVC would also be a Full-Stack Framework?
But just because you can serve an end user with HTML, does it then make it a Full-Stack? What about the interaction (JavaScript)? Like this article says, http://www.smashingmagazine.com/2013/11/21/introduction-to-full-stack-javascript/
MEAN is also referred to as Full-Stack Framework and has AngularJS included for the user-interaction? I've read that this makes MEAN truly a Full-Stack Framework, and if Laravel or ASP.NET MVC is combined with lets say AngularJS, then these would be a Full-Stack Web Application Framework.
And this is where i get confused, because with Laravel or ASP.NET MVC you can build an application alone with the framework it self, and also ASP.NET have async operations build-in with controllers, so maybe would't need something like Angular?
Isn't the JS interactions like the ones you can do with Angular just a matter of opinion, and what about just using plain old jQuery library for the DOM updates? Does the Full-Stack need to have a JS framework?
How do you define or argument for something being a Full-Stack Web Application Framework?
A full-stack framework is able to handle everything you need to build a complete web application. It is not saying that you can't add anything else to it that might make it easier for you to achieve certain goals such as using Laravel for the back-end and AngularJS for the front-end.
Framework combining rises out of wanting to find the best possible solution for what you are trying to achieve. In the example mentioned above, developers find it beneficial to let AngularJS handle the front-end not only because it might make it easier to create a dynamic single page application, but also to achieve code separation between the front-end and back-end. This allows your application to be more modular, which we all know has a lot of benefits (testing, api creation, third party integration, etc).
In the end, it all depends on what you are trying to achieve. If your goal is to have a simple web application you might only need to have one full-stack framework, but if your application has multiple ambitions then you might find that combining frameworks would be the best possible solution.
I come from using ASP.NET MVC/Web API and now I am starting to use Angular but I am not clear on the proper way to mix them.
Once I am using Angular does the MVC sever side concepts still provide any value ? Or should I strictly be using Web API purely to get data for the angular HTTP calls ?
Any tips you have for a ASP.NET MVC guy transitioning to Angular would be helpful
Pure Web API
I used to be pretty hardcore with ASP.NET MVC but since I've met Angular I do not see one reason why I would use any server side content generation framework. Pure Angular/REST(WebApi) gives a richer and smoother result. It's much faster and allows you to build websites that come quite close to desktop applications, without any funky hacks.
Angular does have a little learning curve, but once your team has mastered it, you'll build much better websites in less time. Mainly this has to do with the fact that you don't have all these state(less) issues anymore.
For example imagine a wizard form with any traditional server side framework. Each page needs to be validated and submitted separately. Maybe the content of the page is dependent on values from a previous page. Maybe the user pressed the back button and is re-submitting an previous form. Where do we store the state of the client? All these complications do not exist when using Angular and REST.
So ... come over to the dark side ... we've got cookies.
Similar question
AngularJS is more associated with the single page application paradigm, and as such, doesn't benefit much from server-side technologies that render markup. There is no technical reason that precludes you using them together, but in a practical sense, why would you?
An SPA retrieves the assets it needs (JS, CSS, and HTML views) and runs on its own, communicating back to services to send or retrieve data. So, a server-side technology is still necessary for providing those services (as well as other means such as authentication and the likes), but the rendering parts are largely irrelevant and not particularly useful because it's a duplication of efforts, except MVC does it on the server side and Angular does it on the client. If you're using Angular, you want it on the client for best results. You can make Angular post HTML forms and retrieve partial views from MVC actions, but you'd be missing out on the best and easiest features of Angular and making your life harder.
MVC is pretty flexible and you could use it to service calls from an SPA application. However, WebAPI is more finely tuned and a bit easier to use for such services.
I've written a number of AngularJS applications, including a couple that migrated from pre-existing WebForms and MVC applications, and the ASP.NET aspect evolves towards a platform for delivering the AngularJS app as the actual client, and for hosting the application layer the client communicates to via REST (using WebAPI). MVC is a fine framework, but it usually finds itself without a job in these sorts of applications.
The ASP.NET application becomes another layer to the infrastructure, where its responsibilities are limited to:
Host the dependency container.
Wire the business logic implementations into the container.
Set up asset bundles for JS and CSS.
Host WebAPI services.
Enforce security, perform logging and diagnostics.
Interfacing with application caches for performance.
Another great thing about an SPA is it can increase bandwidth of your team. One group can blast out the services while the other lays in the client app. Since you can easily stub or mock REST services, you could have a fully working client app on mock services and swap out for the real ones when they're done.
You do have to invest up front on Angular, but it pays off big. Since you are already familiar with MVC, you have a leg-up on some of the core concepts.
It depends on the project you are working on.
If angularJS is something new for you I would rather pick a small low risk/pressure project to get started and ensure you learn how to do things in the right way (I have seen many projects using Angularjs wrong because of pressure, deadlines... lack of time to learn it in a proper way, e.g. using JQuery or accesing the DOM inside the controllers, etc...).
If the project is a green field one, and you have got some experience on AngularJS, it makes sense to abandon ASP.net MVC and in the server side go for pure REST/WebAPI.
If it's an existing project, you can pick up a complex subset of functionality and build that page as a separate angularJS app (e.g. your app is composed of a big bunch of standard simple / medium complexity Razor based pages but you need and advanced editor / page, that could be the target piece to build with AngularJS).
You can use Angular framework for front end development i.e to construct views. It provides you a robust architecture and once you learn you will find it's advantages over Asp.net MVC's razor view engine. To fetch data you have to use WebAPIs and now ASP.Net MVC project support both WebAPI and MVC controllers out of the box. You can refer below link start with Angular and ASP.Net MVC application development.
http://hive.rinoy.in/angular4-and-asp-net-mvc-hybrid-application/
There are two frameworks currently available for developing UI components for angular applications. I have used both these frameworks in one of the angular projects that I worked.
Material
https://material.angular.io/
PrimeNG
https://www.primefaces.org/primeng/#/
I'd like to use for my next project Ext js and ASP.NET MVC.
I'm wondering what would be the best way of using this two framework together. So far I did some project using ASP.NET MVC, where every action method returned a view and reloaded the page. The Ext js mvc application uses a single page approach.
As I'm pretty new to ext js so I'm wondering if someone could share some experiences of building real world application using this two frameworks.
You can use extjs as you think is better for you. You can use its components as simple widgets or create a full javascript (extjs) client. However, which are the real requirements? a single page client or a traditional client?
In our current project we started using ASP.Net MVC Framework with extjs widgets, it was ok for a while but the customer wanted more and more sophisticated UI and a better user experince (among other thing) then, we changed the app, we left MVC models and controllers (views were removed) and we created a full javascript client with extjs 4.1.
After that we realized we were using an ASP M_C framework (with no views) and that was a nonsense so, we took the ASP MVC project away and replaced it by a WCF Rest service (it also could be done with an ASP.Net Web Api).
We feel proud of our decision and the resulting design. If you can, if you know extjs (learning it is rather hard) and javascript and, if you have support to your decision then, keep your application splitted in two:
a server-side service/api and,
a full javascript application.
Good luck!
I'm not sure I'd agree with the answer by #lontivero, I'm currently working on a project using ASP.NET MVC as the backend and ExtJS as the front.
You do, as pointed out, loose the V from the ASP.NET MVC stack and you end up needing to duplicate you C# view models in you ExtJS Models on the client side but I've found using MVC as a backend (effectively as a rest based collection of Json end points) absolutely fine.
You can utilise the model binding, model validation in MVC whilst leveraging the full client side js app in Ext.
I'm curious as to the points you didn't get on with using this structure (I'm not saying it's perfect, but it does seem to work)
We used Ext.NET (versions 0.x-1.x) in our previous projects. Even after a comprehensive effort to upgrade our projects to the (now current) version, we had to drop Ext.Net 2.x out.
If it fits you, it can help.
The main problems with Ext.Net were (several) incompatibilities with ASP.NET and a lack of trust. They used to keep their schedule, it's far from it for last 2 years or so. And they are behind ExtJS.
I started in the web development world with PHP, and then Rails in the recent few years. Since then I've been doing all my web projects in Rails.
Recently there seems to be a movement towards making Rails as a pure RESTful backend service and using frontend framework such as Backbone.js for all frontend interaction. I'm wondering what's you guys' take on it? Will this be the eventual future?
As well, besides Backbone.js, what are some other alternatives for frontend framework for this purpose?
Also assuming that I will want to support both a desktop version and a mobile version of my app, would this be a proper route to take? So I'll have a single backend service with different frontend services? This way I don't need to manage all the views on Rails' side?
Thanks!
For Client-side frameworks, this article has a list of 20 of them with pro's and con's:
http://net.tutsplus.com/articles/web-roundups/20-javascript-frameworks-worth-checking-out/
Here's the list:
Backbone.js
Knockout.js
Asana luna
Cappucino
Sproutcore
BatmanJS
corMVC
TrimJunction
pureMVC
jamal
choco
sammyjs
extJS
agilityJS
eyeballs
activejs
spinejs
qooxdoo
These are roughly all about creating client-side, ajax-based, javascript MVC frameworks.
If you're looking to start somewhere, then I recommend thinking about Client-Side Templates (...ates...ates...ates) (just the "V") to support a service-oriented architecture (many clients are supported by service-endpoints you create).
It's a new technique that involves modularizing your client-side code, bringing MVC to the client, and let business-logic live in the platform. A lot of Software-as-a-Service applications are leveraging them, and with the increasing sophisticated of javascript libraries and frameworks, as well as browser capabilities with HTML5, CSS3, etc. there's going to be an increasing sophistication in client-side presentation.
So learn it.
What are the benefits?
To paraphrase Linked In: for leveraging browser-caching, de-coupling your front-end client-side presentation, asynchronous load, progressive rendering (for some frameworks), performance, ajax-interaction, and more.
Several great frameworks include:
mustache
dust.js
handlebars
Google Closure Templates
Nun
Mu
kite
I highly recommend looking at Linked In's move away from JSP towards Client-Side Templates and why they choose dust.js in Linked In's front-end client-side templates throwdown for a comparison. They go into much greater detail, and research, as to why they changed their stack to support this (it involved using 3 server-side technologies), as well as their comparisons of all the frameworks they could find.
I did something like this a few years ago in .net. Is was not via proper .NET MVC and didn't use the new JS frameworks, but the principle was the same; server code returns JSON to javascript which builds the page and interactions etc.
The result was a lovely responsive website, but, maintenance was a nightmare. Be very careful to keep your JS code well organised.
Personally, I find it easier to maintain server code (in any language) than javascript so I wouldn't go down that route again.
(IMHO)
Fran
It is my opinion that contemporary web applications are moving towards this model of having RESTful back-end and all the view interactions coded in front-end. These free video tutorials from Joe Zim:
http://www.joezimjs.com/javascript/introduction-to-backbone-js-part-1-models-video-tutorial/
helped me understand backbone and how it can simplify templating and view renders.