To PG, the mods and whoever else is responsible: thank you for not trying to ‘fix’ what isn’t broken.
+1 for a dark theme though, reading from a bright screen in midnight darkness hurts eyes.
Another frequent thought I have during such trips is why so few sites have any basic offline support? E.g. while writing this I moved to offline zone and if I press 'add comment' now then most likely I will lose it. So I have to copy it and save temporarily in a GMail draft. But it would be nice if all drafts are stored in LocalStorage/IndexedDB as I type until posting is acknowledged.
Actually it is much easier to lose written text on mobile. I've just opened 5 apps that took all Android memory, which kicked Chrome from RAM and forced page reload when I returned to Chrome. The page reloaded from cache instantly, but the comment draft was lost (continuing this from GMail draft, waiting for a stable 4G at the next train station near a mid-size town).
GitHub issues comment form keeps the content if I accidentally click on a link (e.g. Pull Requests) and then return to the issue page (not just by going back, but jumping over several GH pages, e.g. Home->Repo->Issues->#issue) and such behavior is much better than an alert on tab close about unsaved content. Probably in GH case this is an accidental side effect from SPA state storage, but at least once it saved me from losing a large complex comment with links and markdown, that is how I noticed the behavior. GH still loses content on page close, but keeps it after page reload.
reddit.com -> old.reddit.com
facebook.com -> mbasic.facebook.com
cnn.com -> lite.cnn.com
npr.org -> text.npr.org
twitter.com -> twitter.com (with JS disabled)
gmail.com -> gmail.com (HTML version)
gmail used to have an option to set HTML as default, but it seems like it's gone.
Only way to get HTML is to click on a link that's available during loading, nothing in the settings to make it permanent.
It's gone. That's why I'm posting about it.
https://pastebin.com/raw/kHyZXcTY
gi Go to inbox
gk Go to first label inbox
t Toggle checkbox of current mail
mr Mark checked mails as read
mu Mark checked mails as unread
k Navigate up in mail list (shift twice as fast)
j Navigate down in mail list
h Go to older mail(s)
l Go to newer mail(s)
Enter Open mail
r Reload
b Back
n New mailhttps://greasyfork.org/en/scripts/389680-google-mail-gmail-b...
*As for reddit though, if you log in with an account you can set it to always use old reddit in preferences.
There is no "always use old reddit"
Are you saying you have that checkbox you pointed out unchecked, and still get new reddit by default?
I basically never ever want to be there. I've specifically not enabled JS for 'www.reddit.com' so that the site won't load, but I still have to fix URLs manually when directed there.
What I'd like is for any 'www.reddit.com' I encounter on the site to be rewritten to 'old.reddit.com'.
So maybe this is a misfeature on old.reddit.com, or you don't have the box unchecked?
Not sure if you're saying that setting's not working for you or you're just annoyed that it doesn't explicitly link to https://old.reddit.com../blah/..
1: https://www.reddit.com/r/AskHistorians/comments/b7rums/why_d...
I personally wound up using an extension[1] to keep old Reddit active, which so far has taken care of the weird behavior.
[1]: https://addons.mozilla.org/nl/firefox/addon/old-reddit-redir...
[1] https://github.com/eminentspoon/chrome-extension-useragent
I have it set up to handle Reddit and Wikipedia. News sites and Twitter don't get to run JS thanks to NoScript, so I usually don't have to do anything extra to get a lightweight experience there.
Redirect:
*//www.reddit.com/*
to:
$1//old.reddit.com/$2* amp link -> non-amp version of same link
while you're at it, please!
Is there a community or name for this? If not, I'm going to call it #neverscript. I find the web works far better, more often, for me when SPAs and JS aren't used. There's something about minimalistic sites that's very appealing to me. I know it doesn't work for all sites, but a lot of the web could be improved by reducing the frontend bloat.
Boggles my mind how bloated and down right creepy the modern web is today.
A webcomic is a far cry from some main stream site, but it served as a good window into how others abuse their viewers with bloat and surveillance.
Using "vanilla" to describe a standard, unmodified and un-customized version of something is a very common idiom. This satirical website followed the convention, it didn't coin the expression. I don't think it's even jargon, it's just based on the meaning of the adjective "vanilla":
Lacking adornments or special features; basic or ordinary: "a delicious twist to a vanilla plot" (Ian O'Connor).
For "vanilla js," I can still have compilers, type checking, advanced ECMAScript 2019 features, local storage, webgl, etc. Without that understanding, you could qualify something as "vanilla js" in lots of different ways.
If someone said "vanilla c++," they might mean c++ without the recent language features, or they could mean the latest language spec but no standard library. Maybe it's still okay to link OpenGL but not okay to use a desktop GUI framework? Maybe OS frameworks are okay but nothing more? There's no communal understanding there that I'm aware of.
I personally don't think there's a market for non-js users. Most of the web is pretty broken without. I've never encountered someone in the real world who lives this way, even in the tech world. At most, someone will install a no-script browser plugin. That makes whitelisting and enabling javascript dead easy for the user. The only legitimate non-js use cases, IMHO, are for extreme political cases where you'd also be using TOR.
Only useful feature to me that javascript enables is comment hiding.
Edit: All my lovely responders, I appreciate the feedback, but I don't want to install addons/mods/hacks to fix line-height.
It's smart enough to remember the zoom level the next time you open HN too.
We're talking about just 1.5x line height. Which is a perfectly reasonable default for nice reading. The browsers have a lower default line height because of historical reasons, doesn't mean it's the right one. People don't use the Times font very often either.
i recently started keeping dev tools's console open when i am using chrome. i have some JS to collapse comments here on HN.
i have seen some interesting things in the console, i just keep it opened now:
- some sites have st tons of JS errors and yet function as normal
- some companies put job ads in there for JS people (medium is doing it right now)
- some libraries show off their awesome ASCII logos in the console
- debug statements are left there unintentionally (i wonder if there is no tool that could strip these out)
And text has nothing to do with pixels, it's not raster.
I suppose if you have e.g. a 720p screen and do 200% zoom you might run into some problems but that's got little to do with zoom and more to do with the lack of space on your screen to put content anymore.
Lack of space is not really a thing for html, rarely a page fits on screen without scroll and wrap.
For Firefox - no extension needed. Press alt to show the main menu. Go to View -> Zoom - then select Zoom Text only.
Now, zoom will only increase font size, instead of the whole page.
I have, but it's a mark of frustration for me. It definitely falls under the heading of, "The user shouldn't have to do this."
The line-height looks perfectly fine to me. AFAIK the HN CSS doesn't force any specific height but uses the defaults. In fact I'm sick of the "modern" absurdly-low-density design trend that just makes me need to scroll more to see less.
My browser has a zoom function, and so should yours. I don't understand the resistance against customising a site --- it is a user agent working for you, and the CSS spec even mandates a user-stylesheet (which I know some browser(s) blatantly disregard). Different users will obviously have different preferences.
[1]: https://news.ycombinator.com/item?id=10489499 "mobile markup"
[2]: https://news.ycombinator.com/item?id=12073675 "collapse comments"
Literally to post this comment, I got a, "We cannot serve requests that quickly please try again in a moment" message. Completely unnecessary in 2019, given how simple this site (as a concept) is.
"I hate change" <- basically the summary of this submission, and kind of sad.
As for concrete examples of the above, see lobste.rs for an excellent interface that's still minimal and responsive. Typing this comment on HN took me to a separate HTML page for absolutely no reason; Lobsters doesn't do that and allows you to write inline, preserving the context above.
Old Reddit (the only acceptable way to use Reddit) is another example of good JavaScript. Fuck the new redesign, but there are countless subtle and useful features in the old design that are only possible because of a tasteful use of JavaScript.
But that's not modern web development, that's jQuery-style coding. Modern web development is about heavyweight SPA frameworks like React or Angular.
That's a ratelimiting function to stop spammers and such. No one is questioning the ability of the servers to handle much higher request rates.
"I hate change" <- basically the summary of this submission, and kind of sad.
It's "I hate useless change". What's sad about that?
You can but no one manages to do that!
https://2019.jsconf.eu/news/how-we-built-the-fastest-confere...
- limit container width so lines don't get too long
- larger text and more line height
And not really CSS but:
- Making it easier to collapse comments on mobile
I know some of those changes would potentially destroy the look & feel that some seem to enjoy around here. However on mobile currently it's only possible to enjoy HN via a third party app though.
I wish websites were as simple as HN.
+ Lightweight.
+ No ads.
+ Works without (or little to no) JS.
+ Does not make me download MB's of data.
It seems 98% of the websites I visit cannot pass the first two.
The basic shift back to pre-rendering + delivering only what's needed on the actual page is a big deal which hasn't got enough attention yet IMO. We went completely in the other direction for over a decade because we thought networks and browsers could handle it, but it was too easy to abuse and mobile took over.
There's no reason even very advanced websites can't load quickly, without having to fully compromise back to the 90s non-interactive websites.
News sites and marketing teams still ruin it regardless with all the crap they add on top. But it's far far better than loading a giant blob of 20 jquery libraries plus a big old angular.js or backbonejs app (sometimes both at the same time) encompassing a whole site in one file, even though you just wanted to visit the contact page.
I also blame Themeforest type developers because they're still stuck in the "let's add a hundred JS files so I can parallax and animate two divs" mindset.
Getting rid of unused css helps but the additional markup would make the page 4 or 5 times larger.
The Bootstrap stuff you seem bothered by is better for splashy big-headline marketing sites not high-density content like HN.
A lof of web designers cut their teeth designing marketing websites, not app UIs, so it's not surprising when I see it mindlessly used on sites like Reddit's new redesign.
It's really a sad state of affairs when an industry with such a strong historical connection with publishing is now reasonably cited as an industry worse at publishing than most others.
They regularly fail on basic UX. Their ability to turn a kilobyte of text into 10MB of trash is astounding, as is their ability to cripple modern computer hardware, or simply readability, with their latest 'innovations' in totally unnecessary JS/CSS fuckery.
uMatrix blocking all JS, including first party, helps. But you've still got bullshit like floating headers that follow you when you scroll down the article to contend with. I find myself creating cosmetic filters to remove pointless floating clutter on news websites more than any other sort of site. The industry seems utterly incapable of presenting a clean and readable article online.
But regardless of our personal work-arounds or workflows, those websites shouldn't be like that. The general public is still subjected to the default experience and that bothers me.
I don’t understand how online ads are as big a business as they are, other than the troll stuff on Instagram. The rest is pretty unremarkable and ineffective.
I can probably count on my hands they number of times I intentionally engaged with an ad in the last 25 years.
For one, they're on-line, = cheap to make and pretty much free to serve.
Two, with the amount of tracking done, on-line ads are attractive to advertisers because they can evaluate their effectiveness real-time, and often tell what ads are responsible for what real sales.
Three, with all the accrued complexity, it's a wonderland for third parties who help the advertisers navigate through on-line advertising landscape, and divine attribution. Now the trick is, if your customer (the advertiser) doesn't have even basic competence in statistics (they most likely don't), you can bullshit them with data to your heart's content. Which is what you're probably doing if your team doesn't have much statistical competence either. I've seen this happen.
I dont think people have really seen what server-side rendering (ala Next.js/Nuxt.js), decoupled components, modern treeshaking, minification, and chunking can do for performance. We've yet to have a full web framework designed entirely to encompass this from day one but they're coming and getting better at it.
Outside of the endless 3rd party crap the 'business' guys add, if anything, it's no longer the JS framework size and library cruft I'm worried about it's how many object watchers I've got at runtime via Vue.js and reactive style programming (which automatically adds Object.observe style watchers to all data) + component initializers (which can add overhead to simple HTML templates). Fortunately with the new Vue 3 function API there is a clear distinction between observed values vs static/immutable/config data. The amount of observers per page dropped dramatically. Otherwise looking at a Vue project in the performance tab shows it's highly async and efficient.
The new Vue functional API (allegedly) is also going to be far easier to treeshake so you really only ever get the library features you're using. Even for something like Lodash or Ramda where you might use only 10% of the functions it's a big deal.
I'm sure React is making similar progress in this direction and it was already smaller than Vue.
CSS Frameworks have some ways to go and PurgeCSS isn't perfect but using a functional CSS framework like Tailwind or Tachyons also helps in this regard, so all of the stuff isn't intertwined and can be stripped out.
This type of tooling really does massively improve the state of things automatically, even with poor coding practices or large applications spanning multiple pages. SSR, treeshaking, chunking, stripping unused CSS, etc is a 'zero cost' type optimization that I've seen turn 700-1000kb dev assets into loading 100kb base + a few 5-10kb js/CSS files dependent on the page.
The parent commenter remembers a time when websites were server-rendered by default. The server would send down HTML, along with a small amount of CSS and JavaScript to style it and add interactivity. You didn't need an elaborate chain of compilers and bundlers and frameworks and chunkers to make sure you didn't ship several megs of dead code to the client; you just didn't ship several megs of dead code to the client. That's their baseline for web performance.
Your comment, on the other hand, seems to use the current giant-JavaScript-framework sites as the baseline for performance. And yeah, you can get a lot of cheap wins if you start from there. (For starters, you can break up your JavaScript execution into tiny slices so that, even if you're using 80% of a CPU core and draining the user's battery for no real reason, you're at least not blocking the browser UI thread.)
I basically rebuild past era bootstrap style Rails HTML views with some jquery into modern Vue components for a living on a B2B app.
I'm very familiar with the old way and how much better a proper modern replace could be. I can pack a ton of information into smaller flexible places and integrate action-relevant help boxes and only showing the parts of forms as needed.
Page render times to first action are about 10x faster on average (no joke) and our users use 1000's of objects on a single HTML form. I'd love to see someone try rendering that pure SSR framework with partials in a performant way and usable way.
This type of interaction extends well outside of my business/B3B domain as well. I'm quite excited for the future of web development after a decade of fearing more JS everywhere (which I was contributing too).
Another great HN style site is Basketball Reference, I personally love these information dense designs but it's not very scalable with tons of information, elements, and what it could really achieve if it was a desktop application or fully flexibly UI wise.
https://www.basketball-reference.com/teams/TOR/2019.html
This site could massively improve with real time filtering, multi-select forms, interactive data exports tools, multi-team/page comparisons, information highlights on hover, inline math tools, etc. On the site currently it looks great on the surface but once you engage with any JS-y stuff or imagine what's possible if it was a desktop app, and the previous tools would be extremely limited in scope.
You can do this very powerful stuff now without clogging up performance and load times. That's a big deal. We've been dealing with slow clunky JS components forever now and it can be way better.
> I can pack a ton of information into smaller flexible places and integrate action-relevant help boxes and only showing the parts of forms as needed.
> This site could massively improve with real time filtering, multi-select forms, interactive data exports tools, multi-team/page comparisons, information highlights on hover, inline math tools, etc.
I guarantee that it is possible to write any of these features in traditional HTML, CSS, and JavaScript without relying on today's frameworks or build infrastructure. I know this because even the most advanced build pipeline in the world must eventually compile down to traditional HTML, CSS, and JavaScript; that's all browsers run, no matter how many layers you add to try to abstract yourself away from it. I also know this because websites existed that had these features prior to React becoming popular.
> We've been dealing with slow clunky JS components forever now
That's the thing -- there was a time before slow, clunky JS components. (They used to be slow, clunky Flash components :P)
"All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection."
I tend to think “but what about making the web enjoyable for the end user?”
But more importantly, the fact that the page loads 2 seconds longer is a drop in the bucket compared to the insane processes our business people dream up.
I understand where they're coming from having dealt with a few legacy frameworkless spaghetti code bases that have no documentation. Give me bad code to maintain in a known framework over bad code without a framework anyday. Adding features and debugging in those conditions are no fun at all.
https://mobile.twitter.com/codinghorror/status/1049082262854...
Stop blaming the modern web. There are plenty of slow PHP and rails sites and plenty of slow React based sites. Of course speed is second priority, I'd much rather have users using my app with a mediocre experience than nobody using my app. However, as the web supports more tooling and frameworks continue to evolve towards web assembly, I believe will start to have web apps approaching native speed.
The reality is that requiring a server to render every page limits what you can do with your app. Even if modern tooling is overused, developers will always move towards what allows you to do more.
I'd much rather focus on making modern tooling faster than complaining about the modern web.
I always strive to keep the client side stupid. I should be sending as much of the final document as possible from the server and any interactivity needed should also produce as little work for the client as possible.
In contrast, many sites seem to think that 1MB of JavaScript, or even 5MB, are acceptable, and they can't even show simple static content when client-side JavaScript is disabled. On a slow link, 1MB of JavaScript means that the user has probably given up. And it's not just the size. 200KB of HTML is far far faster than 200KB of JavaScript; web browsers are highly optimized for handling HTML, while processing JavaScript is necessarily much slower. JavaScript is great for some things, but like a sledgehammer it's not always the best solution. Too many people aren't considering the real end-user experience. "Pretty graphics, but it takes 5 minutes to download" is usually not a worthwhile tradeoff.
To paraphrase Goldblum:
Your web designers were so preoccupied with whether or not they could use JavaScript, they didn’t stop to think if they should.
If the companies hiring web devs changed their mindset and listing a dozen different frameworks on your resume was perceived as the negative trendchasing architecture-astronauts that such developers often turn out to be (at least in my experience), and valued simple JS skills and experience instead, I suspect websites would end up being a lot different than they are today.
for this as well.
I bet HN will look almost identical 10 years from now, too. I wonder how many popular websites can boast such a consistent design from their beginning?
https://gist.github.com/1player/85d146a4aa0c2afc78bab63582f5...
Some things like the login page are not styled correctly, but works good enough to browse and post comments.
I personally wish HN attracted a bit of a fresher, younger crowd as the conversation here has become more stale over the last few years.
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.
A better responsive CSS file wouldn't make the site any slower or degrade the experience for laptop users.
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.
I got so used to pinch-to-zooming, for so many years, I guess I didn't even consider that usability flaw.
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 could use some tweaks to keep everything aligned, but the small usability tweak was most important to me.)
These are my network requests when I vote with JS enabled.
It's not any lighter, it's just not reloading the page.
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.
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.
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.
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.
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).
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
Exactly
But it doesn't turn green.
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.
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).
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.
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.
What a pleasantly tiny script file. More site code should be this easy to read.
(if *ajax-request*
(upvote)
(upvote-and-generate-page))It also (partially) removes the requirement for live-pages on an active post here.
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.
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.
Please never do a redesign. Don't ruin a good thing.
I’d also like to express my sincerest THANKS for keeping it simple. Visiting HN every day is pure joy, and reminds me of the old days of the web with less distractions.
It crashed eventually (not surprising given the minuscule amount of RAM this device has), but the front page was visible long enough for me to read some of the titles.
- Sent from my Apple Watch
Yes indeed, the shit that web developers were trying to get rid of around 2005-ish, is actually better than we have today on many pages.
Who are all these programmers that like bloat so much??
That was written two and a half years ago now, and things have only continued to get worse since then.
This improvement could be very beneficial for users with fat fingers. Well, HN is inclusive platform, right?
[1]: https://i.postimg.cc/jjBSVmCX/Screenshot-at-2019-09-01-15-23...
That annoyance is considerably less than all the others a full-JS Twitter imposes. Including the motherlovin' account-creation nag that shows up all the motherlovin' time.
One click through at entry rather than random annoyance in the midst of reading? A net win. And an incredibly sad commentary on the state of the Web.
And I would prefer if "hiding" would be near the voting buttons.
See a few posts less but don't have to fiddle around with buttons.
https://www.talkyard.io/forum/latest
Long term, I'd like to make this work on slow connections, Offline-First, in e.g. rural villages in Africa :- ) on a Raspberry Pi, local wifi, unaffected by a "global Internet outage".
Can I ask, which part of the world are you in? (which country?)
Imgur for instance isn't a site that I visit daily or even weekly any more. I really enjoyed the site, but after a redesign it just stopped being enjoyable. It's way to slow, to much Javascript. It's the only thing that will reliably force my MacBook to ramp up it's fans. How is it possible for a website to make a laptop heat up more than doing development work?
What makes you say this?
Fine by me, but I wish HN would offer the same privilege to its users and allow us to delete our old posts
Though he's still a major shareholder of YC which owns it. He tweets quite a lot these days.
I do agree with op that HN is built for sharing news and links and it is great that they have not tried to update it with new style and heavy experience.
I’m proud to have a single brick in the foundation of a site that has lasted this long.
When I share an hn link on iMessage or telegram it should at least show the hn title text
It doesn't constantly break, because the site is simple and unchanging.
Thanks to HN for that.
- Keeping the ‘[-]’ comment collapse button minuscule on the mobile site, so that hitting it is a game of chance.
- Abstaining from adding semantic CSS class names to page elements—such that CSS selectors amount to “a table cell on the third level under this table cell.”
These two features steadily keep me from spending even more time on the site than I already do.
Even if I only touch in it’s general direction my phone compensates for my fat fingers and collapses anyway.
Does this not work on other devices?
With HN as is, I think plenty can be done to make it light weight and make it even more performant.
E.g HN isn’t a progressive web app. So you’re loading the same things over and over again. With a service worker HN could teach even more people around the world with a spotty connection.
May be I should prototype and build it.
Hacker News uses standard HTTP headers to cache all its CSS, JavaScript, and images. The only thing that gets re-downloaded when you click a link is the actual text content on the page -- usually about ten kilobytes. And isn't that almost always what you want, to make sure you see the latest posts, comments, and vote counts?
Because it's standard HTML, Hacker News also works with existing features like Chrome for Android's "download page when back online" button.
Could be a bit more flexible on some regions of discussion, but take that as a quibble, and recognition to many personas here. (You are good people, I do not imply otherwise)
Those personas combine in what I find to be lucid, and high value.
And the full thanks go to those who recognize that and work to nurture it all along.
By 'works', I mean not just content been served, but overall usages not making you wanting to abandon this site.
Also DDG !hn <terms>
If DDG is your default browser, you can run that in the navbar. Which I do all the damned time.
https://hn.algolia.com/?q=thinkpad
So not nice!
I'm a fan of basic functionality w/o JS in most cases myself. I make exceptions for useful and non-annoying sites. Algolia meets both criteria.
It's not as clean as hn, but way better than "new" reddit. (I use it even on my fast connection.)
Tends to work better than either www or old for console browsers (lynx, w3m, etc.)
Some features, notably search, are broken, however.
I actually find it useful though. It's among the features that kept me using Reddit as a blogging engine for as long as I did, though accumulating annoyances have since driven me from that.
Also: yall ever hear about that syndrome that originated in Stockholm? This site obviously needs a lot of work
Learn once, use for a lifetime.
I'd argue that having simpler markup and some sane, well-designed css would enhance performance further.
I wish there were more.
I wouldn’t complain, though, if dark mode and a mobile-friendly font size were introduced.
Fonts and upvote buttons could be a bit larger on mobile though imho (my hands are of average size).
It still works on my Blackberry 8700 under Opera Mini, and is the only site that I commonly use that I can say that about.
So HN performs fine using GPRS/EDGE!