I'm all for p2p (really), but how about taking back control (sorry) of the Web by actually developing and enforcing declarative/markup technologies and standards instead of praising JavaScript because "it's not half bad" and adding procedural features to the Web (APIs, WASM)? With the current state of affairs wrt privacy and self-proclaimed standardization bodies, I'm not sure the Web is worth preserving.
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 connections or modify form data, isn't useful enough without that to justify the added bloat to the client.
God, it'd feel lightning fast compared to what we have now. And it wouldn't be able to spy on you. A document-centric (once again) web that's somewhat less crippled than Gopher would be amazing, but we absolutely must cut out things like scripting in order to make the client trustworthy (and fast).
> it'd feel lightning fast compared to what we have now
I disagree with this completely. So much of what JS does is increase the (perceived) speed and sanity of the user experience. For example, in a scriptless world, your HN up/down vote can't be done without a full page load, which would come with the added headache of changing the state of the world on your page because stories and comments have changed their ordering. Solution? Return of the chronological thread (no thanks).
And there are a lot of other applications in this same boat. I don't know if you are old enough to remember webmail when the refresh button was how you checked for new mail. I'd greatly prefer what we have now, where mail just appears over a socket. Online drawing/CAD apps or games without CSS and JS? Forget it. Or go back to Flash.
Bottom line, we have the ecosystem we do today because the users demand it. For us as devs, it could be better, more consistent, etc. but we need the capability.
> For example, in a scriptless world, your HN up/down vote can't be done without a full page load
You're incorrect. The up/down vote can be a form POST, which receives a 204 No Content in response. The only thing one would lose would be the change in the vote arrow.
Even that could be achieved in a world in which HTML allows PUTs: PUT to the page URL the specific bytes required to select an arrow, and return a 204 No Content or 206 Partial Content. In the first case the browser would know exactly which bytes to update, because it PUT them; in the second it'd know exactly which bytes to update, because the server sent them.
The case of reloading only parts of a page (while retaining boilerplate and other already-received content) could trivially be solved if HTML could make use of entities (a concept from SGML on which HTML is based) in combination with HTTP cache controls. But once Netscape brought us JavaScript, any effort in this direction was doomed because it wasn't essential in an already Turing-complete scripting environmemt. As recently as earlier this year, HTML Imports were removed from the spec I believe (not entirely sure about this).
> I disagree with this completely. So much of what JS does is increase the (perceived) speed and sanity of the user experience. For example, in a scriptless world, your HN up/down vote can't be done without a full page load, which would come with the added headache of changing the state of the world on your page because stories and comments have changed their ordering. Solution? Return of the chronological thread (no thanks).
Counterpoint: when JS/Ajax-free versions of sites are available, they're usually faster in practice. Gmail, Google Calendar. Tried them in their low- to no-AJAX versions lately? I use basic HTML gmail because I got friggin' sick of how slow AJAXy gmail and Inbox were on my stupid-fast MacBook. For the specific case of upvotes on HN, IIRC this would be solvable with the appropriate 2xx response (I forget which), signaling success but not triggering a page load, without requiring any modification to current web clients. Obviously this hypothetical user-focused web successor would be well served by more flexible linking options (more method support, mostly) and built-in form capabilities—which happen to be things the current web really ought to have too, for that matter—but I don't think HTTP itself would need to change.
IMO email and chat with notifications and such belong in their own programs, if you want stuff like live notifications instead of a static page. I'd rather bloat and code that can communicate with the outside world when I haven't specifically told it to not be included with my document browser, because it makes every operation on said browser slower, (way) less safe, and less predictable.
Or hey, how about RSS/Atom for new mail notifications?
> I don't know if you are old enough to remember webmail when the refresh button was how you checked for new mail.
I was on the web well before Gmail existed, so yes, I remember the bad old days of webmail before AJAX. Most of the improvements we've seen in it would be served about as well by smarter, better client-provided form elements, and some other, smaller modifications to the client side, save update pushes. I don't think what we've gained from mixing traditional web stuff with the huge set of things a page might now do to/for you with Javascript and CSS has been even close worth the cost in trust, security, privacy, and predicability. Quarantine that stuff somewhere else, plzkthx.
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 about 5% of that to patch in better form elements and such, 3) write some default styles that don't suck and a system for editing them or loading themes, maybe even per-site (nice, but not needed in the MVP), including user-submitted styles, and 4) overcoming the chicken/egg problem of getting content on it to attract users, or vice/versa (there's the tricky bit).
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.
> For example, in a scriptless world, your HN up/down vote can't be done without a full page load, which would come with the added headache of changing the state of the world on your page because stories and comments have changed their ordering. Solution? Return of the chronological thread (no thanks).
I don't see why it would have to change the state of the world on your page. Sites like HN in a scriptless client world would still be programmatically generated on the server, and presumably could still keep track of state via cookies or via adding parameters to links when they generate the page.
Up/down vote could reload the same view you had before voting, with only the effects of your vote added.
Why does it need to reload? Why not just have the votey button hyperlink to a dummy fragment URI like "#upvote_comment_1234", and something like a ping attribute [1] to send a request in the background, and a CSS rule like
Sorry, but I wouldn't like to lose the ability to build fully custom solutions. I don't want to rely on defaults. One person's sensible default is another's insane one. JavaScript is what it is today because it serves a purpose and frankly, I think it does it well enough for now. And without CSS we'll end up with Beige boxed web, all looking the same, behaving the same, and stuck in someone's idea of a sensible default.
> And without CSS we'll end up with Beige boxed web, all looking the same, behaving the same, and stuck in someone's idea of a sensible default.
That'd be amazing. I wouldn't have to manually kill awful anti-user elements on half the pages I visit, learn how some special snowflake interface works yet again, and so on. I'd know exactly when server communication was going to happen. I could set custom user styles to whatever I like, or, probably, select from the most popular user-submitted ones on some settings screen.
Write applications if you want that stuff. It's not like the current Web would go away, if you wanted to write exceptionally bad applications in e.g. Electron or write "web apps". I'd just like a program I can open to browse a document-centric web that I know won't spy on me, or use stupid amounts of resources to show me some text while hijacking scrolling, or show me popup ads, or auto-play video, make me adjust zoom levels per-page for the best reading experience, or any of that stuff that makes the Web worse and that we cannot get rid of without ditching (or crippling) Javascript and CSS. An enormous percentage of the Web would be vastly better under such a system, and most of the rest would be better as a real, native application.
Isn't it simpler to enforce-by-convention good ethical practices when developing web apps and sites? The slowness is many times not caused by the site but by the underlying extras underneath - useless and badly done ad tracking, overdose of adverts, video ads, sound - those can go. Good design however, sells. People who'd prefer beigebox internet are a minority. If they weren't the net would be different.
Of course not, but if you want to be an app, be an app. There's huge value for consumers in standardization, that was something people liked about paper encyclopaedias back in the day: a huge amount of information presented in a consistent format that's easy to navigate. By comparison, the web is a drugstore magazine rack with minimal functionality wrapped up in eye candy.
Way back in the early days of the web (said the old man) you also had control over how stuff presented int eh browser, you could customize fonts etc. to read stuff in a way that was comfortable for YOU. I absolutely hate everything being defined at the server end; large parts of the Settings page in my browser don't actually mean anything because nobody uses standardized html any more, and so client-side user interface development has stalled badly. I swear desktop Linux looked better 15 years ago than it does now because people took theming more seriously.
You can still have design, custom design even. But it would be so nice to retain the ability to just see the content without all that (IMO) unnecessary "design" rubbish.
Reader View in Firefox is somewhat a step in this direction, but I find it removes images and some other important content.
What are you saying? That non-power-users like and are good at deciphering different designs and interaction models and layouts for every site, but they can't deal with regular, plain, bland sites because those are scary and confusing?
If anything, shouldn't that be the other way around? Power users wanting javascript experiments, and non-power-users wanting "if it ain't broke, stop messing around with it"?
No, not scary and confusing. Users (meaning non-power-users, generally) aren't always stupid. (In fact, given how well they can break our stuff, I'd say they're often smarter. But I digress...)
What I'm saying is while we might be comfortable looking at plain HTML with #000 text on a #FFF background, a user isn't going to enjoy it very much.
While we might use ctrl+f to hop around a page, a user will probably prefer a search bar with instant results that doesn't cause them to lose their place on the page.
Consider: my mother (not picking on her!) definitely notices when websites run slowly. She hates it. (I got my lack of patience from her :-) However, I'm confident she would trade "slightly slow" Facebook for "have to refresh the page after each action" Facebook.
I'd like to see a return to semantic markup, accompanied by pragmatic information about the purpose of the data and its intended size. The data should also be strongly typed. Then leave it to the client how to display, how to edit, and how to select the data.
The receiver should decide how to best display e.g. a list of 20000 names or a choice between 4 options on his device.
Me too, except I would say strongly duck typed. As in there should be sensible defaults when possible.
In any case, the designers won this argument a long time ago. They want to decide how you consume their page, it is not a document to them, it is a work of art. How dare you want to display it differently from their vision.
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.
> 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.
Everything but web apps and spy-vertising would be better (for the user) without Javascript, overall. I submit that those can live on some other platform (the current Web could keep going) while most of the rest could switch to the low-footprint client that cannot spy on you or do user-hostile crap with its interface (popups, hilariously bad layouts/styling [see: Medium] that "look cool", and so on). Keeping low-trust scumbag code strictly separate from safe sites that don't try to screw with me because they cannot would be very useful.
Ecommerce, Facebook, webmail, all that stuff would be fine without Javascript, if anyone cared to do that on this hypothetical Web alternative that treats the user with respect. Tried basic-HTML Gmail lately? It's faster, with its full-page loads on every interaction, than Ajax gmail and way faster than Inbox, and many of the most useful features it lacks from those could be added server-side with no more, or even less, difficulty than adding them client side (Inbox's categories, for example). Its worse layout issues, especially on mobile, would disappear entirely if we had sensible defaults (user overridable) for each platform's browser to which pages were forced to defer.
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 web page without Javascript I'd have laughed at how implausible that was, so that's a long-overdue change anyway.
> 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?
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 imagine websites without simple upvote/downvote mechanisms but that's what you're asking us to do. And that's just one tiny feature that barely scratches the surface of what is possible.
We had working voting systems before AJAX (source: I have a high-but-now-considered-lowish Slashdot ID) so we can do it. Besides, visited link state seems like it'd resolve the problem, and it's been in HTML approximately forever.
I still don't see the problem. The rest of what's possible can go on the current web, which would hopefully optimize (even more) for delivering apps if that happened. I want a content reader that won't, in practice, often run malicious code when I point it at the wrong document. That means it must not be able to run scripts, or at least not scripts that can communicate with the outside world in any way, at which point you may as well save the disk, memory, and complexity by leaving scripting out. There's no reason the thing I browse Craigslist, Wikipedia, IMDB, and Facebook and Twitter for that matter on must also be able to run ports of Wolfenstein or Excel clones or whatever. Or chat clients. The loss of trust and predictability in ordinary web browsing that scripting and complex layout systems bring aren't worth it. Put them somewhere else (including right where they are now—that'd be fine. Move the web to something more suited to it and leave the apps on the current "web")
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 plugins installed to do just that) but limiting usability and creativity is the wrong approach. It's been done and it always fails.
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 to a page that's a god-awful pain in the ass to read and burns your battery up ("modern" designed web articles). Like a not-shit version of Google's AMP, kinda.
It'd be better separate if that worked out—if all the things that work just fine without JS and advanced CSS went to the New Web I'd be able to arrange things so I rarely need anything else. Web apps blow and I try to avoid them when possible, or, increasingly, they're better off in Electron for reasons including that it's quicker to get to them to murder them mercilessly when they go rogue, than it is with some tab somewhere. But a unified client for both that kept them strictly separate would at least be a lot better than what we have now.
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.
There is no rule in HTTP that mandates the user-agent must navigate away from what it's currently displaying to show you the payload of an HTTP error. It simply says [1] that the error "SHOULD" (in the RFC 2219 meaning of SHOULD [2]) be displayed to the user. Because of this, most browsers display the payload, but some show a built-in "friendly" error page if the payload is under a certain size.
Because of the language in the spec, the server can't rely on any particular behavior. If it reliably knew that user-agents always display the payload, the body of the 4xx or 5xx response could contain the exact HTML of the page you were just on, with the details of the error spliced in. Understandably, few people do this.
In late 1990s, early 2000s browsers, a status bar was commonplace which tended to show parsing errors, script errors, and other errors the user probably couldn't fix; nowadays these notifications have been moved to the console or log and are hidden from non-power users. A HTML form property could be used to signify that the form be submitted out-of-band, and have the results logged instead of updating the document view. With HTML5, they introduced the 'async' tag to allow linked assets to load without blocking rendering, so conceivably the same mechanism could be used to mark forms, if any user-agent were interested in supporting it.
The point is, extremely minor changes could improve usability in this particular case, using semantics that aren't breaking new ground at all, but quite simply no one has done it.
None of this is necessary if you have JavaScript to control the error handling exactly the way you want. If it's a critical problem, you can display an error message. You can retry behind the scenes and succeed without even having to inform the user of a failure.
Again, I make the point that a pure declarative solution only works if you know every possible use-case. You can add all kinds of new tags and attributes that could possibly exist to solve the one problem you imagine right now and that still won't be enough.
Completely agree. Declarative approaches define the palette of available options ahead of time, but if wish to do something out-of-scope, it's back to the drawing board. Imperative approaches instead give you a low-level computation environment, and hooks into manipulating the outside world.
Most facets of the original Web are declarative: HTTP is a complex state machine, HTML is a declarative language, hyperlinks are declarative ways of specifying outgoing edges of a node in a graph. Javascript enhanced that with imperativeness, which is why it's been leveraged to extend the Web in new ways -- ways that are ad-hoc reimplementations of behaviors that have not (yet) been otherwise codified.
> 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.
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.
A lot of the smaller blogs and personal sites I follow use CSS and Javascript in quite unique ways that give them the freedom to express themselves. I think this is a huge use case that your view misses out on in a people-centric web.
I agree that articles would be a lot easier to read if everyone followed a consistent style. And sure the internet would be a safer and faster place without javascript. But you can't just throw it all out the window.
It sounds like what you want is some sort of simple web, with nothing more than HTML and some decent default styling. Wouldn't a web based on markdown or latex be awesome?
The vision of these three posts (tannhaeuser, ashark and JohnStrange) are incompatible. This thread is a tiny (but complete) clinic in why the web is such a mess.
I submit that Tannhaeuser's vision is what can replace the current web in its cross-platform-app-distribution role, leaving the document-browsing side to mine :-)
That addresses the core problem, as I see it, which is that when I want to browse some damn HTML I'm subjected to a ton of actual user-hostile behavior and lots more potential hostile behavior that I have to worry about, all while paying for it in disk space, memory, and processor cycles (so, paying in terms of battery and UX). Mixing the two is why the Web sucks so very much. Separating them into a document-browsing client and a sandboxed-app client is precisely what I wish would happen. I don't want a link in my document-browsing client to maybe open an application without telling me, nor for it to have access to all that capability when I just want to read Wikipedia or whatever, and trust that the links I follow won't lead to some "page" that spies on my every mouse movement, mines Bitcoin, auto-plays video ads, pops up "SUBSCRIBE TO MY NEWSLETTER" modals, or any crap like that.
I'm pessimistic about strict semantic markup/typing of data being viable as a web replacement, as in JohnStrange's suggestion.
So under that model, would Wikipedia, which uses javascript, be in the sandboxed-app client, and would you would be perfectly happy viewing it with javascript on, in that case?
I'm curious which sites you actually frequent which wouldn't count as "apps," but which still use javascript, and which would actually run in the static-only client you seem to prefer?
My own personal vainglorious idea about the opportunity missed with the web is much more radical yet.
Semantic markup (remember, TBL originally designed HTML this way) failed already once for a reason. Markup language was a bad choice to begin with.
Instead of an SGML-derived markup, we should have had a set of primitive s-expressions that were supported in a standard allowing people to extend the behavior of browsers by implementing renderers based on any kind of s-expression. Wanna extend your browser? Just implement a renderer. Wanna distribute a renderer? Fine; the interface of renderers are part of the standard. You can distribute the renderer along with your page.
There would never have been JS to begin with: that gets handled right out of the box with s-expressions.
