This means that every vote results in a
response that's usually around 10KB gzipped
Just moving the mouse towards the like button created 824KB of data transfer. Not sure if it is because of tracking the mouse movement or if it preloads stuff it thinks my mouse is moving towards. Or maybe it loads stuff that it would display if I held the mouse over something longer. No idea. But it loaded 824KB without me interacting with anything. Just because I moved the mouse.
The actual click on the like button added 30KB on top of that.
With JS, they could send a completely empty HTTP 200 response and it would work exactly the same (it does nothing with the response anyway). Right now HN is probably sending multiple gigabytes worth of responses to voting every day that are all just thrown away.
That's their point. You're not wrong, you can always be better, but HN is barebones compared to almost all (using the mathematical definition...alright, facetiously using it) other sites.
I appreciate your generosity to him but I am sad to see that is the top comment.
There are multiple downsides and not a single benefit to the current method.
And if you are not authenticated, you are instead taken to a login page. Logging in then gives you the redirect and the upvote is registered.
But it'd be a quick performance win if it didn't do that when you were logged in with JavaScript enabled. The actual JavaScript part of this is actually already implemented -- that's why the page doesn't refresh when you upvote my comment -- so you'd just need one if-statement on the server side to send a blank response instead of a redirect.
Sure, 10 KB of download and the server CPU time needed to re-generate the listing page is probably pretty negligible, but multiply that by the number of votes casted on Hacker News every day and it starts to add up.
If someone loads this thread right now, the initial page load is 61KB (gzipped). If they read down the thread and vote on 30 comments while they're doing it, they transfer an additional 480KB (16KB/vote [1]). There's no reason that they should be receiving 8x more data by voting on a relatively low number of comments (~10% of the thread) than they did when loading the entire page originally. It also has to re-generate the page an extra 30 times unnecessarily - a repeatedly voting user becomes like a heavy multiplier to your traffic.
[1]: Also, I just noticed that the responses back from voting actually aren't the full page, they're truncated. It seems like maybe the response size is capped at 16KB gzipped? That implies that there's already some kind of special handling for the voting responses.
Taking data from 2.5 years ago[0], HN has ~300k daily uniques. Assuming 10% of that are users, each upvoting one story, that's 30k unnecessary page renders per day. That's ~2% of the total views (though the more expensive views - AFAIK when you're logged out, you get cached pages?), so on the one hand it's not much, but on the other hand the fix should be trivial and have minimal impact on code readability.
--
It will work with any possible browser under any reasonably foreseeable condition with no maintenance on the part of the HN crew.
> I bet that they'd see a significant drop in resource usage solely by not generating entire comments pages just to throw them away every time anyone votes on a comment.
If there is a serious performance problem they will presumably do some analysis and make changes related to the most serious bottleneck.
> There are multiple downsides
There are multiple irrelevant hypotheticals. If anyone cares about the heavy-weight HN, I hope they don't accidentally click the link to the article and discover the wider internet with images and whatnot.
Facebook is a very different site, and could be lazy loading anything, and do you know the mouse move was causal? was there a window.setTimeout initiating it?. Facebook is not a site i'd expect to use on a low bandwidth connection, or if I did I'd use a low bandwidth version if possible (like Gmail has a HTML only version).
No need for an app or anything.
I’ve been using mbasic on my phone since I read about it here in HN (Thanks HN !), it’s perfect and less intrusive.
A better responsive CSS file wouldn't make the site any slower or degrade the experience for laptop users.
I got so used to pinch-to-zooming, for so many years, I guess I didn't even consider that usability flaw.
(It could use some tweaks to keep everything aligned, but the small usability tweak was most important to me.)
I really wish I could do one feature on the desktop/web that mobile MiniHack.app does on mobile - to enforce all links opened launch in reader mode in Safari webview. 99% of the time that's exactly what I want when I click through.
The bookmarklet:
javascript:(function()%7Bvar%20n=window.document.createElement(%22style%22);n.setAttribute(%22type%22,%22text/css%22);n.innerText=%22html%7Bfont-size:1.2em!important;line-height:1.3!important;%7Dbody,table,tr,td,.default,.comment,.comhead,.pagetop,span.pagetop%20b,.c00,.yclinks%7Bfont-size:inherit!important;line-height:inherit!important;%7D.pagetop,.title%7Bfont-size:1.2em!important;%7Dtable%23hnmain%7Bwidth:100%25!important;%7Dbody%7Bmargin:0;%7D%22;window.document.head.appendChild(n)%7D)()It should take conscious effort to vote, and the small target size mentally reinforces this model; that it's not supposed to be the most common action.
EDIT: See, clearly the vote targets simply aren't small enough! </s>
Aside: I have noticed Safari auto-inceases the touch zone for inputs and elements with ontouch/onclick events (I noticed because I had to fix an issue caused by this!)
This increases area by padding the link. Just don’t want the rap areas of different elements to overlap with too much padding.
You can also put a border around the new area, or a box shadow, to indicate larger click area, making it a button sort of:
{border: thin solid grey}
This does put the discussion in a different light (not to mention helps avoids me making comments that don't apply to more karmarific users).
CSS `px` units are not equivalent to a device pixel.
The reality is that for the bulk of users, votes are an uncommon interaction; most of us are here to read the articles and view the comments. The additional complexity needed to make votes small has an upfront cost, and in this case, I feel the simplicity of the base interface is the better thing to optimize for, and HN's designers appear to agree. 10 kB for what is effectively a server-side page reload (which probably gracefully degrades for folks running NoScript) seems fine.
What a pleasantly tiny script file. More site code should be this easy to read.
(if *ajax-request*
(upvote)
(upvote-and-generate-page))No one is contesting that HN can work without JS. But for those who have JS enabled, it uses JS. For these people the optimisation could be implemented.
For example, adding a story to favourites shouldn't redirect it back to the main page
At the same time there were a couple of minor improvements "recently", like the undo feature for votes which were a bit of high-impact low hanging fruit.
Apart from that I'm just happy I can customize the level of orangeness on the top bar to a lighter shade
Other than that I like the minimalism. I even think the lack of automatically quoting the parent comment is a good thing, as it forces the user to think about the part of the parent they want to quote instead of wholesale quoting it all as the lazy option. If auto-quoting existed the comments would be 40% quotes of each other, and much harder to read.
But apparently there's people who dislike wrapping code so much, that it's worth messing up the layout of a whole discussion even if only one comment has code in it (or by accident, even). Personally, I dislike horizontal scrolling much stronger (and I actually mildly prefer wrapping code, but that's taste, the horizontal scrolling is a big annoyance).
Exactly
You typically see users working this around with spacing, and (sometimes) other users complaining (rightfully) that they can't see the full text on mobile without scrolling.
This is exacerbated by the fact that then HN rendering only has the "<p>" concept, not the "<br>". If one works this around using the greater than symbol, and there are several entries, it blends too much with user-typed text.
It's not a very big deal, but it's pretty much standard feature in forum engines, and the lack of it makes the text outlook unnecessarily worse.
But it doesn't turn green.
However when JS and AJAX is used, it's expected that it also avoids an entire full-page HTML response that goes unused. It can easily be a 204 instead.
As for the rendering engine, a iframe tag per comment is nothing compared to the pile of JS that's normally there on other sites.
On the client, iframe tags are entirely separate browser windows and can use up considerable resources. It's like opening up hundreds of tabs and is far more intensive than running some javascript code which is quickly parsed, compiled and cached in modern JS engines.
It's not any lighter, it's just not reloading the page.
These are my network requests when I vote with JS enabled.
The page reloads and re-renders with the UI changes (up-down buttons hidden and unvote link added). However, the reload takes noticeable time, and you lose your scroll location, which is disorienting.
With JS enabled, the UI changes happen instantly, and the scroll position doesn't change. The page still reloads, but the reload is directed into a new Image object which is immediately garbage, so it's off the UI timeline. But it's inexplicable bandwidth waste, nonetheless!
You can't do much with the response without JS but a single upvote doesn't change anything on the page so there's no need for the reload.
Not much, but it does hide the arrows and shows an undo link on the comment.
No, X-Requested-With is a non-standard header set by frameworks like jQuery. But it’s trivial to set something like that with either XHR or fetch.
It also (partially) removes the requirement for live-pages on an active post here.
People seem to assume every aspect of this forum has some brilliant, purposefully elegant rationale behind it, but the truth is PG designed the language (and the forum) to be experimented with and iterated upon, and likely didn't intend the forum to be considered "finished." This software isn't a masters' thesis, it's a proof of concept for a web application in Arc lisp.
Unfortunately, a cargo cult mentality has kind of grown up around this forum and every aspect of it is treated as sacred and not to be touched because "there must be a reason for it." The reason is probably that PG didn't care enough to iterate on the first working solution he came up with.
Mandatory min of 5MB vs. current 10KB?
I'm pretty sure I'm missing the logic here. I sometimes rely on a satellite connection in my access, and I don't hold HN responsible for that fact.
I do agree that no anger is merited (nor sane).
For heavy users of the site, sure. For someone who has stopped by for the first time, well, good luck with customer acquisition is all I can say.
It really does seem this is exactly how modern web app redesigns are done.
Per HN guidelines, 'don't talk shit you wouldn't say in person.' There is so much ridiculous rhetoric on HN these days, satire is difficult to discern.
Edit: Re-reading the original comment in its entirety, rather than focusing on numbers, I guess it's obvious satire. I naively assumed that's not the convention on HN.
Wait, what?
>open-source link aggregator with no ads or tracking (currently in invite-only alpha)
HN is over 12 years old and much larger. Suggesting an alpha-level service is the "gold standard" is pure hyperbole.
I'm not familiar with the founder, so I am not making any judgement; and, I support the basic premise of their project.
Tildes's design has a lot more to it, including better responsiveness for mobile use, a built-in theme system with multiple themes (including dark ones), full markdown (CommonMark/"GitHub Flavored Markdown") support, syntax highlighting for code, etc. There are lots of aspects of it that would be nice to have on HN.
As of right now, for me, voting on any comment in this thread currently causes a 14KB response and takes about 1.3 seconds to finish.