ºÝºÝߣ

ºÝºÝߣShare a Scribd company logo

SinglePageApplications

?Download as PPTX, PDF?
?
Adi Challa
Adi Challa

This document discusses the evolution of web applications from static HTML pages to single page applications (SPAs). Early web applications used static HTML pages that loaded entirely when requested, while dynamic pages loaded content from a database. JavaScript added interactivity but required page reloads to update. AJAX allowed updating parts of a page without reloading via XML/JSON. Native apps communicated with servers via APIs for new data. SPAs combine JavaScript, DOM manipulation, and AJAX to allow web browsers to behave like native apps, loading initial content and then updating dynamically without reloads. This avoids maintaining separate web and API code.

1 of 15
Download to read offline
The What? Why? And How? Single Page Applications
The beginning of the beginning¡­ (early 1990s) Request (GET) for a Static HTML Page Respond with requested Static HTML Page STATIC HTML PAGE
The beginning of the beginning¡­ (early 1990s) Request (GET) for another Static HTML Page by clicking on a Hyperlink Respond with requested Static HTML Page FROM ONE PAGE TO ANOTHER
A little after the beginning of the beginning¡­. (mid 1990s) Submit new order to the server using an HTML form Store the order and respond with a confirmation HTML page. FORM SUBMISSION (POST)
A little after the beginning of the beginning¡­. (mid 1990s) Request for a Dynamic Page showing all orders so far¡­ Generate a dynamic html page based on current data and respond with that page. DYNAMIC PAGES (GET)
Birth of a star¡­ (1995) Request for a Page Respond with the page along with its corresponding JavaScript which adds behavior to the otherwise extremely boring and inactive page. JavaScript
Birth of another star¡­ (1996) Request for a Page Respond with the page along with its corresponding CSS which gives a way to separate structure from presentation. CSS
The 3 stars that became super stars¡­ Structure Presentation Behavior
Exchange of new information with the server, after a page is loaded, required a page refresh or use of browser plug-ins such as Macromedia Flash, Java Applets, etc. ? Eg: While following a game, the sports page needed a refresh every 30 seconds so that a whole new page was generated by the server with the latest scores. ? Eg: A chat session required a browser plug-in such as Java Applets which allowed the display of new messages on the page. ? Eg: An interactive video game page required a browser plug-in such as Macromedia Flash to allow the page to interact with other users. The Big Limitation¡­
Enter the game changer (2005)¡­ Request for latest information behind the scenes without reloading the parent page using just plain JavaScript and no plug-ins. Respond with information requested that can be quickly integrated into the parent page by the browser without reloading.
Enter the devilry¡­ Native Apps (2007) Request or send data in the form of XML or JSON while all the screens and their rendering is handled client-side. Respond with the requested data or acknowledge receipt of new data from the client.
Too much happening server-side¡­ With the entry of Native Apps web applications now needed to maintain two sets of code on the server-side¡­ 1) One set of code to continue supporting web browsers which required.. 1) rendering of HTML pages with data pulled from the database. 2) acceptance of form data and responding with an acknowledgement page. 2) Another set of code to exchange just data with Native Apps via APIs. Pretty much every major feature that a web application provided had to be made available also in the form of an API.
Need for better life¡­ Maintaining two sets of code doing more or less the same thing is always a pain. How can we avoid it? Is it possible to come up with a way where we only need to maintain one or the other? Well¡­ let¡¯s think about it¡­ all we have to do is make the web browser behave like a Native App. How can we do that? Well¡­ we have JavaScript which can render new elements based on data. It can also allow content to be changed within an element in the DOM. And we have AJAX which allows new content to be brought in without reloading the page¡­ So, all we need to do is to combine all these features!
Single Page Applications
A much better life¡­ Request or send data in the form of XML or JSON while all the screens and their rendering is handled client-side. Respond with the requested data or acknowledge receipt of new data from the client.

More Related Content

SinglePageApplications

  • 1. The What? Why? And How? Single Page Applications
  • 2. The beginning of the beginning¡­ (early 1990s) Request (GET) for a Static HTML Page Respond with requested Static HTML Page STATIC HTML PAGE
  • 3. The beginning of the beginning¡­ (early 1990s) Request (GET) for another Static HTML Page by clicking on a Hyperlink Respond with requested Static HTML Page FROM ONE PAGE TO ANOTHER
  • 4. A little after the beginning of the beginning¡­. (mid 1990s) Submit new order to the server using an HTML form Store the order and respond with a confirmation HTML page. FORM SUBMISSION (POST)
  • 5. A little after the beginning of the beginning¡­. (mid 1990s) Request for a Dynamic Page showing all orders so far¡­ Generate a dynamic html page based on current data and respond with that page. DYNAMIC PAGES (GET)
  • 6. Birth of a star¡­ (1995) Request for a Page Respond with the page along with its corresponding JavaScript which adds behavior to the otherwise extremely boring and inactive page. JavaScript
  • 7. Birth of another star¡­ (1996) Request for a Page Respond with the page along with its corresponding CSS which gives a way to separate structure from presentation. CSS
  • 8. The 3 stars that became super stars¡­ Structure Presentation Behavior
  • 9. Exchange of new information with the server, after a page is loaded, required a page refresh or use of browser plug-ins such as Macromedia Flash, Java Applets, etc. ? Eg: While following a game, the sports page needed a refresh every 30 seconds so that a whole new page was generated by the server with the latest scores. ? Eg: A chat session required a browser plug-in such as Java Applets which allowed the display of new messages on the page. ? Eg: An interactive video game page required a browser plug-in such as Macromedia Flash to allow the page to interact with other users. The Big Limitation¡­
  • 10. Enter the game changer (2005)¡­ Request for latest information behind the scenes without reloading the parent page using just plain JavaScript and no plug-ins. Respond with information requested that can be quickly integrated into the parent page by the browser without reloading.
  • 11. Enter the devilry¡­ Native Apps (2007) Request or send data in the form of XML or JSON while all the screens and their rendering is handled client-side. Respond with the requested data or acknowledge receipt of new data from the client.
  • 12. Too much happening server-side¡­ With the entry of Native Apps web applications now needed to maintain two sets of code on the server-side¡­ 1) One set of code to continue supporting web browsers which required.. 1) rendering of HTML pages with data pulled from the database. 2) acceptance of form data and responding with an acknowledgement page. 2) Another set of code to exchange just data with Native Apps via APIs. Pretty much every major feature that a web application provided had to be made available also in the form of an API.
  • 13. Need for better life¡­ Maintaining two sets of code doing more or less the same thing is always a pain. How can we avoid it? Is it possible to come up with a way where we only need to maintain one or the other? Well¡­ let¡¯s think about it¡­ all we have to do is make the web browser behave like a Native App. How can we do that? Well¡­ we have JavaScript which can render new elements based on data. It can also allow content to be changed within an element in the DOM. And we have AJAX which allows new content to be brought in without reloading the page¡­ So, all we need to do is to combine all these features!
  • 15. A much better life¡­ Request or send data in the form of XML or JSON while all the screens and their rendering is handled client-side. Respond with the requested data or acknowledge receipt of new data from the client.