Javascript – How to structure a modern web application

asp.net-mvcjavascriptprogramming practicesweb-development

Background

I recently developed, for two different projects, two web applications.
The two followed quite different approaches. The first one was a classic inventory application (lists of stuff to view, select, edit.. very CRUD) and was developed with Razor and ASP.NET MVC: controller accepting requests, getting a model through a Repository, building different Viewmodels out of it for view and editing, pass the Viewmodel to the view engine and render of the page.

Very direct stuff (you can almost build such an application with wizards only using ASP.NET MVC), with very little Javascript "magic" (only the minimal offered out of the box by the MVC framework, mainly for validation).

The second one was quite different: this application is basically a bunch of screens (views) through which the user can navigate back and forth, which appearance change as users input data in different places – it is basically a hub in which the user views and reviews information linked to his account(s).
I built this second application as a REST service (built with ServiceStack, and therefore following the design patterns it enforces – like Data Transfer Object) and a SPA application implemented using AngularJS. The angular application uses its (excellent) http service to get the JSON objects from the rest service, and then populate its (client side) Viewmodel (the scope). Very neat and clean; it is easy to navigate back and forth the various account information (which is visualized in many different ways: lists, graphs, …)

It is maybe a little more difficult to code at times (authentication/authorization is a bit more difficult (you have to be careful to mimic control on client and server, for example).

Now, I am starting a third project. It is something in between: it is still a CRUD application, but it needs to be very responsive. For example, in a page, we have a complex information to enter (combo of form and list); in the list the user need to select a item from another list, but if the item is not there we want to open the "edit list items" view, let him/her insert the item, and go back to the original page… all without refresh/pushback/… You got the idea.

The question

Which is the best way to accomplish this, to develop a modern, quick, responsive web application? I have seen too many different approaches:

"control based" (jQuery) approach: build the page using your MVC framework (which will produce html, a table for example), use jQuery to "enrich" the html and make it ajax
"data based" (Angular): build the page as an html page with data bindings, a JS application, and structure the server side as a REST service, that the JS app uses to get/post data
the mix #1: part of the app is built using your MVC framework (which spits out html), part using a data-based framework (like angular). Angular scope/model is initialized using jQuery to extract the initial data out of the html DOM.
the mix #2: part of the app is built using your MVC framework (which spits out html), part using a data-based framework (like angular). In addition to html, the server writes a "script", which is JSON data, and embeds it into the page. Angular then uses it as its model to render the data visualization (client side)
the mix #3: same, but this time no embedded JSON: the server exposes a REST service that is used by Angular to retrieve the data it needs. It is essentially part generated on the server, part on the client through a secon call to get e JSON object
(more…?)

I personally find the mix #1 and #2 ugly, but I am too "new" to modern Javascript development to judge. Are they common? I see for example that one advantage of mix #1 is that you get the initial view immediately, you do not need to wait for JS to render it. And both mix #1 and #2 do only one call to the server.

So, which one is the best practice? Or which one(s) should I really avoid?
I (personally) am more comfortable with a mix of server-side generated pages and client-side JS; making a SPA completely using services was not that easy, more than one time I wished to have something generated using server-side logic, but I may be doing it wrong (that is why I am asking!)

Best Answer

Your Question is going to return some very opinion based answers. So I am trying to answer as neutral as possible regarding which Framework or option to use.

I think every thing you pointed out is fairly modern as are all your listed technologies. jQuery and AngularJs aren't that old I guess.

Also I believe that you have already answered your own question. Let me explain my utterrance in detail :

Out of 3 mentioned practises you don't like 2, so only one mix really remains.

I personally find the mix #1 and #2 ugly

Why not just go with what you are comfortable with for now instead of relying on the opinion of other people. You seem to know what you are doing and have an open mind to new developments in your field so why worry about what other people think for now. Your question helped me discover something new. Thx for that. Hope that helped.

Originally a comment was just too long for it to be one.

Related Solutions

Mixing Angular with ASP.NET MVC/Web API

The easiest way to think about it is that the server serves a state. Angular can manage collecting the updates to that state and send it to an web/api on the server. If you want to go more single page app, then the server side code would be just the initial state of your app.

Web API is a excellent place to start for for pulling your data into your app. You will eventfully update the default routs to meet your environments design requirements and if you want, to be strictly rest-full.

There are quire a few libraries that ASP4 included by default and those were also included in the MVC4 templates. There really are many things included in the page that are not needed, as wells as included in the project and never even referenced by their default pages. You should be safe removing everything except jQuery and I even go as far as taking out jQueryUI. Many of the defaults mean well but once you start to fill in your domain knowledge you will use libs that meets your specific needs.

Even with a strict divide you will find server side mvc is still a very clean backing to a single page app. Effective routing in delivering your page and your api calls is a prime example. Another useful feature are controllers that return views that don't use the master page or are only a partial view. Angular has a "view" that it can fill with a template, which can be a static file or a partial from one of your routes.

I read you comment earlier today and threw together a demo solution to show what I originally mentioned. The solution also has some of the original "fluff" removed though when adding Angular and Bootstrap you get the core libraries and every derivation there with. That's the trade off of using nuGet.

Check it out: https://github.com/QueueHammer/AngularWithPartialViewViews

In learning Angular I found the Angular-Seed program fairly helpful. Especially after I tried the demos on their site. The sample project is just different enough that it helps you learn. After that I looked at Angular-Require-Seed but that's another post. Angular Step by Step http://docs.angularjs.org/tutorial Angular Seed: https://github.com/angular/angular-seed

Javascript – Web Application: Combining View Layer Between PHP and Javascript-AJAX

If you're going to have a significant amount of logic written client-side, then consider using MV[C]-style "separation of concerns" in your client-side JS code. For example, you might have some JS "view" logic which handles rendering:

<script type="text/javascript">
function renderUser(user) {
  $('#username').val(user.username);
  $('#dateOfBirth').val(user.dob);
  $('#address').val(user.address);
}
</script>

Then define some JS "controller" logic to pass the data into the view. The design of this depends on expected usage of the application -- e.g. if "user" is only rarely displayed, then the JS controller logic might look like:

<script type="text/javascript">
function showUser() {
  $.ajax({
    type: "POST",
    url: config.indexURL + "user",                
    dataType: "json",
    success: function(data) {
      renderUser(data);
    }
  });
}
</script>

On the other hand, if the user is displayed on every page-request, then it's non-performant to fetch the user via AJAX -- better to include the user data as part of the initial page request. You can still use the same rendering function:

<script type="text/javascript">
renderUser(<?php echo json_encode($userdata); ?>);
</script>

Or if your web-application provides a real-time list of new user-accounts via web-sockets, you could draw them on-demand:

<script type="text/javascript">
var ws = new WebSocket("ws://localhost:9998/users");
ws.onmessage = function (evt) { 
    renderUser(evt.data);
};
</script>

The examples above are a crude but hopefully demonstrate the flexibility that comes with separating MVC in JS. For a better discussion of that topic, check out a tutorial on one of the popular JS MV* frameworks (Backbone, Angular, Ember, etc).