Talk:Single-page application

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search


Why does this page merely redirect to the page for TiddlyWiki when there used to be a bona fide page explaining what a Single Page application is? Honestly, the old page should be restored, and admins should absolutely disallow it being changed back to a mere redirect.

  • I agree 100%. "Singe Page Application" is a technical term well-established in web development that merrits its own article. I put up an article about it a few years back and it was deleted by the wiki police on the grounds of "no original research". Luckily, sources about SPA on the web have improved over time so quite a few references cab be given now. I will try to integrate my findings in this article. --Thron7 (talk) 11:02, 12 March 2010 (UTC)
    • Have you got any references? Superficially, FORscene might be deemed a single page application, as its interface runs in Java in a single page. But it doesn't meet all the other conditions listed in the article. Also, WP tends to reject neologisms, which could be why it was deleted before. Stephen B Streater (talk)
      • The most important reference for me was not any particular application, but the fact that David Flanagan devotes an entire sub-section in his book to singe-page applications (which I wasn't aware of for years :). I think examples are abundant meanwhile, just think of the JavaScript version of Gmail, but I was hesitant to just throw arbitrary links into the article. That might benefit from better consideration. As for conditions, I don't think that offline capability is a constituting feature (again given Flanagan's use of the term), so I relaxed the old text in this regard (It's an interesting feature nevertheless). Thron7 (talk) 16:41, 12 November 2010 (UTC)

about MVC Backbone[edit]

backbone aims to help organizing and structuring web applications. But, it never claims to be an MVC framework besides the fact that it is really close to. Therefore, I'm wondering about the pertinence of MVC mention about backbone. Ergnouf (talk) 13:35, 13 August 2012 (UTC) sfvaa — Preceding unsigned comment added by (talk) 11:13, 11 June 2013 (UTC)


... and vague - I added these templates for the following reasons:

  • The way traditional web applications work causes disruption in the user experience and workflow. [...] The complete page reload that occurs on each user interaction results in unnecessary re-transmission of data over the wire.
    • There are provisions such as HTTP ETag and Cache-Control which are used by "traditional web applications" and which reduce re-transmission of data.
  • This gives users the ability to download the SPA from a server and run the file from a local storage device, without depending on server connectivity. If such an SPA wants to store and update data, it must be self-modifying.
    • In the normal case of a downloaded page acting on data and not on its own logic, I'd say that this doesn't qualify for "self-modifying" as in "self-modifying code".

--Abdull (talk) 00:25, 3 November 2012 (UTC)

MIT Curl web content language[edit]

Curl from really should be in a See Also as it was intended to be just this and does run either in a browser or on the desktop - but unlike JavaScript, the interpreter never became a standard browser feature.

The original Curl model involved a pennies pay-as-you-use model. There have been recent calls to reconsider even that for some application needs.

The MIT folks working on Curl had the Lisp credentials ; the JavaScript folks included Self and StrongTalk ( i.e. Smalltalk ) credentials ?

Self language inlining strategies and StrongTalk performance both influenced Google's efforts that led to, among others, Node.js on the server.

Unlike Rebol and Icon, Curl string processing is regexp oriented but, unlike Icon and Rebol, and like JavaScript, has always been Unicode-oriented - but code source itself can be in any character encoding page point.

see: rebol3, red programming language, Unicon, Object Icon for related expression-based languages

A Curl process with .xcurl files will also run headless on a web server ( and does so on one of mine alongside Node.js ).

see: Curl_programming_language

G. Robert Shiplett 14:16, 20 June 2013 (UTC)

Shouldn't it be single URL website?[edit]

Shouldn't this be a single URL website? What makes a 'page' anyway? What if there are no pages? or multiple pages in the one view? The article is badly written with pointless statements like "is retrieved with a single page load,[1] or the appropriate resources are dynamically loaded and added to the page as necessary, usually in response to user actions" which of course means it's done however you want to do it... are there any other ways than that? "The most prominent technique currently being used" AJAX is typically used only for server data transmission, it has nothing to do with such websites unless they deal with data on a server - if they are for example totally static, they can still be single page applications. ZhuLien (talk) 00:24, 18 February 2014 (UTC)

SPA's often make use of the fragment identifier (the part of the URL after the hash # symbol), so technically it's not a single URL. But you're right, the definition of "page" is not always clear. Think of it as the main canvas that can be written to and erased from by JavaScript or by the browser. Technically, it corresponds to the "body" or "frameset" tag from the initial HTML document. Even though additional HTML documents can be loaded (through frames or AJAX), in SPA's they will not replace the original document body, their content will only be inserted into the original page.
The text about single page load or dynamically loaded resources is not meant to differentiate SPA's from other types of webpages, but to distinguish the two main types of SPA's. One type is the ones that load all resources on their initial load, the second type is the one that uses AJAX or related technology to "lazy load" additional resources when they are required.
SPA's are often used to communicate to a server, just as normal web pages are. Since they only have one initial page load, all subsequent communication with the server has to be done through techniques like AJAX. However, client-server communication is not a requirement for an SPA, just as it is not for a normal webpage (apart from the page load itself). A very simple JavaScript-based calculator would be an SPA, that has no need to communicate to a server.
--Peter (talk) 14:49, 16 March 2015 (UTC)

Alternate Draft[edit]

I put forward a page in my user space as potentially addressing some of the concerns that have been raised. My work is not a finished work (no citations or examples) but editors may feel free to draw from it in any way to improve this page. Cardiffman (talk) 00:49, 22 May 2014 (UTC)

Need new section?[edit]

In the section Search engine optimization are two paragraphs that don't belong there. The first one begins "One way to increase the amount of code that can be shared between servers and clients". I'm going to create a new section titled "Client/Server partitioning" to contain those two paragraphs. - Dough34 (talk) 14:51, 24 July 2014 (UTC)


I may be misunderstanding, so I wanted to put my thoughts here first before editing the text. The following sentence is too strict in my opinion:

Modern browsers that can parse HTML5 allow developers to shift the user interface (UI) and application logic from web servers to the client.

The original was a bit more nuanced, but I feel it's still off:

Modern browsers and HTML 5 provide power to shift UI and application logic from web servers into browsers hands.

UI rendering on the client has been one of the ground principles of HTML forms since HTML 2.0, and enhanced with CSS in HTML 3.0. Running application logic on the client has been possible since the introduction of JavaScript (creating "Dynamic HTML") in HTML 3.2.

Am I misunderstanding, or is the original writer thinking too advanced? -- Peter (talk) 12:21, 16 March 2015 (UTC)


The jqcomp link in the External Links section looks like advertisement. The website is down and the GitHub page seems to hold less than a hundred commits from a single contributor. I think it should be removed. (talk) 14:02, 11 December 2015 (UTC)

Disadvantage: Requiring JavaScript[edit]

JavaScript is practically a requirement for SPA. Not all devices support JavaScript, and not all users have JavaScript on for all websites by default. It's possible to write an SPA that gracefully falls back to a "paged" application, but this is mentioned only as a small note in the context of SEO. It may affect a relatively small portion of users, but I believe it's worth mentioning. The proportion of JS-disabling visitors can be quite high for certain kinds of businesses, making SPAs inappropriate for such businesses. A related disadvantage is RAM usage, which can be quite high since garbage collection usually doesn't kick in until there are quite a few "dead" pages in RAM. In contrast, the memory is cleared in a timely fashion when loading traditional pages and only the resources needed for that page are loaded. For many mobile devices, that delay in clearing the RAM can produce noticeable lag or even make the site unusable. Eishiya (talk) 16:37, 17 April 2016 (UTC)

Most prominent technique currently[edit]

In the Ajax section, Ajax is said to be "the most prominent technique currently". However, the given source for this is from the year 2006. I don't think that this is still valid today. If anyone has an up-to-date source for what's most prominent today, it should be given. Otherwise, I suggest to simply remove the "most prominent technique currently" phrase. 2A01:CB05:4A1:3E00:D55B:5992:157F:E791 (talk) 14:51, 1 January 2019 (UTC) — Preceding unsigned comment added by 2A01:CB05:4A1:3E00:3803:E18E:B0BB:5041 (talk) 12:26, 1 January 2019 (UTC)

  • Well some things change rapidly in IT but that didn't. Using XHR is still the most common technique for dynamic applications. What would you suggest is more common? --Nux (talk) 20:05, 3 January 2019 (UTC)