Talk:Web application

Rewrite

Good job on the rewrite and merging from "browser-based". However, I am a bit concerned about the following sentence:

Because of their architectural similarities to traditional client-server applications, with a somewhat "thick" client, there is some dispute over whether to call systems of this sort "web applications"; an alternative term is "rich internet application".

It would be a good idea to provide a source for this dispute. Flash and Java applets are indeed applications delivered over the web, with code updates made only on the server-side (with the rare exception that a plug-in or JRE needs to be upgraded to a particular version, but this applies to any web applications that may utilize their resources). With no need for traditional client distribution, I don't see how they can be seen differently from a web application. One could compare the web browser to common plug-ins and the JRE (which merely make the thin client a little thicker), as being tantamount to OS fixtures, as they are so ubiquitous.

I am not looking for a back-and-forth argument here and these will be the last words I say on the matter. But I will be looking for a source. Thanks. — Stevie is the man! ^{Talk | Work} 21:43, Jun 18, 2005 (UTC)

That sentence was based on conversations I've had with people who either work or teach in the field, so I don't have any print or web source to cite. Their argument was that a well-designed client-server system can update a thick client transparently over the internet in much the same way as you'd update a cached Java applet (what MS is trying to do with Windows Update), the difference between a browser-executed app and an OS-executed app is arbitrary (see DoJ vs. MS), and some of those "applets" get pretty darn chubby. The disinction's getting blurrier; I was trying to acknowledge that, instead of simply asserting my own position (that a browser-executed Flash app is just as much a web app as anything done with HTML & Javascript). In retrospect, "disgreement" would be better than "dispute", because no one in any of these conversations lost their temper. :) Tverbeek 23:40, 18 Jun 2005 (UTC)

It appears that a potential rewording lies in the words you use to your response here. Clarity is a Good Thing (TM). — Stevie is the man! ^{Talk | Work} 00:15, Jun 19, 2005 (UTC)

wikipedia as example

I would think readers unfamiliar with the subject would find it interesting to be reminded that wikipedia itself is an example of a web app. Is there any reason why it's not mentioned here as a particularly relevant illustration (and in the Application Service Providers article)? ["wiki" is mentioned very briefly in a passing list near the top, but doesn't really make the point with any impact.]

Semi-protected edit request on 1 December 2023

Change "Traditional PC applications consist only of 1 tier, which resides on the client machine, but web applications lend themselves to a multi-tiered approach by nature." to "Traditional PC applications are typically single-tiered, residing solely on the client machine. In contrast, web applications inherently facilitate a multi-tiered architecture." Travis-g-reid (talk) 01:10, 1 December 2023 (UTC)

 Done Lewcm Talk to me! 09:30, 8 December 2023 (UTC)

"Webware" listed at Redirects for discussion

The redirect Webware has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2024 January 26 § Webware until a consensus is reached. Shhhnotsoloud (talk) 12:01, 26 January 2024 (UTC)

Edit request: Add "webware" to the text of the article

Please add to the intro:

Web applications are collectively known as webware.

References

This will support the incoming redirect Webware properly.

-- 65.92.247.66 (talk) 05:19, 17 February 2024 (UTC)

 Not done: for such statement to make it in the lead, we'll need more than a single source from 1997. M.Bitton (talk) 02:26, 18 February 2024 (UTC)

---

Web applications are collectively known as webware.

References

Now with additional references, since you said that 1 reference from a professional journal in computing wasn't sufficient -- 65.92.247.66 (talk) 07:32, 27 February 2024 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{Edit semi-protected}} template. I don't think this is a common enough term that its addition to the lede is uncontroversial. As such, this warrants a consensus discussion, rather than the "Edit Request" template procedure. PianoDan (talk) 23:43, 27 February 2024 (UTC)

Edit request

Please replace the current content of the page with User:Buidhe paid/sandbox2. Reason: expand, add sources, address the issues flagged by the cleanup banners on this article. Buidhe paid (talk) 19:10, 18 March 2024 (UTC)

This is unquestionably a good-faith effort, but I'm concerned it's mostly based on a single source (Hoffman, 2020), which is either incorrectly summarised or makes a number of WP:REDFLAG statements and not an improvement overall.

Compared to downloaded applications, web applications are quicker to deploy and update because they can be accessed via a URL link - this would be correct for client-server applications, but is a very questionable statement for desktop or mobile apps.

Web applications began with the invention of JavaScript in 1995 - this is wrong, for example, Common Gateway Interface was developed in 1993. If this is used in a narrower sense, 1995 is correct, but it's unrelated to JavaScript invention.

Web applications are vulnerable to various types of cyberattacks; defenses against malicious actors are incorporated into many. Web applications can be analyzed using functionality built into many popular web browsers, and third-party analytics are also available. - a largely meaningless summary, as same can be said about any computer software. Apparently it only made it to the lead because of the subject of Hoffman's book, which is tangential to the article scope.

Earlier web applications were developed to make the server generate a page in HTML, JavaScript, and CSS that was sent to the client. - this is plainly wrong, early web applications didn't use JavaScript or CSS.

To update, the client would send another request that was returned via HTTP. - requires copyediting

The invention of Ajax (asynchronous JavaScript and XML) in 1999 enabled network requests to be sent using JavaScript. - this is a wrong statement replacing one that is correct. Requests could've been sent programmatically prior to AJAX, but required reloading the entire page or a frame.

REST is usually preferred to the earlier Simple Object Access Protocol (SOAP) due to better caching and scalability. - unclear what 'better scalability' makes in this context.

JavaScript is the only programming language allowed in client-side software loaded into a web browser. - this is plainly wrong, there's WASM, as well as, historically, Flash, ActiveX, Java and others.

SPAs generate the document object model (DOM) on the webpage, which organizes the XML code that ultimately displays the content to the user - DOM doesn't 'organise XML code' and XML code doesn't 'display the content to the user'.

What it says about web servers and databases, while not strictly incorrect, is outdated by 20 years.

LocalStorage/IndexDB description is completely inadequate.

Single-page applications are dynamically altered - no, they aren't.

Progressive web applications are an innovation that function like a mobile app - I assume this is trying to say they can be added to home screen, but a lot of the nuance is lost as website shortcuts can be added too.

Most web applications are split into client and server domains, and often there are multiple server-side domains. - this is a word salad

Most databases are prone to code injection attacks but these are most common for SQL as it is the most popular format. - this is a false statement, and SQL isn't a 'format' either

many applications run over HTTP, which does not allow saving user data between requests - wrong, HTTP saves user data between requests using cookies (besides other methods available to dynamic web applications)

Because most applications rely on dependencies, which are usually not scrutinized as much as custom-written code, the dependencies or the linkage between them and the in-house code can be the source of vulnerabilities. On the other hand, reinventing code can lead to its own security pitfalls if the new code is not as secure as the alternative. - this is not wrong, but meaningless ('code can be vulnerable regardless of who writes it') and sounds like something GPT would generate

To build a secure application, developers make security a priority during and after the development of the application's functionality. An application is only as secure as its weakest link and needs a secure architecture at all levels of its functionality. Only limited security improvements can be made if the underlying features were not developed with security in mind. Developers will often test the software for vulnerabilities, conducting security audits, vulnerability assessments, and penetration tests (deliberate attempted cyberattack). Testing is followed by rewriting the software to close the identified vulnerabilities. Most security features will have trade-offs, for example increasing the cost of development or reducing the application's usability. - none of this is specific to web applications PaulT2022 (talk) 20:57, 18 March 2024 (UTC)

I don't think it is accurate to describe as based mainly from a single source. A majority of the Hoffmann citations are from the "technologies" section, simply because other sources did not provide an up to date summary of this aspect. You haven't provided any sources for most of your statements. I never claimed to be an expert on this topic but the proposed article is based on reliable sources. In general, we repeat what is said in the reliable sources unless RS disagree among themselves. If you feel that a source is erroneous, please provide another source of comparable or better quality that disagrees.

• Lastly, if you disagree with some of the content, the recommended thing to do would be implement all of the non-disputed content while disputed content is discussed.

1. Compared to downloaded applications, web applications are quicker to deploy and update because they can be accessed via a URL link The source specifically discusses delays with getting applications approved for mobile app stores, as well as barriers to the rapid deployment of desktop applications.
2. Web applications began with the invention of JavaScript in 1995—this claim was not added by me, it was a summary of previously existing text in the history section. I have now researched the question, but cannot find anything other than primary sourced, competing claims of having developed the first web application in different years. Thus, I have rephrased the draft to avoid making a definitive claim.
3. Web applications are vulnerable to various types of cyberattacks... The reason it is in the lead is as a summary of the "security" section, per MOS:LEAD. A very large portion of the reliable sources on this topic focus on security, so it is definitely WP:DUE, even if the principles of security are similar to other types of applications.
4. Earlier web applications were developed to make the server generate a page in HTML, JavaScript, and CSS that was sent to the client. The article says earlier not earliest. The content is supported by the cited source: "A decade ago, most web applications were built using server-side frameworks that rendered an HTML/JS/CSS page that would then be sent to the client. Upon needing an update, the client would simply request another page from the server to be rendered and piped over HTTP" Nevertheless, I have added a clarification about the timeline.
5. The invention of Ajax... Added clarification regarding your point
6. REST is usually preferred ... The cited source does not go into detail about what it means by scalability, so I added information from a new source.
7. That is what the source says: "JavaScript is not only a programming language, but also the sole programming language for client-side scripting in web browsers."
8. If you think that the section on databases needs updating, could you suggest some recent reliable sources that could be cited instead?

I will try to get to the rest of the comments tomorrow. Buidhe paid (talk) 07:35, 19 March 2024 (UTC)

I am of the opinion that Hoffman, 2022 isn't a reliable source for most of the statements it's being used for in the proposed edit. It isn't a widely recognized work, is about the security of web applications rather than web applications in general, and in the proposed edit, it appears to contradict mainstream sources. PaulT2022 (talk) 16:43, 19 March 2024 (UTC)

What "mainstream sources" are you referring to? (t · c) buidhe 16:45, 19 March 2024 (UTC)

I contend that no mainstream source would describe that REST is used instead of SOAP primarily because of 'better caching and scalability'; the new source you've added references this statement to a masters dissertation. There's probably nothing wrong with the dissertation, but it had a very narrow scope: Experiments were done to measure how much time and memory a SOAP and REST clients in PHP take in accessing the web service applications.. There's a difference between measuring performance of protocol clients in a single programming language, and making a conclusion about the considerations that go into choosing a protocol.

If you insist on specific sources, pretty much any book about web development that can be located by searching 'rest soap' in Google Books would describe this differently:

• https://www.google.co.uk/books/edition/The_Definitive_Guide_to_Grails/gIMnCgAAQBAJ?hl=en&gbpv=1&dq=soap+rest&pg=PA449&printsec=frontcover
• https://www.google.co.uk/books/edition/Industry_4_0/YuOODAAAQBAJ?hl=en&gbpv=1&dq=soap+rest&pg=PA149&printsec=frontcover
• https://www.google.co.uk/books/edition/Professional_Development_with_Web_APIs/nWTLjB33bP4C?hl=en&gbpv=1&dq=soap+rest&pg=PA214&printsec=frontcover

Similarly, no mainstream source would say something like SPAs generate the document object model (DOM) on the webpage, which organizes the XML code and other problematic statements I flagged.

My opinion is Hoffman, 2022 isn't reliable for what it's used for per WP:RSCONTEXT (Information provided in passing by an otherwise reliable source that is not related to the principal topics of the publication may not be reliable) and definitely shouldn't be used to support WP:REDFLAG statements not present in plurality of secondary sources on the topic.

I'll leave finishing this discussion to someone uninvolved as I contributed to this article and feel that engaging further may get into WP:OWN territory. PaulT2022 (talk) 03:29, 20 March 2024 (UTC)

Well, after double checking I don't think Hoffman says SPAs generate the document object model (DOM) on the webpage, which organizes the XML code, I believe I misinterpreted it.

I don't have an issue with removing the reference to scalability if many sources on the topic don't mention it, however, I did not find any contradictions to that in the sources you bring up. The main reason I did not cite these sources is that their scope seemed too narrow (one book was specifically about Grails) or I was concerned that they might be out of date (the third reference was published in 2005). Buidhe paid (talk) 03:48, 20 March 2024 (UTC)

Semi-protected edit request on 25 June 2024

Humaira123t (talk) 06:40, 25 June 2024 (UTC)
Open Your Procuring Potential: Demonstrated Web-based Revenue Streams in World  

In the computerized age, the scene of procuring open doors has gone through a groundbreaking shift, particularly for people in Pakistan. The ascent of the web and the gig economy has opened up a universe of opportunities for creating pay without the requirement for critical forthright speculation. Whether you’re hoping to enhance your essential type of revenue or looking for a full-time remote vocation, the web-based domain offers a huge swath of worthwhile choices ready to be investigated.

 Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Charliehdb (talk) 13:17, 25 June 2024 (UTC)

References

Semi-protected edit request on 26 June 2024

Change the link in the word Ajax in "The practice became known as Ajax in 2005." to be for the programming practice instead of the Canadian town in Durham Region. Smeefers (talk) 18:05, 26 June 2024 (UTC)

 Done PianoDan (talk) 18:11, 26 June 2024 (UTC)

Wiki Education assignment: Technical and Professional Writing

This article is currently the subject of a Wiki Education Foundation-supported course assignment, between 21 August 2024 and 5 December 2024. Further details are available on the course page. Student editor(s): Nfarrow93 (article contribs).

— Assignment last updated by Nfarrow93 (talk) 01:14, 21 September 2024 (UTC)

Howdy! I'll be making some edits over the next few days, focusing primarily on structure and organization of sections, as well as looking into linking additional sources as suggested. Most of these edits will be worked on this weekend, and should be finished no later than 10/21/2024. I'll be sure to explain the reasoning for the edits I make, but please reach out if you have any criticisms, suggestions, or anything else that may be relevant. Nfarrow93 (talk) 15:06, 17 October 2024 (UTC)