Live data from Hacker News

A plan to rescue the Web from the Internet

staltz.com

131–140 of 220 posts

Re: A plan to rescue the Web from the Internet

#131
post #117

Earlier quoted context omitted.

I have a site that delivers content, forums, and maybe even a few application-like features all in one. Why have two systems when one system can do all that? It'll simply never happen. The web killed gopher. The web killed NNTP. The web has almost killed email. What you described has existed and been killed off a half-dozen times already. I'm not against having more user-protection features (heck, I have a number of…

I'd be OK with keeping both in the same client, with warnings when transitioning from one to the other (say, you follow a link on a web page to a web app), if that's what it took. It'd be like the HTTPS lock and content-origin policies and such but for guaranteeing the page you're visiting isn't actually a "page" that's spying on you and doing all kinds of other nasty stuff, or that the link you're following may go t…

Everything you describe is a usability nightmare including "with warnings when transitioning from one to the other". You might not use any web applications but major web applications are the most used sites on the web.

Would it not be better to provide full functionality and simply use better sandboxing to avoid spying and nasty stuff? Reducing functionality is like throwing the baby out with the bathwater -- you really want better privacy and more control but rather than attack that problem you want to take the web back 20 years. That's a solution but it's not a very good one.

I personally don't think that browsers shouldn't leak all the information that they do -- that should be a hole to be plugged.

Re: A plan to rescue the Web from the Internet

#132
post #8

Earlier quoted context omitted.

HTML with great default styles and better built-in form and interactive elements (date picker, sortable tables) would be ideal. Screw CSS, it slows everything down, just have good defaults and don't let pages mess with them much. If we must have CSS at least jettison the complex parts with animation and such. Make it very, very simple and weak. No Javascript. Can't be trusted if it has the ability to initiate connect…

I would love it if the internet worked like this, but I don't see how we could ever get there from where we are now. Too much is invested in the status quo and people are too used to it. Gopher is cool. I bet if Gopher made it easier to link to other documents it would have really taken off.

Well TFA has portrayed p2p as the way to go. Relying on classic HTML and/or other markup will help in cross-media publishing to get there. Presence of much more interesting content on p2p will take people there.

Re: A plan to rescue the Web from the Internet

#133
post #53

Here’s the problem with IP addresses: there aren’t enough of them.... As a consequence, the Internet has allowed intermediate computers to rule. These are like parasites that have grown too large to remove without killing the host. The technical flaw that favored intermediate computers prefigured a world where middlemen business models thrive. The handwave is the word "prefigure". How did IPv4 and NAT play any role i…

If they did not add value, we would still be using newsgroups.

I wish we were. Newsgroups were great, but they fell apart under commercial pressure; internally from spam, externally from the pretty graphics that were possible in a web browser. I really wish there were a clear successor to NNTP and a simpler, clearer markup standard - the popularity of FB and Wikipedia shows that people value simple, uncluttered interfaces almost to a fault.

Re: A plan to rescue the Web from the Internet

#134
post #10

The reason the Web needs rescuing is because it's not a particularly well-designed system that has been patched over and over again for the last quarter century. And now it has been degraded to a delivery layer for JavaScript apps, a poor RPC protocol and an overly complex UI rendering toolkit. It should have had protocol-level technologies for preserving historic data, for search, for offline use, for authoring and…

> It should have had protocol-level technologies for preserving historic data, for search, for offline use, for authoring and publishing. [...] He was talking about the lack of protocol-level solutions for resilience of the Web.

That's completely at odds with what Kay actually advocates for. His position is strongly aligned with the "mechanism, not policy" philosophy. That is, what he advocates for is less of what you want, not more. This is apparent from that Dr Dobbs interview, his work with VPRI, back to his OOPSLA speech in 1997. To wit:

> HTML on the Internet has gone back to the dark ages, because it presupposes that there should be a browser that should understand its formats. [...] You don't need a browser if you followed what this staff sergeant in the Air Force knew how to do in 1961. Just read it in, it should travel with all the things that it needs, and you don't need anything more complex than something like X Windows.

Kay has always sat on the diametrically opposite site of the table as those favoring the Principle of Least Power—one of the most underappreciated tenets of computing. Tim Berners-Lee called it out in Axioms of Web Architecture:

> At the other end of the scale is the weather information portrayed by the cunning Java applet. While this might allow a very cool user interface, it cannot be analyzed at all. The search engine finding the page will have no idea of what the data is or what it is about. The only way to find out what a Java applet means is to set it running in front of a person.

You can get a better view of what a world that more closely adhered to Kay's vision would look like in Stanislav's (an adherent's) post, "No Formats, No Wars": http://www.loper-os.org/?p=309

Re: A plan to rescue the Web from the Internet

#135

Earlier quoted context omitted.

And this is important because the author misses the point as to why people get value from the "middlemen" -- to find stuff. Even with a content-centered web, there will be a need to find content and people, and new discovery engines and aggregators will emerge.

I was struck with the same thing. There is a reason we moved from newsgroups, to HTML and browsers to search engines. Each step became a better, more powerful tool to find content faster, more efficiently. These days so many of the tools we're using are so entrenched, even with some of the changes the author talks about, it would still be a monumental task for people to change. I mean, look at how bad FB is (on sever…

I've been trying to explain this for years here. People don't care that much about privacy because they can't see it and it's hard for them to conceptualize the scope of what they're giving up. It's a selling point, but not that great of a selling point - certainly not good enough to overcome the network effect.

I forget who pointed it out, but I like the point that to disrupt a big incumbent you need to be not just 10% better, you need to be 50% better. You can get started by doing something that nobody else does which is useful. What FB did better than anyone else was provide a clean interface to social network curation that made it far more useful to the initial population than the alternatives that existed at the time.

Re: A plan to rescue the Web from the Internet

#136
post #8

Earlier quoted context omitted.

HTML with great default styles and better built-in form and interactive elements (date picker, sortable tables) would be ideal. Screw CSS, it slows everything down, just have good defaults and don't let pages mess with them much. If we must have CSS at least jettison the complex parts with animation and such. Make it very, very simple and weak. No Javascript. Can't be trusted if it has the ability to initiate connect…

The problem with that approach is that you have to define all your possible use-cases up front. If the web had stayed as a simple document format, it wouldn't even be worth talking about now. A much more flexible and future-proof approach is a fully programmable environment without any declarative features at all. No HTML. No CSS. Just a clean API in a tight sandbox.

> If the web had stayed as a simple document format, it wouldn't even be worth talking about.

Maybe in the sense that we're conditioned to always look for the "next thing". But HTML is also used for legal documents, in education, for cultural heritage, etc. Basically, for most written and published information created by mankind today. A role too important to leave it to very few monopolies.

Re: A plan to rescue the Web from the Internet

#137
post #96

Earlier quoted context omitted.

See discussion in this thread about the "204 No Content" response code. Not all successful HTTP requests trigger a page load. And that's without having to change anything about current HTTP/HTML—except maybe giving hyperlinks and/or forms access to more HTTP methods, though for god's sake we ought to already have that in HTML and if you'd told me in 2007 that in 2017 we still wouldn't be able to PUT or DELETE on a we…

You'd have way no indicate that your upvote succeeded with a 204 status code. Going back to my original point, and what you're arguing for me here, is that do this properly you'd have to imagine and implement every possible use case. In 1993, nobody envisioned web pages like Reddit. And yes, without JavaScript the web would be much faster and much safer but also much less interesting and powerful. It's hard to imagin…

> You'd have way no indicate that your upvote succeeded

Sure you do. 204 No Content for success, 4xx for an error that you (or your browser) can fix, and 5xx for an error that only the server can fix.

Re: A plan to rescue the Web from the Internet

#138
post #48
post #10

The reason the Web needs rescuing is because it's not a particularly well-designed system that has been patched over and over again for the last quarter century. And now it has been degraded to a delivery layer for JavaScript apps, a poor RPC protocol and an overly complex UI rendering toolkit. It should have had protocol-level technologies for preserving historic data, for search, for offline use, for authoring and…

> protocol-level technologies for preserving historic data, for search, for offline use, for authoring and publishing It does [1][2][3]. It's not the most elegant, it's not without flaws, but it's there, and enough to build against. Proprietary services weren't bound by having to code against a standard, so they cranked out something quick (and mutually incompatible), skinned an attractive interface, offered it for f…

Saying that WebDAV lost to Facebook is a bit like saying HTTP POST and DELETE actions lost to Facebook.

I was thinking of publishing and versioning of a different kind. For example, right now the only way to see how some website looked 10 years ago is to go to webarchive.org. 5% of all links on the web get broken every year. Isn't that something worth solving more systematically? In this respect content-addressable Web is a very interesting idea.

Re: A plan to rescue the Web from the Internet

#139
post #96

Earlier quoted context omitted.

Every upvote would refresh the whole page.

See discussion in this thread about the "204 No Content" response code. Not all successful HTTP requests trigger a page load. And that's without having to change anything about current HTTP/HTML—except maybe giving hyperlinks and/or forms access to more HTTP methods, though for god's sake we ought to already have that in HTML and if you'd told me in 2007 that in 2017 we still wouldn't be able to PUT or DELETE on a we…

> See discussion in this thread about the "204 No Content" response code.

HTTP is not the problem, the problem is knowing how to update the rendered page once the upvote happened (which, sure, could be communicated to the browser by a 204.) JS is what does that now; what does that without JS?

Re: A plan to rescue the Web from the Internet

#140
post #115

Earlier quoted context omitted.

I think you're quite right. Browsers would need to add quite a few capabilities in order to support the world you envision, but those capabilities would be simpler and less generic than javascript support.

HTML built-in elements—especially forms and tables—have atrophied badly, I guess because the Javascript crutch is right there. That's gotta be why things like the file picker are still awful, there's nothing like native UI date/time pickers that any sane native UI kit includes, tables don't have (re)sorting built in, and so on. So the work would be, 1) delete like 80-85% of Gecko or Servo or whatever, 2) add back abo…

For 4), what if you started with clean versions of Wikipedia and things that could be built from public datasets? That would be enough content to provide a meaningful comparison experience, and if you had good content creation tools the smart set could migrate over to HyperNet or whatever this brave new world is called, originate content there, and dump it to the web as a secondary option, recruiting people through the blogosphere.

I would absolutely be up for running something like this in parallel to my existing browsers. Right now I have Chrome and Firefox going, migrating things slowly over to Brave, and Tor about half the time. Plus desktop RSS readers and other stuff. I'd love to have some clean virtual space to work in. One more open window wouldn't be a problem.

Post reply on HN