I've been struggling in deciding what direction to go with in regards to the best approach for rendering content to the browser: server side using razor or client side using JSON data and some form of templating (jsRender, loadJson, etc.)
Here's a great article on using client side templating with asp.net mvc:
jQuery Templates/View Engines in ASP.NET MVC
ASP.Net MVC 4 has some great toys (WebAPI). I can see creating a suite of WebAPI functionality for delivering JSON data that can be used on traditional web pages and even mobile pages. Really cool stuff.
Then I look at what options you have going with a traditional ASP.Net MVC approach. You have layouts, can take advantage of automatic bundling/minification of JS/CSS files (more ASP.Net MVC 4 goodness), robustness of having ASP.Net MVC available at your fingertips. Really cool stuff.
So, my question is how do you make decisions on which direction you should go architecturally? I suppose you can have a mix bag of approaches within your site, but that becomes a maintenance issue. Going total JavaScript Templates and consuming JSON data from a service is a super clean separation of concerns, but it seems you loose out on a lot of the goodness that ASP.Net MVC offers like routing.
What's the best approach for balancing all of the options available to us?
This is a bit of a general question, so a general answer is that you should stick to the approach that makes you most productive/gets the job done. Either approach works but of course has tradeoffs. However those usually don't matter that much unless you reach really big scale (e.g. Twitter recently annonced it will move back to server-side rendering for performance reasons). If you're already familiar with MVC and you're working against a deadline - stick to that. If you have more time or want to learn a new technique - go with what looks interesting.
Related
I'm currently evaluating the use of Backbone.js along with Aura.js for building an enterprise scale SPA.
I have a nice Javascript architecture mapped out that provides abstraction, consistency, flexibility and no dependencies on any base libraries.
As I see it, in using any MV* pattern (and in particular Backbone), markup generation could be scattered throughout views via a combination of direct dom manipulation and external html templates.
I would like to apply the same principles to the html markup in my views as I have with my Javascript architecture.
Abstraction - Ideally I would like to provide developers with a simplified API for producing markup, potentially shielding them away from the css classes/markup structure being used.
Consistency - I would like to promote and control consistency in the markup produced within a team of developers.
Flexibility - I would like to avoid having to find and completely rewrite all instances of certain markup if there comes a need to change either the css classes/markup structure being used. Ideally I'd like any changes to be made in one place, that will propagate throughout all uses within the system.
As a practical example of how this can be achieved server-side, we currently use a suite of custom HtmlHelpers within ASP.NET MVC (similar in design to KendoUI). These helpers provide a nice fluent API for developers to use and centralise control of the markup that is generated.
However as we're moving towards client-side UI generation I'm not sure how to gain the same benefits that are available in server-side markup generation.
I appreciate templates can provide re-usable widgets throughout the UI, however that does not completely address the issues outlined above, which apply when creating those templates and the layout to contain them.
So to summarise my question...
What practices can be employed to achieve control and consistency in markup generation within a team when developing enterprise scale SPAs?
Since your question is limited to Backbone.js and Aura, I'm not sure this qualifies as an answer, but I would definitely check 3 things
AngularJS and AngularUI - the concept of directives, resembles the notion of Web Components (a work in progress W3C standard for web controls)
If you like typed coding, and likes to live on the bleeding edge, check Dart Web UI it also uses a pretty much similar concept
If you have to stay in Backbone land, then I would check Backbone UI of course
I believe the first 2 have a better chance of answering your 3 requirements.
Could any one please suggest the best MVC4 WEB API Grid ?
Right now we are using Mustache templates to display Data.
Current App: MVC 4 Web API, C#.Net, Visual Studio 2012, Mustache templates
Client wants Mustache templates to be replaced with nice grid with all the search and sorting features.
Datatables.net provides a lot of functionality and is widely used.
I've had success using jqgrid - a lot of functionality and demos for mvc -
http://www.trirand.com/blog/
Datatables, jqgrid, kendoUI etc.. they will in the long term cause you extreme frustration and unhappiness.
Best thing to do is really make data LOOK like a grid, you can have complete control and really understand what is going on and do sorting and paging etc.. Use Bootstrap for CSS and make ajax calls to Web Api.
Angular is really nice, but you can start without Angular. I've been on 40 projects in which the 3 I mentioned caused a lot of headaches for many people including myself.
I want to start a project and I am evaluating the architecture.
And now I am at point to decide the front end components.
I want to use HTML5 + Css3 + Javascript
On Javascript side I don't know what do you recommend. YUI or Backbone. I don't know how to evaluate what can be the best for me. The idea is to create a Browser web app and a Mobile app.
Do you recommend another framework for do that? Or some book, url or something that expose how to organize my front end?
This might be a bit late. But I will say this. I've looked through these so far:
Angular, Knockout, Backbone, YUI
And I read some other comments on Ember.
From what I've seen, Angular and Knockout take the same starting approach. They start out telling you how to interface with the front end. I do NOT like this. They give you a whole lot of rope to hang yourself with if you don't know how to design good architecture. Its completely up to you to build a proper MVC app with them.
From what I've seen of YUI, its EXTREMELY similar to Backbone, which is no surprise because YUI was INSPIRED by Backbone. I have spent a LOT of time looking at backbone and I'm very impressed with it. If you follow its principles and standards, it will encourage you to build a sound framework that won't leave you hanging later.
But I saw another commentor who actually actually moved from Backbone to YUI because he said YUI is more streamlined and all around better. I wouldn't be surprised if this is true. But I need to evaluate it further.
Many folks, including myself, agree that Ember, Knockback, and Angular are rather "heavy handed" in their approach. Like I said, they START with explaining how to interface with the HTML. Right out of the gate, they're wanting you to do things a certain way. This could be very problematic depending on your particular application.. OR it could make your particular application a piece of cake if it fits nicely in their approach!
My two cents!
Backbone is great for creating web apps, both for desktop and mobile. It's strongest point is that it's small and quite simple: you can actually read through the entire annotated source code. Backbone helps you structure your code in a maintainable way, which is the main benefit.
The downside of backbone is that it's not very beginner-friendly: setting up the collections, models and views can be quite challenging if you're not used to it. It also doesn't help you at all in rendering the views, which is a blessing and a curse: it's not as easy or helpful as a widget based framework, but it also doesn't get in your way, which is especially important when implementing the mobile app.
I would recommend you study the backbone todo-example ( http://documentcloud.github.com/backbone/#examples-todos ) to get an idea how the framework works.
The server side is pretty much set up, it's basically
struts 2 / spring security / jpa.
Now I have to decide what to do with the client side (the browser). The client side codebase should be maintainable and should lend itself to automatic regression testing.
So as an example lets say I need a table component having properties such as
sortable/pageable columns
reordering of rows and columns (via drag & drop)
inline editing of table cells
remembers state when customer re-visits page
integrates easily with struts 2
As far as I understand things there're 4 alternatives
DIY using oldschool HTML + JQuery + Ajax
Finding a JQuery plugin that does all this or
plumb together different plug-ins (like Flexigrid + additional plug-in for drag & drop)
Using a JS toolkit
Should I stick with JQuery? Or should I go for fullblown JS toolkits? I have little experience with JQuery and JS toolkits (I'm not a web developer).
Thank you for helping a serverside programmer cross the messy world of web-ui-programmming ;)
My experience is that Dojo's support for programming-in-the-large is great if you have a large-scale app that will benefit from the build system, class system, widgeting system and integrated widgeting library. It also of course brings all the standard stuff with it, like cross-browser support and event system.
If you just need some widgets and animations then any library will work. I'd stick with the one you/your team knows best. jQuery definitely has the greatest number of people with that skillset.
Our team wasted 6 months trying to give the client what they wanted with JQuery/UI, and we switched to ExtJS 4, and the client is happy after 2 months. This is an app with 50+ models.
JQuery/UI is NOT designed for web applications. It is designed for web SITES. Sure, it has some good plugins, but you'll spend countless hours learning their apis and switching your thought process between them all. JQuery/UI lacks the following:
a graphical designer (see Sencha Designer 2), ie graphical layout GUI program
complicated layouts (in ext you can switch a layout of a container to accordion, tabs, wizard, anchors with one setting)
a grid (ext grid supports paging, sorting, filtering, grouping, summaries, editing out of the box)
real comboboxes
a model view controller system
templating
good html editor control
a whole ton of other stuff
do yourself a favour and spend the money on ext, and save yourself countless hours.
regarding the grid you mentioned, ext's is far superior to anyone else's. you can do what you listed in about 20 nicely-formatted lines. i am not kidding.
regarding client-side unit testing, use jasmine with ext.
The short answer is yes. Frameworks like Ext.js take care of a whole lot code that you would end up writing yourself if you were to write everything from scratch. These frameworks take care of models, events, views, communication with servers/APIs, etc.
This isn't really an answerable question. It all depends.
ExtJS is great for very specific things. If you want those very specific things, it's likely the most efficient option for you.
If jQuery UI meets your needs, then that's your answer.
If you have jQuery dev's, maybe stick with jQuery.
If you have ExtJS folks, consider ExtJS
etc, etc.
I work with C# at work but dislike how with webforms it spews out a lot of JavaScript not including the many lines for viewstate that it creates.
That's why I like coding with PHP as I have full control.
But I was just wondering how this sites HTML is so clean and elegant?
Does using MVC have something to do with it? I see that JQuery is used but surely you still use asp:required validators? If you do, where is all the hideous code that it normally produces?
And if they arent using required field validators, why not? Surely it's quicker to develop in than using JQuery?
One of the main reasons I code my personal sites in PHP was due to the more elegant HTML that it produces but if I can produce code like this site then I will go full time .net!
One of the goals of ASP.NET MVC is to give you control of your markup. However, there have always been choices with ASP.NET which would allow you to generate relatively clean HTML.
For instance, ASP.NET has always offered a choice with validator controls. Do you value development speed over markup? Use validators. Value markup over development speed? Pick another validation mechanism. Your comments on validators are kind of contradictory there - it's possible to use ASP.NET and still make choices for markup purity over development speed.
Also, with webforms, we've had the CSS Friendly Control Adapters for a few years which will modify the controls to render more semantic markup. ASP.NET 3.5 included the ListView, which makes it really easy to write repeater type controls which emit semantic HTML. We used ASP.NET webforms on the Microsoft PDC site and have kept the HTML pretty clean: http://microsoftpdc.com/Agenda/Speakers.aspx - the Viewstate could probably be disabled on most pages, although in reality it's only a few dozen bytes.
You were on the right track. It is the fact that they are using the ASP.NET MVC web framework. It allows you to have full control of your output html.
The ASP.NET MVC Framework is an alternative to the normal "web forms" way of doing ASP.NET development. With it you lose a lot of abstraction, but gain a lot of control.
Yes - MVC doesn't utilize the ASP.NET view state junk.