Talk:Web application/Archive 3

This is an archive of past discussions about Web application. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Archive 2

Archive 3

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.

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.
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.
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.
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.
The invention of Ajax... Added clarification regarding your point
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.
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."
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:

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)