4 ms·
> 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
by unit91 9y ago
> 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.
- ashark 9y ago> 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.
- NoGravitas 9y agoI 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.
- ashark 9y agoHTML 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).
- anigbrowl 9y agoFor 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.
- deleted 9y ago[deleted]
- zeveb 9y ago> 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.
- tzs 9y ago> 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.
- rev_bird 9y agoThat's true, but it would still need to reload, rather than just sending the little request in the background as you keep scrolling along.
- mrec 9y agoWhy 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 a.votey:visited { visibility:hidden; } to hide the button once you've clicked it? [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#attr-ping https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#...
- rev_bird 9y agoI honestly didn't know about "PING," thank you. I have no idea how I missed such a fundamental feature, even if it is relatively new.
- pjmlp 9y agoUsers don't have any idea what they want. They weren't the ones creating Ajax to try to fit Outlook into the browser, and everything that came after that.
- brokenmachine 9y ago> Users don't have any idea what they want. ...but they certainly know it when they see it.
- tannhaeuser 9y agoThe 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).
- snaky 9y ago> in a scriptless world, your HN up/down vote can't be done without a full page load 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.
- brokenmachine 9y agoHow does one upvote comments using NNTP?
- snaky 9y agoIn a perfect world, there's your very own scoring rules (adaptive and AI-assisted, why not) instead of groupthink-enforcing tools like upvotes.