Accessible from Web, Gemini and Gopher.
This is a category error. "Web" does not mean "HTTP(S)"; "Gopher" and "Gemini" are in fact part of the Web (subspaces).
A Web browser that exclusively browses Gopher- and/or Geminispace is still a Web browser (the same as a Web browser that exclusively supports HTTP(S) and eschews Gopher and Gemini and e.g. FTP).
It's written in web assembly; they are on the cutting edge of implementing desktop-style software in the browser. Of course that breaks the HTML-webpage-as-document model.
It doesn't naturally follow that by using WebAssembly, the ordinary WHATWG/W3C hypertext model will be broken.
The fact that these written-in-WebAssembly apps render to canvas is the problem here. If they were spitting out HTML (or the spiritual equivalent of draw calls/system calls that manipulat the document object model), then there would be no problem. Again, canvas is the problem.
defeats the purpose
Does it defeat the purpose, or is it a form of redundancy?
The problem with this page is that the author is playing fast and loose with the words "parser" and "parsing". It's also not totally honest (or is yet again confused) about e.g. what the IETF RFCs say about parsing high precision numbers.
It is however not being done as an open source project & there are other options out there if that's something you need your software to be. It does rely on open source libraries & a number of modified plug-ins for which their changes are being provided to comply with their code licensing requirements. Ultimately I don't want to spend the time to run a properly done open source project when there's no guarantee of any assistance vs the overhead involved & my time management isn't great so spending more time on project management isn't imho a good use of my time.
judgment
"settlement"?
every layer of the modern computing landscape has been built upon the assumption that users are passive recipients rather than active co-creators. What we need instead are computing systems that invite every user to gradually become a creator.
Is "creator" the right word here? There's lots of software that falls outside of what is the subject of this paper that enables creators. Indeed, it has been a common refrain in criticisms of the FOSS movement that for the types of software that creatives need and/or simply desire to use the proprietary apps tend to have no equals.
Software does not need dusting, waxing, or cleaning. It often does have faults that do need attention, but this is not maintenance, but repair. Repair is fixing something that has been broken by tinkering with it, or something that has been broken all along. Conversely, as the environment around software changes, energy must be expended to keep it current. This is not maintenance; holding steady to prevent decline.
Browser-based interfaces are slow, clumsy, and require you to be online just to use them
Nope (re: offline). You're confusing "browser-based" and "Web-based" (sort of the way people confuse statically typed" versus strongly typed*). They're different. You can have a fully offline browser-based interface. Most common browsers are every bit as amenable as being used as simple document viewers as Preview.app or Microsoft Word is. The browser's native file format is just a different sort—not DOCX, and not PDF (although lots of browsers can do PDF, too; you can't write apps in PDF, though—at least not in the subset supported by typical browsers). Instead of Office macros written in VBA, browsers support scripting offline documents in JS just like online documents. You can run your offline programs using the browser runtime, unless they're written to expect otherwise.
Today “REST” and “RESTful architecture” are widely used terms,and sometimes even used appropriately.
the program idea manifests commonly as an OS process
The running program, that is (as just described).
@1:10:20
With HTML you have, broadly speaking, an experience and you have content and CSS and a browser and a server and it all comes together at a particular moment in time, and the end user sitting at a desktop or holding their phone they get to see something. That includes dynamic content, or an ad was served, or whatever it is—it's an experience. PDF on the otherhand is a record. It persists, and I can share it with you. I can deliver it to you [...]
NB: I agree with the distinction being made here, but I disagree that the former description is inherent to HTML. It's not inherent to anything, really, so much as it is emergent—the result of people acting as if they're dealing in live systems when they shouldn't.
note that this will show the historical content within the current template – so not necessarily exactly the same as the original page
not designed to be secure
"secure" is used in this context to mean, roughly, "work with adversarial input"
XBL is a proprietary technology developed by Mozilla
Example of when "proprietary" is not an antonym of "open source".
"Why have a locked wiki when you can instead just post static Web pages?"
What even is a locked wiki insofar as the ways it differs from traditional (pre-wiki) content publishing pipelines? Where's the wiki part of it?
actual programming language
I'm approaching the open source portion of this project strictly as "open source" not "open contribution" similar to the SQLite approach
The trouble with redefining "REST" to mean "not REST" is that the first step in learning known techniques to solve a problem is learning the terminology that people use to explain the techniques. If you think you know the terminology, but you have the wrong definition in your mind, you will not be able to understand the explanations, and you will not be able to figure out why you can't understand them, until you finally figure out that the definition you learned was wrong.
Let's call this style of API pseduoREST or JSON-RPC.
What the re-education around REST needs is a catchy label for what people call REST that works well as a light pejorative. Two-Bit History gave it a shot, coining the ad hoc acronym "FIOH", but it doesn't have the desired properties.
It's a pet peeve, but I wish that people would stop describing their HTTP RPC APIs using the term "REST".
The only solution is probably to advocate for moving away from "REST" entirely—for all parties. Mend the discord by coining two new terms and clearly articulate the two meanings that should be attached to them.
("Indian" is another word like this, but that did not get fully deprecated. This is resulted in lots of confusion. "'Indian'? Like Native Americans?" "No, Indian as in 'from India'" "Oh, all right." A similar thing is happening with "open source".)
This probably involves making the terms (or at least one of them—so long as it's the right one) somewhat cool. Maybe the non-REST term should be AROH (pronounced like "arrow") for "Application RPC Over HTTP".
In mainstream press, the word "hacker" is often used to refer to a malicious security cracker. There is a classic definition of the term "hacker", arising from its first documented uses related to information technologies at MIT, that is at odds with the way the term is usually used by journalists. The inheritors of the technical tradition of the word "hacker" as it was used at MIT sometimes take offense at the sloppy use of the term by journalists and others who are influenced by journalistic inaccuracy.