Hacker News Reader

Comment by 127001brewer | Hacker News Reader

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

View on HN

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".

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

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.

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.

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.

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.

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)?

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?

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

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-m...

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.

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.

Tomayto Tomahto

Both great with a little salt.

Reply on news.ycombinator.com