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).
The receiver should decide how to best display e.g. a list of 20000 names or a choice between 4 options on his device.
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.
I wonder where this would fail!
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.
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.
But something as simple as voting on reddit would be tedious.
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.
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'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.
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.
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.
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.
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.
[1] https://tools.ietf.org/html/rfc7231#section-6.5 [2] https://tools.ietf.org/html/rfc2119
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.
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.
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?
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.
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.
Designers generally vastly overestimate how much users actually want "design".
Sure, _we_ like it because it can be great for "power users" like _us_, but 99% of the population aren't power users.
It reminds me of devs wondering why many people prefer bloated, slow GUIs to CLIs.
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"?
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.
Reader View in Firefox is somewhat a step in this direction, but I find it removes images and some other important content.
Yes, please!
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 know, like for e-mail, or newsgroups, and so on.
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.
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.
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).
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.
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.
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.
a.votey:visited { visibility:hidden; }
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#...
They weren't the ones creating Ajax to try to fit Outlook into the browser, and everything that came after that.
...but they certainly know it when they see it.
In a perfect world, HN wouldn't need any web thing at all, NNTP is better fit for it. With all the features of decent newsreader of your taste.
Gopher is cool. I bet if Gopher made it easier to link to other documents it would have really taken off.
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?
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.
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?
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.