Thursday, 11 August 2016

Single Page Applications Fundamentals

https://msdn.microsoft.com/en-us/magazine/dn463786.aspx

What is a Single Page App.


Single-Page Applications (SPAs) are Web apps that load a single HTML page and dynamically update that page as the user interacts with the app. 
SPAs use AJAX and HTML5 to create fluid and responsive Web apps, without constant page reloads. However, this means much of the work happens on the client side, in JavaScript.


Traditional Page Lifecycle Vs SPA Lifecycle


In a traditional Web app, every time the app calls the server, the server renders a new HTML page. This triggers a page refresh in the browser. If you’ve ever written a Web Forms application or PHP application, this page life-cycle should look familiar.

In an SPA, after the first page loads, all interaction with the server happens through AJAX calls. These AJAX calls return data—not markup—usually in JSON format. The app uses the JSON data to update the page dynamically, without reloading the page.  When the json is retrieved the app uses a data-binding JS frame work like angular or knockout to bind the json result to the HTML.























One benefit of SPAs is obvious: Applications are more fluid and responsive, without the jarring effect of reloading and re-rendering the page. Another benefit might be less obvious and it concerns how you architect a Web app. Sending the app data as JSON creates a separation between the presentation (HTML markup) and application logic (AJAX requests plus JSON responses).

This separation makes it easier to design and evolve each layer. In a well-architected SPA, you can change the HTML markup without touching the code that implements the application logic (at least, that’s the ideal). You’ll see this in action when I discuss data binding later.

In a pure SPA, all UI interaction occurs on the client side, through JavaScript and CSS. After the initial page load, the server acts purely as a service layer. The client just needs to know what HTTP requests to send. It doesn’t care how the server implements things on the back end.

With this architecture, the client and the service are independent. You could replace the entire back end that runs the service, and as long as you don’t change the API, you won’t break the client. The reverse is also true—you can replace the entire client app without changing the service layer. For example, you might write a native mobile client that consumes the service.



JS Data-binding Frameworks.




5 comments:

  1. Replies
    1. The article provides a clear introduction to Single Page Applications by contrasting their lifecycle with traditional web applications. The explanation of loading a single HTML page and dynamically updating its content helps illustrate why SPAs can provide a more fluid user experience without repeatedly reloading the entire page.

      The discussion of AJAX and JSON also explains an important architectural distinction: the server can provide data while the client handles presentation and updates. This separation between application logic and HTML makes it easier to understand how frameworks such as Angular support Angular Course development.

      Delete
    2. The section on client-service independence is particularly useful because it explains how a SPA client can communicate with a service through an API without needing to know how the backend is implemented. The same service can potentially support different clients, while data binding keeps the user interface synchronized with application data, providing useful context for TypeScript Course learners.

      Delete
    3. The overview of routing, templating, and data binding also gives a useful picture of the responsibilities handled by JavaScript data-binding frameworks. These concepts form important building blocks for developing applications where the browser manages UI interactions while backend services provide data, making them relevant when progressing toward practical Angular Projects.

      Delete