4 ms·

What exactly is a "single-page application"? Wikipedia states that it "is a web application or web site that fits on a single web page with the goal of providi

What exactly is a "single-page application"? Wikipedia states that it "is a web application or web site that fits on a single web page with the goal of providing a more fluid user experience akin to a desktop application. In an SPA, either all necessary code – HTML, JavaScript, and CSS – is retrieved with a single page load, or the appropriate resources are dynamically loaded and added to the page as necessary, usually in response to user actions." [1] How is this any different from any other web application? [1] http://en.wikipedia.org/wiki/Single-page_application http://en.wikipedia.org/wiki/Single-page_application

elmerland 12y ago
Consider a page like wikipedia. Every time you click on a link to another article a new request is made, the page is loaded along with all its dependencies and resources. A SPA would instead only get the text of the new article and write it in place. Therefore, removing the need to re-download the entire page again. You can also read about this in the blog post by bloomberg: http://www.bloomberg.com/company/2015-03-24/bloomberg-weve-made-brisket-can-make-anything/ http://www.bloomberg.com/company/2015-03-24/bloomberg-weve-m...
- pdwetz 12y ago
  A little misleading since most of the non-article content (e.g. javascript, CSS) is cached locally by your browser. You can also utilize AJAX to have responsive user interactions as needed.
kevincennis 12y ago
I think the main distinction is that there's only one HTML document that ever gets loaded during the course of your usage of the app. In other words, you never have to navigate anywhere else. Or are you making the point that anything that doesn't function this way isn't really a web application?
- 127001brewer 12y ago
  No, what I didn't initially understand is that only one page is loaded (and then reused, etc).
rdtsc 12y ago
They way I think about it is like this: SPA looks more like a mobile app. As you click the links the page doesn't refresh, content just gets replaced dynamically. Traditional web page honors web standards a bit more and looks like the traditional structure of pages linked with hyperlinks. Want to read about the product? Click a link. Want to refresh the current price? Click refresh button.
JustSomeNobody 12y ago
Tomayto Tomahto Both great with a little salt.
lbotos 12y ago
It's different in that before you might have: home.html profile.html group.html and all of those pages are literally different views and you use ajax to grab the data. Now you build: index.html with subviews and essentially index is doing all of it. Picking your subviews, handling making urls, rendering, making the requests. I still haven't found a "class" of app that is "better" with SPAs. Just about anything you would do with an SPA you can do another way. SPAs are just the "cool new thing".
- bduerst 12y ago
  This is a pretty good explanation, and I'd also add that SPAs move away from the traditional server-structure URL path mentality, which wasn't very user friendly and never really needed. Now URLs are kept mostly for sharing or bookmarking. i.e. www.domain.com/user/profile/update.html can just be handled in index.html
  - acjohnson55 12y ago
    By "traditional server-structure URL path mentality", do you mean the mapping of URLs directly to static files on the filesystem? If so, I'd argue that's a separate issue from SPA vs. MPA. After all, most MPA frameworks, like Django and Rails, break that equivalence. URLs map to controllers, rather than particular templates.
    - bduerst 12y ago
      I meant the mentality, which started with URL static file mapping and continued with web routing. Not all URL path routing is bad, but with SPAs you get more focus on what the customer uses URLs for (i.e. URL paths for sharing a picture, etc.) rather than parsing page functionality out across different paths. It's my opinion this URL simplicity makes a better user experience, but that's just my opinion.
- deleted 12y ago
  [deleted]
yebyen 12y ago
Typically when I hear "Single-page application" I think of web apps that perform a dirty trick like starting out logged in making the main content section of the page an empty <div id="content"/> and letting some javascript add the necessary dom elements as information about them comes available through some asynchronous request. Clicks on page elements that represent some user interaction with the app should usually not trigger a whole-page reload, but instead fire some On-Click action resulting in (maybe) some data being sent to the server and (maybe) some new content being added or updated on the screen without changing the URL of the loaded page. The client might long-poll or maintain a websocket so that new information from the server can be received without a user action. These are the types of patterns you don't normally see in "any other web app" that differentiate an "Web 2.0" SPA from "old-school Web 1.0" applications.
- acjohnson55 12y ago
  Push solutions like long-polling and websockets are a separate concern. It's perfectly possible to use those technologies in a web app that's primarily still multi-page, such as a stock ticker on an otherwise static page. I would draw the distinction in navigation. Are links primarily triggering built-in browser navigation (MPA) or are they handled by long-running in-browser code, backed by asynchronous requests for additional server data (SPA)?
acjohnson55 12y ago
Traditionally, web applications used sessions to maintain state while the user navigated the interface, with full page reloads for every screen (typically visible as a blank white page as the next screen loads from scratch). By contrast, single-page application (SPA) architecture holds session state in a long running in-browser Javascript application. This style is particularly strong when user actions only need to modify a portion of the screen.

elmerland 12y ago

Consider a page like wikipedia. Every time you click on a link to another article a new request is made, the page is loaded along with all its dependencies and resources. A SPA would instead only get the text of the new article and write it in place. Therefore, removing the need to re-download the entire page again. You can also read about this in the blog post by bloomberg: http://www.bloomberg.com/company/2015-03-24/bloomberg-weve-made-brisket-can-make-anything/ http://www.bloomberg.com/company/2015-03-24/bloomberg-weve-m...

pdwetz 12y ago
A little misleading since most of the non-article content (e.g. javascript, CSS) is cached locally by your browser. You can also utilize AJAX to have responsive user interactions as needed.

kevincennis 12y ago

I think the main distinction is that there's only one HTML document that ever gets loaded during the course of your usage of the app. In other words, you never have to navigate anywhere else. Or are you making the point that anything that doesn't function this way isn't really a web application?

127001brewer 12y ago
No, what I didn't initially understand is that only one page is loaded (and then reused, etc).

rdtsc 12y ago

They way I think about it is like this: SPA looks more like a mobile app. As you click the links the page doesn't refresh, content just gets replaced dynamically. Traditional web page honors web standards a bit more and looks like the traditional structure of pages linked with hyperlinks. Want to read about the product? Click a link. Want to refresh the current price? Click refresh button.

JustSomeNobody 12y ago

Tomayto Tomahto Both great with a little salt.

lbotos 12y ago

It's different in that before you might have: home.html profile.html group.html and all of those pages are literally different views and you use ajax to grab the data. Now you build: index.html with subviews and essentially index is doing all of it. Picking your subviews, handling making urls, rendering, making the requests. I still haven't found a "class" of app that is "better" with SPAs. Just about anything you would do with an SPA you can do another way. SPAs are just the "cool new thing".

bduerst 12y ago
This is a pretty good explanation, and I'd also add that SPAs move away from the traditional server-structure URL path mentality, which wasn't very user friendly and never really needed. Now URLs are kept mostly for sharing or bookmarking. i.e. www.domain.com/user/profile/update.html can just be handled in index.html
- acjohnson55 12y ago
  By "traditional server-structure URL path mentality", do you mean the mapping of URLs directly to static files on the filesystem? If so, I'd argue that's a separate issue from SPA vs. MPA. After all, most MPA frameworks, like Django and Rails, break that equivalence. URLs map to controllers, rather than particular templates.
  - bduerst 12y ago
    I meant the mentality, which started with URL static file mapping and continued with web routing. Not all URL path routing is bad, but with SPAs you get more focus on what the customer uses URLs for (i.e. URL paths for sharing a picture, etc.) rather than parsing page functionality out across different paths. It's my opinion this URL simplicity makes a better user experience, but that's just my opinion.
deleted 12y ago
[deleted]

yebyen 12y ago

Typically when I hear "Single-page application" I think of web apps that perform a dirty trick like starting out logged in making the main content section of the page an empty <div id="content"/> and letting some javascript add the necessary dom elements as information about them comes available through some asynchronous request. Clicks on page elements that represent some user interaction with the app should usually not trigger a whole-page reload, but instead fire some On-Click action resulting in (maybe) some data being sent to the server and (maybe) some new content being added or updated on the screen without changing the URL of the loaded page. The client might long-poll or maintain a websocket so that new information from the server can be received without a user action. These are the types of patterns you don't normally see in "any other web app" that differentiate an "Web 2.0" SPA from "old-school Web 1.0" applications.

acjohnson55 12y ago
Push solutions like long-polling and websockets are a separate concern. It's perfectly possible to use those technologies in a web app that's primarily still multi-page, such as a stock ticker on an otherwise static page. I would draw the distinction in navigation. Are links primarily triggering built-in browser navigation (MPA) or are they handled by long-running in-browser code, backed by asynchronous requests for additional server data (SPA)?

acjohnson55 12y ago

Traditionally, web applications used sessions to maintain state while the user navigated the interface, with full page reloads for every screen (typically visible as a blank white page as the next screen loads from scratch). By contrast, single-page application (SPA) architecture holds session state in a long running in-browser Javascript application. This style is particularly strong when user actions only need to modify a portion of the screen.