3 ms·
I thought this was gonna be about how we've been tying data or documents in native mobile apps to their program of origin, making the use of several apps on a s
by cwizou 5y ago
I thought this was gonna be about how we've been tying data or documents in native mobile apps to their program of origin, making the use of several apps on a same document very complicated (or importing data from other apps). iOS went all hog on this and it's been a pain for "pro" workflows.
Instead it's complaining about bad JavaScript usage and needless "apps" for "personal websites", which by the definition of the author are just documents to be shared. I love badmouthing SPAs and needless JS like anyone else, but what if I want a bit of interactivity such as comments? Am I not allowed to do that on my personal website by the author's definition?
I think most importantly it misses the point that the web never was about defining documents. HTML was about linking pages and resources together. And even early on, CGI was a thing, and interactivity quickly became the "killer app", starting with search.
I mean, Mosaic added forms in 1993. [1]
[1] : https://www.w3.org/People/Raggett/book4/ch02.html https://www.w3.org/People/Raggett/book4/ch02.html
- emaro 5y ago> I love badmouthing SPAs and needless JS like anyone else, but what if I want a bit of interactivity such as comments? Am I not allowed to do that on my personal website by the author's definition? OP addresses this point well in my opinion: > If your page includes a few non-essential scripts to do different things on the page, that isn't a problem. The document itself is still readable in a wide variety of programs and formats, regardless of support for those scripts. If your post is still readable without JS, no one complains if the comments don't work. And no one complains, if you implement comments using JS. The problem is, if the core content is actually a document, but behaves like an app (and you cannot access simple text because you disabled JS).
- cwizou 5y agoThat's a very fair point, I guess I skipped over that part, my bad. My core issue was around this and I should have sticked to it : > The original purpose of the Web was to be a set of protocols and formats used for the purpose of publishing documents. I still think this is a bad argument, I disagree that HTML was conceived as a way to make "documents", but it shouldn't matter, things evolve on their own and people may use your creation in ways you disagree with. > The problem is, if the core content is actually a document, but behaves like an app (and you cannot access simple text because you disabled JS). I 100% agree with you, but the distinction is the "core content" part. Part of the page is that core content, and what we actually want to see/read indeed (and why various web browser brought a "reader mode" that extracts that part). But the page itself is not a document that only contains this core content, and hasn't been for a couple of decades. Most blogs/publication, even personal ones have been backed by a publishing system with the core content in a database. At this point these are applications, and many of these system can still output "pages" that 100% fit the description of being easily readable without JS, while still adding a lot of utility. Hence my disagreement around the "Documents ≠ Programs". That's the distinction I was trying to make.
- azernik 5y agoThe author is also not against using HTML/JS for things they were not initially intended for: > It can be very useful to run certain programs in the browser. In a lot of cases, however, the same technologies are used for documents. And yes, often the HTML is generated from a database. That's fine. "Document" does not equal "file on disk". The HTTP/HTML model just talks about the entities that actually hit the wire. If what you're delivering to the browser isn't a document, but rather a program running in the browser to build a document, you should be taking a deep breath and checking whether you actually need to do that.