>Not even to enrich a document, such as syntax-highlight the code snippets. This one may seem too stringent, but I think it’s better to err on the safe side, and it’s very easy to enforce.
If the enrichment rules are known ahead of time, there is no reason you can't just "hard code" the colors or formats into the document.
I think that's what the author was going for. Syntax highlighting and other improvements would be "baked" into the document by the server and the final document would be served to the client. All without the use of client side scripting.
In theory, dynamic syntax highlighting done via Javascript lets you customize it on-the-fly, for example by choosing a syntax highlighting method that suits you. In practice, I've never seen a website with syntax highlighting that does it. So we're getting the worst of both worlds: no ability to tweak and syntax highlighting for the same page repeated millions of times. I find it especially ironic that Rust programming books use Javascript syntax highlighting. Doesn't Rust pride itself with cutting the runtime operations to absolute minimum?
The one and only place where I want dynamic syntax highlighting is on "pages" where content might change, such as in-browser code interpreters. This kind of thing can't be done with static syntax highlighting:
https://play.rust-lang.org/
I appreciate the sentiment, but the prescription is extreme. The technologies mentioned beyond HTML: CSS and JavaScript (yes, even Javascript), can be used to enhance the presentation of the document, and more importantly can do so without altering the document itself (ie the HTML). We need to be encouraging better design and implementation practices, namely graceful decay, and can do so without sacrificing features that improve readability and accessibility, such as syntax highlighting or dark color scheme variants.
Can you give an example where JavaScript would “enhance the presentation of the document”?
You mean like scroll-jacking? Some script that prevents me from copying and pasting? Something that loads images later for some reason and shifts everything around?
I don’t mean to be facetious, I am genuinely curious what you mean. In my experience JS has been nothing but a detriment (for reading documents, that is), and I have it disabled on all of my computers.
MathJax allows pretty good equations to be rendered in LaTeX format, which I like for scientific write-ups. Of course my static site generator could probably prr-process those as images with alt text.
The author's point is that adding some technologies such as JS sound like a good idea because at the beginning they are used reasonably, but they then get abused.
Encouraging better design and graceful decay didn't work, because it was too easy not to care.
If you want good design to be the majority, it must be the path of least resistance.
> CSS and JavaScript (yes, even Javascript), can be used
The key observation, that generalizes to a lot of societal woes: can be used doesn't mean will be used. Asking people for restraint doesn't work in general, and doubly so in a competitive environment. That's why asking for restraint generally never works, you can either take away the toys (a quick fix) or find a way to force restraint on people.
I think the new Web3.0, and blockchains, and IPFS are going to lead to a new web that is more like it was in the old days where people were sharing actual documents.
I'm the creator of 'quantizr.com', which also fully adheres to your sentiments, but also a belief that documents themselves should be granular (i.e. quantized).
The IPFS 'interpretation' of my quantizr concept would be something like saying a 'document' can have a version stored on IPFS that is a specific immutable copy.
Maybe I'm missing something, but I don't understand the authors thesis here. He seems to have a problem with when he navigates somewhere and instead of receiving an expected block of pure text, he gets that along with a whole bunch of tracking/impressions/pay walls.
Sure, I get it, that's a problem, but it's not a _document_ problem. The web of applications let you _actually do stuff_. Yeah sure there's a ton of crap, but cherry picking only the news sites as a reason to remove PUT requests seems like the total wrong approach.
What if we just released a new browser that flat out refused to load any resource outside this definition?
Would sort of be like the parallel worlds of gopher and the web for a while. I think it would be interesting to have a "web fork" that was just for documents not apps.
IPFS and blockchains are the technological solution here.
Many applications are already being developed to create this new Web3.0 document-centric world (I'm creating one of them!) which will provide a "way" to have the original Tim Berners Lee web once again be possible.
...and not only that but it'll also be decentralized and 'uncensorable'!
IPFS is not uncensorable. The protocol is based on a DHT that allows anyone to find what IP addresses are hosting a particular content, so it's possible to take them down.
It only appears uncensorable because it's not (yet?) popular enough for states to care about it.
And for blockchains to be uncensorable, you need the content to be on-chain, which doesn't scale. (because, if the content is off-chain, then you need an external solution to host the content, so the blockchain didn't solve the problem)
You're claiming that if a piece of information has an identity that makes it reachable, then that makes it censorable too, but you left out what would be required to make that censorship happen. The gov't would have to require the IPFS codebase to support a 'blacklist table' of hashes, and then make it illegal for a server to run a codebase without using the 'updated' latest table. The the gov't would have to come up with a mechanism where they maintain and update this blacklist and disseminate it.
Meanwhile, if I want to make a blacklisted doc 'available again' all I'd have to do is add one bit or byte to the end of it, and the hash would change completely.
Right now one single person at one single tech company (like a Twitter employee) can literally ban someone for life, for perfectly legit political speech.
IPFS is the best-in-class effort to solve all that, and I'm actually a guy building a node that will go on the IPFS network.
> You're claiming that if a piece of information has an identity that makes it reachable, then that makes it censorable too, but you left out what would be required to make that censorship happen. The gov't would have to require the IPFS codebase to support a 'blacklist table' of hashes
No, it only has to take down servers hosting its content.
> all I'd have to do is add one bit or byte to the end of it, and the hash would change completely.
This is unrelated to my point, but a nitpick: IPFS uses a rolling/chunking hash, so one could blacklist chunks of a file; so it's not as easy as adding a byte at the end.
1) Regarding the gov't taking down servers publishing hashes it doesn't like, yes that's exactly what I said they'd have to do, if you go back and re-read my prior post. Glad you agree. But like BitTorrent or Bitcoin, they'd have to basically shut off the whole internet to disable it. Not gonna happen.
2) Regarding chunking in IPFS, the fact that files are chunked actually increases the burden on any authority attempting to implement a blacklist of hashes, and so that's in agreement with my points.
Also if someone truly wants to fight censorship you'd just symmetric encrypt the data using a publicly available key so that it DOES change all hashes of ALL chunks every time you encrypt with a different key.
And encrypting the same data under many different keys (creating different copies of whole file, is also my proposed solution to the problem of "Proof of Replication" in the IPFS system.)
Interestingly. I tried this. As expected, some sites work, and some do not.
I can view wiki, yc, and even some news websites. I can search through google, but can't use my account. Of course FB, LinkedIn also doesn't work. And I also can't login to HN and consequently can't leave a comment here.
It rises a question: is it possible to decouple our personalization needs from Web of Application to get properly working and convenient Web of Documents? Or it will be like a huge library of everything?
One problem is that the line of demarcation between "document" and "application" isn't always totally clear cut. I think most of us intuit that something like Gmail is an "application", whereas something like https://people.math.gatech.edu/~cain/textbooks/onlinebooks.h... is a "document". But as soon as you introduce something as trivial as user login, now you need forms, cookies, etc. And Javascript can be used to make "rich documents" (I'm thinking of things like Tangle.js based docs, for example) that blur the line between "document" and "application".
For that matter, where does HN fall on the spectrum? It's not as "application'y" as some sites, but it's certainly not a static document either.
Having seen this argument come up many times on HN, I've come to the conclusion that the line between "document" and "application" on the web is more emotional than technical.
Although the definition in the article would seem to be that "documents" are static, non-interactive (excluding even forms and possibly any kind of server-side rendering), non-scriptable HTML pages which simulate paper documents as much as possible, with perhaps the sole exception of allowing hypertext, and "applications" are everything else.
If so, that seems far more restrictive than even the web in its infancy, at least at the point where most people became aware of it.
Ultimately, there's nothing that says a saner web couldn't exist side-by-side with the modern one. We don't have to fork the browser, we just need to create a subgraph in the larger link network - a connected, searchable subgraph of sites that are document-oriented, machine-readable, that don't track or abuse you. A search engine limited to a certain criteria and perhaps some amount of curation would work as a way to define this subgraph.
No, this won't solve the web problem for everyone, but I think this is too tall a goal to have. Instead of trying to fix everything for the world at large, I feel we should be creating our own better subspace, and slowly let those who care come over.
I think I've suggested before that someone (Mozilla comes to mind) could use this as an opportunity in the same way they did with asm.js, roughly along the lines of:
- specify a strict subset of html and css (no scripts, or maybe a set of well-known scripts for things like autocomplete etc, avoiding layouts that are known to be problematic)
- add a meta tag or something to indicate that the browser should attempt to read this page based on these rules.
- fall back if the page doesn't follow the spec exactly.
I guess this could result in lightening fast pages. Now get one or two organizations on board (Wikipedia? Other non-profits? etc.) and suddenly people will notice.
>add a meta tag or something to indicate that the browser should attempt to read this page based on these rules
This seems kind of like XHTML. No one liked that because people preferred having a webpage fail gracefully and still display something, rather than throw an error (ironically, the "worse" solution of non-strict HTML in that case making the web act more like documents than applications, because sloppily written documents are still readable.)
While I like the idea I feel like it's misplaced. Hand writing documents was acceptable until we got typewriters. Black and white text was acceptable until we built color displays. Paper documents were acceptable until we built word processors. Digital documents were acceptable...until we built the Web of Applications.
I do not see documents and applications as two separate things. I think an application is the inevitable next step towards our goal of disseminating information as efficiently as possible. That's why it's called hypertext - it's meant to be a better version of plain text documents.
The author's biggest complaint is "applications pretending to be documents," such as journalism sites that implement monthly article caps. Sure, but in the old days you had to pay for the newspaper too, didn't you? Paywalls are not a result of the "Web of Applications" as much as they are a corporate attempt to adapt to a new medium. Nobody will publish documents for free unless it is a hobby or passion; in order for there to be worthwhile documents churned out every week or so, someone has to get paid. The author seems to presume that news orgs would simply publish their documents for free if the Web only enabled GET requests. I have extreme doubts about this.
I think Daniel's ideas are very similar to the sentiments of pretty much everyone fed up with Social Media and their censorship and the fact that a few monopoly tech companies control the flow of information nowadays (FANG+Twitter), rather than the original free "web of documents" Tim Berners Lee created.
Web3.0, IPFS, blockchain, etc. are what will end the 'non-document-capable' web that we all seem to now be experiencing.
For example if you go to someone's blog, it's on some site, and if that site goes away, that document is gone forever. That's the problem. We need an internet that is more like a massive public blockchain than a small number of monopoly sites trying to feed you enough stuff to collect information to sell about you.
I think I understand what the author is trying to say.
For me the feeling that you are browsing a "web of documents" is that you know that you are clicking around for information. It is very basic. You look at and read a page with some links. You find something interesting and click on a lick. This produces a deterministic action: another page loads with some links. That's it. It might look slightly different but it doesn't move around when components are loading dynamically, no pop-ups, no red "1" badges that try to grab your attention. It will either load slowly or it will load fast, it won't alternate between the two while loading.
The main focus is the content of the document and the other content it leads to. Not the style, the features, the tech that it uses to load the content. I compare it to books. Most books are the same, predictable. They will have text and some images on pages. When turning a page it will show another page. It wont suddenly ask you to log in or go buy another book in the middle of this one. The covers of the books are slightly different but the basic function is the same. That's it.
it doesn't move around when components are loading dynamically
Images that don't have width and height attributes always did that. Not adding those attributes to an img tag was considered a sign of a poorly made website in the very early 2000s. I think it might have been the origin of the term "layout thrashing".
It is weird, but there is some quite utopian potential within that simplicity. I can really recommend to anybody: try to browse the web for an hour using a command line text-only browser like lynx. This is a totally different experience.
Kind of like when I go for a walk in a forest that I haven't been to. A forest with many possible paths.
Whenever I hit a fork or a junction, I go to the places that seem most interesting. I say to myself: "Oooh it looks like there's a cozy lake over there", or "over there, there's a little river that I can jump over, or play with creating a temporary dam".
If I get lost I can walk back (click the back button) and change my choices, or decide to just walk the same way back/go home (stop reading).
Obvious question that’s been asked a million times: who the hell is gonna pay for this web of “documents”? Producing and distributing “documents” costs money; this web of “documents” is all well and good for hobbyist stuff (and we do still have a subweb of documents of personal websites) but breaks down when people rely on it to put bread on the table.
Not it’s not. I need to pay if I want my files pinned and distributed, not unlike traditional hosting, so the costs of content creation and distribution are still on me. Granted if my content is popular I don’t need to distribute as much. It doesn’t solve the monetization problem at all.
That's right, no single person or organization is going to voluntarily pay for all the storage for all the rest of humanity. No one would suggest that would or should happen, and I'm sure you weren't either.
The question is: How do we equitably allow everyone to pay for their OWN storage in a way that doesn't involve selling ADs or selling people's 'information', the way the current Big Tech monopolies do.
Disk space is ridiculously cheap nowadays. I can buy enough space to store everything you ever typed in your entire life for $10. So I hope IPFS+FileCoin is successful, and you should to!
> How do we equitably allow everyone to pay for their OWN storage...
People create content in order to make money, not to pay for their own storage. However cheap disk space is it's a cost, not revenue (btw, setting aside disk space, bandwidth is nothing but cheap with cloud providers, and nor is business or home bandwidth depending on the definition of cheap). You're shifting the goalpost.
In my opinion 99.99999% of the content on the web are created not with some revenue goal in mind (to sell access to it) but in order to share some information openly like a blog, or collaborate and participate in some social network, etc.
I mean think of it, you've posted 10000s of things onto the web but you've sold NONE of it right?
What I'm advocating for is a way to eliminate the current situation of middle-men in the process (Big Tech firms), because they have a long and proven tack record of manipulating and censoring search results and social media feeds, etc. and banning people for life even.
Not only am I advocating for the Web3.0 (as it's called), I'm helping to build it.
The Web of Documents would eliminate subscription models entirely (unless we resort to HTTP Basic Auth), so that leaves non-personalized advertising as you said. Unfortunately that seems to only work when your content has a specific audience that can be profitably targeted without personalization, plus being notable enough so that advertisers suitable for your audience would notice your site and partner with you. Doesn't work for most ad-supported websites if you ask me.
> but breaks down when people rely on it to put bread on the table.
No, it doesn't. It only breaks down when people use the web as a sole and direct means of making money. I.e. baiting people to view ads.
Any normal company that does business over the Internet uses the web to present their offering and drive purchases. The web part is funded by proceeds from their actual business. This is entirely compatible with the "web of documents".
Regarding distributing such documents, they are cheaper to distribute than applications.
Regarding producing the documents, the author mentions Xanadu as inspiration, and in the linked wikipedia article we find rule 9: "Every document can contain a royalty mechanism at any desired degree of granularity to ensure payment on any portion accessed, including virtual copies ("transclusions") of all or part of the document.". So the idea for a mechanism to allow payments was foreseen. I guess there can also be advertisements, only not personalised.
I love the idea of a web of documents, but I would love it even more if it was a web of documents you could edit collaboratively.
First class support for Google Docs/Sheets/Slides style creation, with a clean default read mode would be perfect. An open web born out of Libreoffice rather than out of Blink/WebKit/Gecko. Secure, federated document access with easy long term caching/archival of static versions.
> This page is a document. Thank you for reading it.
Opens Dev tools, views <head> tags, and "Source" tab looking for javascript
Nothing there. Well done, author. All too often I read articles like this on Medium and laugh at the authors perpetuating the problem they want to solve. I love clean, well styled, beautiful looking static blogs. I'll have to start one someday.
Daniel's sentiments resonate with me. I would add 1 additional restraint:
4. Every document is version controlled
That way, as Daniel puts it, "[the document] will not magically alter its contents tomorrow". Or if it does, I can see a history of what was altered. Ideally, this would somehow be built into the protocol/browser rather than be a burden to the publisher.
Also, maybe after a certain amount of time I can no longer modify my document. If I'm the New York Times, this means when I publish a news article document, and it contains an advertisement, that same advertisement forever lives on that document - just like physical newspaper.
Let's say I'm the NY Times and I host a page on my server at nytimes/2020/01/22/some-article. 1 hour later I realize I got one of the facts wrong, so I modify that hosted page on my server.
I'm not making HTTP requests here, but, to your point, I am mutating the document at that url.
Maybe the protocol would somehow store the diff between those 2 documents somewhere. There could be an organization, similarly structured to ICANN, that stored and surfaced those diffs long term to users.
Interestingly, the page as I just read it does not (no longer, I guess) mention "version control". Probably the author changed their mind towards simplicity. This is funnily, ironically meta.
That said, I agree with the author and discussed the topic with friends for years.
On the "do you practice what you advocate?" side, my freelancer company website is, since day one 8 years ago, a totally static (no script, no cookie... except the one my hosting provider added without letting me options, I will quit them some day) collection of documents with readable stable URLs. https://fidergo.fr/
And the smaller English language https://fidergo.com/
The part detailing dozens of software projects is generated in advance from a structured data store into static pages uploaded to server. https://fidergo.fr/expertise
Version-controlled, scripted deployment.
Safe for me to serve, safe for you to browse and read.
> On the "do you practice what you advocate?" side...
Sure, I do that with my websites too, and I monetize none of them. (I do use cookies because some of my sites require logging in for access control.)
However, you and me can afford to do that because our livelihoods don't depend on revenue directly from page views. There is this subset of the web that is already just a web of documents, because we can afford to keep them this way.
But what about people whose livelihoods do depend on revenue from page views, and page views alone? It's very frustrating when people who can afford to not do X talk about X without even acknowledging people who can't.
If that's what you're interested in discussing, why don't you start your own discussion about that? It's not constructive to arbitrarily require every single comment on X to give a perfunctory acknowledgement to people who can't afford to do X. You're commenting on a website yet don't acknowledge people who can't even afford electricity. Let people talk about what they want, and if you want to talk about something else, you can do that too.
“While I personally adhere to X just like you, do realize that by holding X to be practical in general you have ignored all people who simply cannot do X” is a valid counterargument to “I agree with X and I personally adhere to it.”
I do encourage you to stay on this site longer before you start throwing straw man analogies at other users demanding that they change where and how they would like to comment.
I've been on this site for years with other accounts that I've forgotten the login to. If there is some policy regarding what I'm allowed to do based on the age of my account, please direct me to it.
I am curious how you consider "do realize that [...]" to be an argument, let alone a counterargument.
> Interestingly, the page as I just read it does not (no longer, I guess) mention "version control". Probably the author changed their mind towards simplicity. This is funnily, ironically meta.
Author here. The article has not been edited since it was originally published. I agree that version control is an important topic, and I applaud efforts such as IPFS; it is, however, tangential to the main point of "documents vs applications" that I was trying to make.
Oh, sorry, thanks for correcting. That line from a commenter was actually an additional idea, not from you. I totally agree with you. Bundling a global visitor-visible version-control system would bring the whole idea closer to the never-implemented xanadu project.
The more i think about it the more I would like to see articles and documentation following the same path as project repos,
Articles and documentation need version control and with pull requests and issues you can rely on other people to notice when some stuff is out of date or inaccurate. The version control allows to see what has been changed over the years, it also prevents censoring.
I've been thinking a lot about this. Over the past week or so, I first made my blog browsable with cURL[0], then plain TCP sockets[1]. I learned a lot through this process, and relearned some things as well:
1. HTTP/1.1 is valuable. With the move to HTTP/2, we lost the principle of "simple things should be simple, complex things should be possible" (Alan Kay). All things in HTTP/2 are complex. I can make an HTTP/1.1 client on the command line with netcat.
2. Serving documents is incredibly simple[2] and safe (once you handle path vulnerabilities :D ).
3. We should extract web browsers from the behemoth JavaScript VMs we're all running now. I'm all for having portable VMs, and I like the direction WebAssembly is headed, but probably 80% of what I do on the web could be accomplished using an order of magnitude simpler software, accessing read-only documents.
4. Markdown and other human-readable formats are awesome. I used to think writing my blog in HTML had the least dependencies, but now I realize it makes you depend on a browser to render it, and that's a huge dependency. Markdown can be read as-is and therefore is almost dependency-free.
So I agree with the author here, and this is how I think we get there. Someone should make a stripped down web browser with the following attributes, or something similar:
1. Only speaks HTTPS
2. Only GET requests
3. A few choice headers, like Range for streaming video.
4. No JavaScript, or any Turing complete language at all.
5. Minimal CSS, ie colors, font sizes, flexbox. No animations (you don't have a language to trigger them with anyway).
6. Can probably throw away some HTML elements as well.
The nice thing about this approach is that sites made to work with this browser will still work in normal browsers. They'll just be super fast, low on resources, secure, and private.
Yes, that's actually what I'm trying to convey, is that we shouldn't see 1.1 as something to deprecate. I'm in favor of maintaining that compatibility.
Agreed with the poster on many points. I want a web where I can return to a website at any given time and expect to see the same content that was present before.
I think a version controlled web would be sweet, like git internet.
Publishing a page ultimately creates a commit hash. Removal of published commits is not a thing. Only forward changes. Mess something up? New commit.
When referencing a page from another, a commit hash can be specified if desired, however, linking to a page/accessing a page without a commit hash resolves the most current (think master branch) page/commit hash.
When accessing a page in browser, you should have the ability to rollback to a previous version of a page if so desired. Since all dynamic content and linked-out content is based on commits hashes (resolved at time of publish), you now have a way to receive all content you did before.
I like the idea of a static HTML/CSS only idea for pages and ditching JS mostly due to what crap the web has become filled with, like author mentions, paywalls and tracking.
At the same time, I think all can be accomplished without dynamic scripting as long as pages are hosted privately (as things like server logs can be inspected) and websites are able to set/retrieve session storage on client-side. Not sure how to solve for that.
I always land on the whole thing being decentralized and everyone participating holds many pieces like bittorrent where there is hash authenticity. The hashing to client lookup could be authority type servers (like cert authorities/trusted tor nodes) as trackers. The problem with this is nobody wants to have crap stored on their computer to use the internet.
Private, trusted nodes seem to me to be the better option, but they would need to be locked down like a root certificate authority. No logs either. Just multi-redundant, multi-region, eventually consistent, nodes adhering to some protocol used for passing around (in essence) a huge scalable, partitioned git repo.
Also this might be complete crazy talk, but that's okay. It's a much better dream than a world where the internet has become full of paywalls and tracking.
RSS is a good illustration of the problem. In theory, it can be used to do that. In practice, it isn't because >Read the full article<. RSS used to be a solution for people who liked simple content. But there's no guarantee that you will get the whole article.
I keep seeing (and mostly sharing) sentiments like this, but a couple of things to note:
- Sets of proposed features vary (happens to both lightweight WWW and modernized Gopher proposals). I guess a more viable approach may be a less strict one than composing such a set. For instance, a search engine for such websites was mentioned in another comment here, and I keep thinking about a web directory for that, but perhaps either of those would be more useful if it was able to detect (and filter by) features required by a website, rather than a single flag saying whether it's usable with a particular set of features.
- Occasionally it's suggested (in this case both in the article and in the comments) that browsers only supporting documents would help somehow. Yet there's a bunch of lightweight web browsers (even I wrote a couple), as well as combinations such as FF+noscript+uBO+Stylus, which may be nicer to use, but don't seem to affect the overall situation beyond "please enable JS" and "best viewed in IE6" messages.
I think the way forward is even more powerful and interactive "document". Imagine for example a car manual that also lets you run diagnostics or tweak the HUD. And also third party "web pages" that can do the same thing if you allow them to.
Imagine searching for a baking recepy, then with a click of the button, the "web page" connects to your baking machine and sets the ingredients.
Imagine a document about some math topics, with interactive models that helps you understand the concepts (that actually exist today).
We hit problems of ownership, control and scope here. I want a tool I can use to find a baking recipe and configure my baking machine automatically. I want that tool to be entirely independent of the sites it pulls recipes from, and of the machines it configures. From this point of view, I want the recipe sites to be dumb documents, preferably in machine-readable format. Similarly, I want my baking machine to be a dumb telemetry/configuration endpoint.
In this baking example, there are three pieces of the puzzle. Recipe source, configuration endpoint, and the brain in the middle that uses one to work on the other. I want that brain part to be independent - but you can easily see how the recipe site and the machine vendors would each like to own the brain part exclusively. That's why we can't have nice things on the Internet - nobody can accept their role as a service provider, everyone wants to be a platform, the landowner of their digital sharecrop.
That would be even better. A static document with an URL. Then you "swipe" the URL from your phone/pad to the baking machine, which fetches the URL and reads the marked up recipe. You then confirm the ingredients on the baking machine, and it starts baking
I however want both "apps" and semantic "documents". Launching an app by typing an URL is powerful. And on Android you can now add an web app to the home screen.
We might not want the recipe to have the same capabilities as the "app". Maybe the apps should be closer to the OS, and "documents" opened in a reader app (browser).
One problem with the "semantic web" is that the added markup feel alien and too verbose. It was designed to be used with web page builder apps. But I and many others still prefer to code the HTML manually, with the help of a powerful editor (with autocomplete and macros). "Structured data" gets too hard to read by source.
An idea is to replace the many span and div elements with actual semantic elements.
In another post I ranted that nothing had really changed for "documents" on the web in the last 20 years. We are practically standing still, without any innovation. Probably due to browsers being overly complex and hard to develop. I think the time is ripe for a "document only" web browser, and we can start innovating again!
For example, the enterpise market is still using word documents, some use alternatives like Google docs. But web "documents" would be far more powerful. Instead of e-mailing files, you should just share a URL.
I'm currently working on an Editor for making web documents (but also for making web apps). I've put a lot of thoughts to how enterprise can use my editor to make web documents instead of word files and PDF's. Almost everyone are using the web today, but very few people actually make web "documents".
The author and their sympathizers can easily refrain from using JS and other technologies they don't like in their own sites, and preferentially give attention to such sites. No technology changes are required for that, except that as another commenter noted, it would be helpful to have a search engine that prioritizes such documents.
The problem the author has is not a technology problem, it is that sites restricted to just such documents are not especially popular with most users.
People who wish that interactivity etc had never been added to HTML are misguided. (I'm not sure if the author falls into that category.) HTML competed with other technologies (e.g. Flash, ActiveX, native apps); when authors felt overconstrained by HTML they used those instead. If interactive apps were all Flash and ActiveX and native today, and Web apps didn't exist, would that be a better world? Certainly the Linux desktop would be far less usable.
I sympathize with the author, but who really likes a 100% web of documents? Me and a couple of other nerds. Is that enough to reach critical mass? Vast majority of internet users loves the engaging, interactive, animated web and notifications. It has armies of psychologists working on it to make it addictive, then feed them ads and sell their data. We would be quite alone in a web of documents. A voluntary exile. I would personally like it, but who would finance it?
really beautiful, simple blog layout! the background color should be a tad bit less saturated though, imo. also, that blurring effect is a little too much for my poor eyes. but i love the simplicity of it!
What the article describes is gopherspace, which believe it or not still exists. And believe it or not, is experiencing a resurgence. It's too bad major browsers gave up on gopher:// because as we are seeing now in this and other laments for the old www, we lost something that we didnt have to lose.
Gopherspace--check it out.
The author states that in an ideal "web of documents", we would have (1) only GET requests, (2) no (java)scripts, and (3) no cookies. While I agree with (1) and (3), I disagree completely with (2).
Having Javascript enables amazing things like interactive documents. For example I would consider [1] a document, despite the fact that there is Javascript running. What a wonderful way to interact with and get a better understanding of a Voronoi diagram! Or how about the wonderful interactive demonstrations of graph searches at [2]? To me, things like this are part of what makes the web platform fantastic.
Earlier in the article, the author writes:
"A document is stateless. It exists in and of itself; it is its own microcosm. It may be experienced interactively, but only insofar as it enables the experiencer to focus their attention on the part of their own choosing; the potential state of that interaction is external to the document, not part of itself."
I think that the two interactive javascript-powered articles I linked comply with this. Ruling out scripts entirely is too heavy-handed - perhaps a nice middle ground can be found somewhere.
Such a good post; I really agree with so many of the author's points! The following tidbit in particular is so powerfully true:
> A document is safe. A book is safe: it will not explode in your hands, it will not magically alter its contents tomorrow, and if it happens to be illegal to possess, it will not call the authorities to denounce you. You can implicitly trust a document by virtue of it being one. An application, not so much...
> We don’t have a Web of Documents anymore. These days, the WWW is mostly a Web of Applications.
Yes! It's 'SaaSS' - as defined by Stallman, not 'SaaS'.
"On the Internet, proprietary software isn't the only way to lose your freedom. Service as a Software Substitute, or SaaSS, is another way to give someone else power over your computing.
The basic point is, you can have control over a program someone else wrote (if it's free), but you can never have control over a service someone else runs, so never use a service where in principle a program would do.
SaaSS means using a service implemented by someone else as a substitute for running your copy of a program. The term is ours; articles and ads won't use it, and they won't tell you whether a service is SaaSS. Instead they will probably use the vague and distracting term “cloud”, which lumps SaaSS together with various other practices, some abusive and some ok. With the explanation and examples in this page, you can tell whether a service is SaaSS."
92 comments
[ 3.1 ms ] story [ 147 ms ] threadIf the enrichment rules are known ahead of time, there is no reason you can't just "hard code" the colors or formats into the document.
The one and only place where I want dynamic syntax highlighting is on "pages" where content might change, such as in-browser code interpreters. This kind of thing can't be done with static syntax highlighting: https://play.rust-lang.org/
You mean like scroll-jacking? Some script that prevents me from copying and pasting? Something that loads images later for some reason and shifts everything around?
I don’t mean to be facetious, I am genuinely curious what you mean. In my experience JS has been nothing but a detriment (for reading documents, that is), and I have it disabled on all of my computers.
Encouraging better design and graceful decay didn't work, because it was too easy not to care.
If you want good design to be the majority, it must be the path of least resistance.
The key observation, that generalizes to a lot of societal woes: can be used doesn't mean will be used. Asking people for restraint doesn't work in general, and doubly so in a competitive environment. That's why asking for restraint generally never works, you can either take away the toys (a quick fix) or find a way to force restraint on people.
I think the new Web3.0, and blockchains, and IPFS are going to lead to a new web that is more like it was in the old days where people were sharing actual documents.
I'm the creator of 'quantizr.com', which also fully adheres to your sentiments, but also a belief that documents themselves should be granular (i.e. quantized).
The IPFS 'interpretation' of my quantizr concept would be something like saying a 'document' can have a version stored on IPFS that is a specific immutable copy.
Sure, I get it, that's a problem, but it's not a _document_ problem. The web of applications let you _actually do stuff_. Yeah sure there's a ton of crap, but cherry picking only the news sites as a reason to remove PUT requests seems like the total wrong approach.
What if we just released a new browser that flat out refused to load any resource outside this definition?
Would sort of be like the parallel worlds of gopher and the web for a while. I think it would be interesting to have a "web fork" that was just for documents not apps.
Many applications are already being developed to create this new Web3.0 document-centric world (I'm creating one of them!) which will provide a "way" to have the original Tim Berners Lee web once again be possible.
...and not only that but it'll also be decentralized and 'uncensorable'!
Is it full of insane people blogs and illegal pornography like all the other technologies with these characteristics?
It only appears uncensorable because it's not (yet?) popular enough for states to care about it.
And for blockchains to be uncensorable, you need the content to be on-chain, which doesn't scale. (because, if the content is off-chain, then you need an external solution to host the content, so the blockchain didn't solve the problem)
Meanwhile, if I want to make a blacklisted doc 'available again' all I'd have to do is add one bit or byte to the end of it, and the hash would change completely.
Right now one single person at one single tech company (like a Twitter employee) can literally ban someone for life, for perfectly legit political speech.
IPFS is the best-in-class effort to solve all that, and I'm actually a guy building a node that will go on the IPFS network.
No, it only has to take down servers hosting its content.
> all I'd have to do is add one bit or byte to the end of it, and the hash would change completely.
This is unrelated to my point, but a nitpick: IPFS uses a rolling/chunking hash, so one could blacklist chunks of a file; so it's not as easy as adding a byte at the end.
2) Regarding chunking in IPFS, the fact that files are chunked actually increases the burden on any authority attempting to implement a blacklist of hashes, and so that's in agreement with my points.
Also if someone truly wants to fight censorship you'd just symmetric encrypt the data using a publicly available key so that it DOES change all hashes of ALL chunks every time you encrypt with a different key.
And encrypting the same data under many different keys (creating different copies of whole file, is also my proposed solution to the problem of "Proof of Replication" in the IPFS system.)
I can view wiki, yc, and even some news websites. I can search through google, but can't use my account. Of course FB, LinkedIn also doesn't work. And I also can't login to HN and consequently can't leave a comment here.
It rises a question: is it possible to decouple our personalization needs from Web of Application to get properly working and convenient Web of Documents? Or it will be like a huge library of everything?
For that matter, where does HN fall on the spectrum? It's not as "application'y" as some sites, but it's certainly not a static document either.
Although the definition in the article would seem to be that "documents" are static, non-interactive (excluding even forms and possibly any kind of server-side rendering), non-scriptable HTML pages which simulate paper documents as much as possible, with perhaps the sole exception of allowing hypertext, and "applications" are everything else.
If so, that seems far more restrictive than even the web in its infancy, at least at the point where most people became aware of it.
Ultimately, there's nothing that says a saner web couldn't exist side-by-side with the modern one. We don't have to fork the browser, we just need to create a subgraph in the larger link network - a connected, searchable subgraph of sites that are document-oriented, machine-readable, that don't track or abuse you. A search engine limited to a certain criteria and perhaps some amount of curation would work as a way to define this subgraph.
No, this won't solve the web problem for everyone, but I think this is too tall a goal to have. Instead of trying to fix everything for the world at large, I feel we should be creating our own better subspace, and slowly let those who care come over.
- specify a strict subset of html and css (no scripts, or maybe a set of well-known scripts for things like autocomplete etc, avoiding layouts that are known to be problematic)
- add a meta tag or something to indicate that the browser should attempt to read this page based on these rules.
- fall back if the page doesn't follow the spec exactly.
I guess this could result in lightening fast pages. Now get one or two organizations on board (Wikipedia? Other non-profits? etc.) and suddenly people will notice.
This seems kind of like XHTML. No one liked that because people preferred having a webpage fail gracefully and still display something, rather than throw an error (ironically, the "worse" solution of non-strict HTML in that case making the web act more like documents than applications, because sloppily written documents are still readable.)
I do not see documents and applications as two separate things. I think an application is the inevitable next step towards our goal of disseminating information as efficiently as possible. That's why it's called hypertext - it's meant to be a better version of plain text documents.
The author's biggest complaint is "applications pretending to be documents," such as journalism sites that implement monthly article caps. Sure, but in the old days you had to pay for the newspaper too, didn't you? Paywalls are not a result of the "Web of Applications" as much as they are a corporate attempt to adapt to a new medium. Nobody will publish documents for free unless it is a hobby or passion; in order for there to be worthwhile documents churned out every week or so, someone has to get paid. The author seems to presume that news orgs would simply publish their documents for free if the Web only enabled GET requests. I have extreme doubts about this.
Web3.0, IPFS, blockchain, etc. are what will end the 'non-document-capable' web that we all seem to now be experiencing.
For example if you go to someone's blog, it's on some site, and if that site goes away, that document is gone forever. That's the problem. We need an internet that is more like a massive public blockchain than a small number of monopoly sites trying to feed you enough stuff to collect information to sell about you.
The main focus is the content of the document and the other content it leads to. Not the style, the features, the tech that it uses to load the content. I compare it to books. Most books are the same, predictable. They will have text and some images on pages. When turning a page it will show another page. It wont suddenly ask you to log in or go buy another book in the middle of this one. The covers of the books are slightly different but the basic function is the same. That's it.
Images that don't have width and height attributes always did that. Not adding those attributes to an img tag was considered a sign of a poorly made website in the very early 2000s. I think it might have been the origin of the term "layout thrashing".
Feels like such a step backward
Kind of like when I go for a walk in a forest that I haven't been to. A forest with many possible paths.
Whenever I hit a fork or a junction, I go to the places that seem most interesting. I say to myself: "Oooh it looks like there's a cozy lake over there", or "over there, there's a little river that I can jump over, or play with creating a temporary dam".
If I get lost I can walk back (click the back button) and change my choices, or decide to just walk the same way back/go home (stop reading).
The question is: How do we equitably allow everyone to pay for their OWN storage in a way that doesn't involve selling ADs or selling people's 'information', the way the current Big Tech monopolies do.
Disk space is ridiculously cheap nowadays. I can buy enough space to store everything you ever typed in your entire life for $10. So I hope IPFS+FileCoin is successful, and you should to!
People create content in order to make money, not to pay for their own storage. However cheap disk space is it's a cost, not revenue (btw, setting aside disk space, bandwidth is nothing but cheap with cloud providers, and nor is business or home bandwidth depending on the definition of cheap). You're shifting the goalpost.
I mean think of it, you've posted 10000s of things onto the web but you've sold NONE of it right?
What I'm advocating for is a way to eliminate the current situation of middle-men in the process (Big Tech firms), because they have a long and proven tack record of manipulating and censoring search results and social media feeds, etc. and banning people for life even.
Not only am I advocating for the Web3.0 (as it's called), I'm helping to build it.
Advertisers find general magazines and TV still interesting enough, without any personalization.
No, it doesn't. It only breaks down when people use the web as a sole and direct means of making money. I.e. baiting people to view ads.
Any normal company that does business over the Internet uses the web to present their offering and drive purchases. The web part is funded by proceeds from their actual business. This is entirely compatible with the "web of documents".
Regarding producing the documents, the author mentions Xanadu as inspiration, and in the linked wikipedia article we find rule 9: "Every document can contain a royalty mechanism at any desired degree of granularity to ensure payment on any portion accessed, including virtual copies ("transclusions") of all or part of the document.". So the idea for a mechanism to allow payments was foreseen. I guess there can also be advertisements, only not personalised.
(Edited the Xanadu rule cited)
First class support for Google Docs/Sheets/Slides style creation, with a clean default read mode would be perfect. An open web born out of Libreoffice rather than out of Blink/WebKit/Gecko. Secure, federated document access with easy long term caching/archival of static versions.
Opens Dev tools, views <head> tags, and "Source" tab looking for javascript
Nothing there. Well done, author. All too often I read articles like this on Medium and laugh at the authors perpetuating the problem they want to solve. I love clean, well styled, beautiful looking static blogs. I'll have to start one someday.
4. Every document is version controlled
That way, as Daniel puts it, "[the document] will not magically alter its contents tomorrow". Or if it does, I can see a history of what was altered. Ideally, this would somehow be built into the protocol/browser rather than be a burden to the publisher.
Also, maybe after a certain amount of time I can no longer modify my document. If I'm the New York Times, this means when I publish a news article document, and it contains an advertisement, that same advertisement forever lives on that document - just like physical newspaper.
From the article: > A book is a document, to me
How can versioning work for the above statement? Will there be a new book or we modify the existing book?
I'm not making HTTP requests here, but, to your point, I am mutating the document at that url.
Maybe the protocol would somehow store the diff between those 2 documents somewhere. There could be an organization, similarly structured to ICANN, that stored and surfaced those diffs long term to users.
That said, I agree with the author and discussed the topic with friends for years.
On the "do you practice what you advocate?" side, my freelancer company website is, since day one 8 years ago, a totally static (no script, no cookie... except the one my hosting provider added without letting me options, I will quit them some day) collection of documents with readable stable URLs. https://fidergo.fr/ And the smaller English language https://fidergo.com/
The part detailing dozens of software projects is generated in advance from a structured data store into static pages uploaded to server. https://fidergo.fr/expertise
Version-controlled, scripted deployment.
Safe for me to serve, safe for you to browse and read.
That is the web of documents.
Sure, I do that with my websites too, and I monetize none of them. (I do use cookies because some of my sites require logging in for access control.)
However, you and me can afford to do that because our livelihoods don't depend on revenue directly from page views. There is this subset of the web that is already just a web of documents, because we can afford to keep them this way.
But what about people whose livelihoods do depend on revenue from page views, and page views alone? It's very frustrating when people who can afford to not do X talk about X without even acknowledging people who can't.
I do encourage you to stay on this site longer before you start throwing straw man analogies at other users demanding that they change where and how they would like to comment.
I am curious how you consider "do realize that [...]" to be an argument, let alone a counterargument.
I think you're misreading gp, they want to add version control to the requirements, they're not discussing an earlier version of op that had it.
Author here. The article has not been edited since it was originally published. I agree that version control is an important topic, and I applaud efforts such as IPFS; it is, however, tangential to the main point of "documents vs applications" that I was trying to make.
Articles and documentation need version control and with pull requests and issues you can rely on other people to notice when some stuff is out of date or inaccurate. The version control allows to see what has been changed over the years, it also prevents censoring.
Source Hut (https://sourcehut.org/) does it very well in my opinion
1. HTTP/1.1 is valuable. With the move to HTTP/2, we lost the principle of "simple things should be simple, complex things should be possible" (Alan Kay). All things in HTTP/2 are complex. I can make an HTTP/1.1 client on the command line with netcat.
2. Serving documents is incredibly simple[2] and safe (once you handle path vulnerabilities :D ).
3. We should extract web browsers from the behemoth JavaScript VMs we're all running now. I'm all for having portable VMs, and I like the direction WebAssembly is headed, but probably 80% of what I do on the web could be accomplished using an order of magnitude simpler software, accessing read-only documents.
4. Markdown and other human-readable formats are awesome. I used to think writing my blog in HTML had the least dependencies, but now I realize it makes you depend on a browser to render it, and that's a huge dependency. Markdown can be read as-is and therefore is almost dependency-free.
So I agree with the author here, and this is how I think we get there. Someone should make a stripped down web browser with the following attributes, or something similar:
1. Only speaks HTTPS
2. Only GET requests
3. A few choice headers, like Range for streaming video.
4. No JavaScript, or any Turing complete language at all.
5. Minimal CSS, ie colors, font sizes, flexbox. No animations (you don't have a language to trigger them with anyway).
6. Can probably throw away some HTML elements as well.
The nice thing about this approach is that sites made to work with this browser will still work in normal browsers. They'll just be super fast, low on resources, secure, and private.
[0] https://anderspitman.net/17/#curlable
[1] https://anderspitman.net/19/#netcatable
[2] https://github.com/anderspitman/newb-server-go
Fortunately, we haven't lost anything yet on that front as HTTP 1.1 is still supported by practically all servers and clients.
I think a version controlled web would be sweet, like git internet.
Publishing a page ultimately creates a commit hash. Removal of published commits is not a thing. Only forward changes. Mess something up? New commit.
When referencing a page from another, a commit hash can be specified if desired, however, linking to a page/accessing a page without a commit hash resolves the most current (think master branch) page/commit hash.
When accessing a page in browser, you should have the ability to rollback to a previous version of a page if so desired. Since all dynamic content and linked-out content is based on commits hashes (resolved at time of publish), you now have a way to receive all content you did before.
I like the idea of a static HTML/CSS only idea for pages and ditching JS mostly due to what crap the web has become filled with, like author mentions, paywalls and tracking.
At the same time, I think all can be accomplished without dynamic scripting as long as pages are hosted privately (as things like server logs can be inspected) and websites are able to set/retrieve session storage on client-side. Not sure how to solve for that.
I always land on the whole thing being decentralized and everyone participating holds many pieces like bittorrent where there is hash authenticity. The hashing to client lookup could be authority type servers (like cert authorities/trusted tor nodes) as trackers. The problem with this is nobody wants to have crap stored on their computer to use the internet.
Private, trusted nodes seem to me to be the better option, but they would need to be locked down like a root certificate authority. No logs either. Just multi-redundant, multi-region, eventually consistent, nodes adhering to some protocol used for passing around (in essence) a huge scalable, partitioned git repo.
Also this might be complete crazy talk, but that's okay. It's a much better dream than a world where the internet has become full of paywalls and tracking.
- Sets of proposed features vary (happens to both lightweight WWW and modernized Gopher proposals). I guess a more viable approach may be a less strict one than composing such a set. For instance, a search engine for such websites was mentioned in another comment here, and I keep thinking about a web directory for that, but perhaps either of those would be more useful if it was able to detect (and filter by) features required by a website, rather than a single flag saying whether it's usable with a particular set of features.
- Occasionally it's suggested (in this case both in the article and in the comments) that browsers only supporting documents would help somehow. Yet there's a bunch of lightweight web browsers (even I wrote a couple), as well as combinations such as FF+noscript+uBO+Stylus, which may be nicer to use, but don't seem to affect the overall situation beyond "please enable JS" and "best viewed in IE6" messages.
In this baking example, there are three pieces of the puzzle. Recipe source, configuration endpoint, and the brain in the middle that uses one to work on the other. I want that brain part to be independent - but you can easily see how the recipe site and the machine vendors would each like to own the brain part exclusively. That's why we can't have nice things on the Internet - nobody can accept their role as a service provider, everyone wants to be a platform, the landowner of their digital sharecrop.
I however want both "apps" and semantic "documents". Launching an app by typing an URL is powerful. And on Android you can now add an web app to the home screen.
We might not want the recipe to have the same capabilities as the "app". Maybe the apps should be closer to the OS, and "documents" opened in a reader app (browser).
One problem with the "semantic web" is that the added markup feel alien and too verbose. It was designed to be used with web page builder apps. But I and many others still prefer to code the HTML manually, with the help of a powerful editor (with autocomplete and macros). "Structured data" gets too hard to read by source. An idea is to replace the many span and div elements with actual semantic elements.
In another post I ranted that nothing had really changed for "documents" on the web in the last 20 years. We are practically standing still, without any innovation. Probably due to browsers being overly complex and hard to develop. I think the time is ripe for a "document only" web browser, and we can start innovating again! For example, the enterpise market is still using word documents, some use alternatives like Google docs. But web "documents" would be far more powerful. Instead of e-mailing files, you should just share a URL.
I'm currently working on an Editor for making web documents (but also for making web apps). I've put a lot of thoughts to how enterprise can use my editor to make web documents instead of word files and PDF's. Almost everyone are using the web today, but very few people actually make web "documents".
The problem the author has is not a technology problem, it is that sites restricted to just such documents are not especially popular with most users.
People who wish that interactivity etc had never been added to HTML are misguided. (I'm not sure if the author falls into that category.) HTML competed with other technologies (e.g. Flash, ActiveX, native apps); when authors felt overconstrained by HTML they used those instead. If interactive apps were all Flash and ActiveX and native today, and Web apps didn't exist, would that be a better world? Certainly the Linux desktop would be far less usable.
Us. All of us. All hail mesh networks.
I’m not much of a designer so I just reused a color scheme I liked that I found on ColourLovers.
https://gopher.floodgap.com/gopher/gw
And a search engine:
https://gopher.floodgap.com/gopher/gw?=gopher.floodgap.com+7...
Having Javascript enables amazing things like interactive documents. For example I would consider [1] a document, despite the fact that there is Javascript running. What a wonderful way to interact with and get a better understanding of a Voronoi diagram! Or how about the wonderful interactive demonstrations of graph searches at [2]? To me, things like this are part of what makes the web platform fantastic.
Earlier in the article, the author writes:
"A document is stateless. It exists in and of itself; it is its own microcosm. It may be experienced interactively, but only insofar as it enables the experiencer to focus their attention on the part of their own choosing; the potential state of that interaction is external to the document, not part of itself."
I think that the two interactive javascript-powered articles I linked comply with this. Ruling out scripts entirely is too heavy-handed - perhaps a nice middle ground can be found somewhere.
[1]: https://strongriley.github.io/d3/ex/voronoi.html
[2]: https://www.redblobgames.com/pathfinding/a-star/introduction...
> A document is safe. A book is safe: it will not explode in your hands, it will not magically alter its contents tomorrow, and if it happens to be illegal to possess, it will not call the authorities to denounce you. You can implicitly trust a document by virtue of it being one. An application, not so much...
Yes! It's 'SaaSS' - as defined by Stallman, not 'SaaS'.
"On the Internet, proprietary software isn't the only way to lose your freedom. Service as a Software Substitute, or SaaSS, is another way to give someone else power over your computing.
The basic point is, you can have control over a program someone else wrote (if it's free), but you can never have control over a service someone else runs, so never use a service where in principle a program would do.
SaaSS means using a service implemented by someone else as a substitute for running your copy of a program. The term is ours; articles and ads won't use it, and they won't tell you whether a service is SaaSS. Instead they will probably use the vague and distracting term “cloud”, which lumps SaaSS together with various other practices, some abusive and some ok. With the explanation and examples in this page, you can tell whether a service is SaaSS."
Source: https://www.gnu.org/philosophy/who-does-that-server-really-s...