I saw the name and thought it might be some kind of retro throwback to the 1996 version of Netscape Communicator. I was sort of looking forward to the integrated but awkward built-in mail client and newsreader.
I would have been horrified if I saw what websites would look like in 2010+ when I first started using the web. The amount of unnecessary garbage and JS added to sites goes well beyond the adtech part. Half or more of sites using frameworks probably should never have used them.
A good contrast is Reddit vs hn. Reddit’s current site is basically unusable and sluggish on modern hardware that can you could train ML models with.
Just look at all the overhead of the article‘s website… When I first clicked the link the "website" crashed, so instead of the hot take, all I could read is that "addEventListener is not a function". That tells you all about the current state of affairs
(Yes I get that webdevs' personal sites are their playground)
My favourite recent incarnation if this is when YouTube has its JavaScript go sideways and then it blames the internet being out instead of doing anything productive
(Semi) honest question to the commenters below parent, do you all use styluses, or do you just have small fingers, or is there some predictive touch system in the default browser for your devices that isn't present in Firefox? How big are your screens, are you running phablets?
Trying to understand how so many people are reaching the conclusion that HN works well on mobile. Maybe 25% of the time I try to upvote or downvote a comment on mobile, I fat-finger the wrong arrow. That shouldn't happen in a mobile interface.
I feel like just for the sheer number of comments I'm seeing saying that they don't know what the problem is, there must be something I'm missing. To me it's pretty straightforward, you have to zoom the screen in 20-40% to press any of the buttons or accurately target on any of the links, and when you do that you have to interrupt reading flow because the text doesn't wrap during that zoom.
When I turn off the mobile site and request the desktop version it's even worse, so I don't think it's a browser setting. I don't think I have particularly large hands, but the links on the top of the site are still only about 1/3 to 1/4 the size of my pointer finger.
What are you all seeing that I'm not? Is there a font-size setting you have checked? This is a pain to use without a precise pointer.
This button clicking issue certainly exists in Android Chrome. It's just that almost every designed-for-mobile website is missing functionality or behaves in unpredictable and terrible ways. Browsing not-designed-for-mobile web sites on mobile and zooming whenever I need to click on something is a big upgrade.
This is an interesting/illuminating comment, and it makes me wonder if some of this might be a personal bubble thing. I feel like I generally tend to have a better experience on mobile than other people describe, but I'm also running mobile adblockers, and more importantly, I also might just not be visiting all of the same sites as other people?
People complain about Reddit on mobile, and I totally agree, Reddit mobile is awful, but it's also a really small part of my life, I generally don't visit Reddit on a phone that often -- so it's easier for me to think about Reddit's mobile site(s) as being some kind of outlier?
My experience has been I read a lot of blogs on my phone, I do searches (that go through duckduckgo, which I don't really have a ton of complaints about as a mobile site), I look up quick pieces of information on the fly from random sites, I look at MDN documentation, trying to think what else...
I also spent a long time turning off Javascript entirely on my phone browser and I've only very recently started changing that practice (largely because of Gorhill deprecating uMatrix), which probably biases things even more, because a lot of the browsing I do on my phone works without Javascript, and that gets rid of a nontrivial number of annoying behaviors from more aggressive sites, and so I wonder if I'm just not giving the same amount of "credit" for HN not doing the Reddit bullcrap where it pops up a notification asking me to install an app, and that makes it easier to stare at the flaws.
If I was doing a lot of Reddit browsing on my phone, I would appreciate HN more on mobile, I will give people that HN is much better on mobile than Reddit.
Anecdotally, I've found that iOS handles small touch targets much better than Android. I had an HTC Raider, a Moto G, and a Moto X Play, and I felt very fat-fingered on all of them. Then I switched to an iPhone 6s and now an iPhone 12 Mini and with both of them I've had zero problems with small touch targets, even ones that are close to each other like with Nonograms.
> Would it be slower or use more CPU or memory to render?
With flexbox layout, probably (?), but likely imperceptibly (don't quote me on that, I haven't actually done the math to check if the benefits from decreased DOM elements would outweigh the increased cost of flexbox, maybe it would get faster just by virtue of shipping less HTML).
That being said, GP is being kind of extravagant, there is arguably nothing on HN that requires tables or flexbox. I always felt like inline spans and maybe a few floats/margin:autos for stuff like headers/menus would probably handle the majority of the layout.
This is part of my criticism of "HN picked the simple answer" takes; even if you go back over a decade and even if you take flexbox off the table, tables weren't really the simplest answer after CSS `margin:auto` was invented. This really isn't a website with columns of data, it almost doesn't need any layout tool at all.
I think the, "now flexbox exists so we can do it correctly" takes are also wrong in their own way; HN is a single-column reading experience with very simple menus, why bring flexbox into this? I always try to temper this claim because I haven't technically ever sat down and built a pixel-perfect replica using normal HTML, I don't technically know there's nothing that wouldn't require modern CSS. But I have poked around at different pages of the site and messed around with resolutions, and I've never seen a situation on the site that I felt required all of that extra HTML and complexity.
I almost wonder if the point of the embedded font tags and image spacers and crud is that site is trying to make it sort of render the same even with CSS turned off. But if so, that's bad practice and the site should stop doing that. Anyone who's turning off CSS is doing that for a reason and the site should just respect that and ship them the pure content.
Eh, yeah I guess that happens, I guess I'm so used to the rest of the internet being so awful on mobile that it doesn't phase me. Which is funny, because I'm always super irritated by the rest of the internet.
Going to push back on this line specifically, HN has a number of issues. They're not dealbreakers, but they're also not particularly hard to fix with modern HTML. HN has generally kind of bad accessibility/semantics, it's pretty frustrating to use on mobile, and it degrades kind of poorly without Javascript (collapsing thread buttons still appear even though they don't work, also, collapsing thread buttons don't work without JS).
HN is (unironically) a great example of how kind of hacky you can make something and how little you can iterate on it while people still are mostly able to use it for its intended purpose. And (with the exception of maybe its blind accessibility problems) it should be held up as a great example of that.
But it's not a good example of "do things simply and they'll just work well." If anything, HN is a great example of why stuff like tables were abandoned. And the HTML isn't even that simple, this must have been a royal pain to build, everything everywhere is another embedded table. It's a weird dig at how bad some major websites have become that people don't see HN's HTML as bloated or convoluted.
Ever really dug into how HN threading works? Everything is a top-level comment, and it inserts transparent images to create the illusion of indentation. It's a wildly out-of-left-field solution that makes parsing out and styling threads way harder than it needs to be. Seriously, I've spent way too much time trying to figure out how to make CSS selectors for custom user-styling work on child comments/replies on a site that is supposed to be displaying a comment tree in the DOM tree. There's a one-to-one mapping there, you don't really need a complicated visual slight-of-hand to display this information; just put the comments in the tree.
Again, not to get mad at HN; but I think people use it as a positive example in the wrong situations. HN has bad HTML with obvious downsides that would be pretty easy to fix, but it turns out that creating an elegant website and filing off the rough edges is actually a really small part of running a community, and doesn't matter that much in the long run when compared to other things you could be doing to foster that community (like moderation/curation), and that is a very good lesson for tech people to learn from HN. But nobody should praise the HTML on this site, there are much better examples out there on the web of sites that use simple HTML to great effect.
----
> (Applications are a different matter obviously)
Much more minor push-back but I actually would love to see more applications embrace the interactive document model even when fully native and fully offline. Not all applications, but a bunch of them. Stuff like calculators, calendars, even bigger applications like database software/image viewers/file browsers, etc...
User-accessible stylesheets for applications, user-accessible scraping tools for applications, etc... I think there's a lot of potential for user computing hidden behind a willingness to say, "no, many applications are just text displayed in tree/table form when you think about it, and the app/document divide was always sort of nonsense."
> Ever really dug into how HN threading works? Everything is a top-level comment, and it inserts transparent images to create the illusion of indentation. It's a wildly out-of-left-field solution...
Having worked on an implementation of comment indentation before, I think it's a technical design choice rather than wildly out of left field. From the backend perspective, it's more performant (and simpler from as far as code maintainability) to have a flat db table with a number representing indentation level, rather than have each comment point to its parent, and then have to recursively build the html.
When you're getting as much traffic as HN, such design tradeoffs can make a huge difference in site responsiveness.
I might be misunderstanding what you're referring to. To be clear, I'm not really talking about recursively building anything about the HTML or fetching any additional data about other comments, or storing it in the database as a tree, a flat structure and iterative builds are fine for all of this. I'm talking about, purely off the top of my head, moving away from:
result = reduce(comments, (result, comment) => {
return result + build_comment(comment);
}, '');
I assume you're right and there's some kind of extra complexity somewhere, but HN isn't just storing the comments with no context other than indentation as far as I can tell. It is maintaining parent-child relationships at least well enough that the buttons to minimize/maximize threads work, so I am not sure what process is being skipped here by shipping flat HTML lists.
I guess I haven't ever read through HN's clientside Javascript, maybe it's calculating how to minimize threads on the fly completely clientside by iterating over the DOM, and maybe that's why the buttons don't work with JS disabled. But.. oof, I wouldn't hold that up as an example of good, simple clientside code if that's the case.
----
But again, I'm not going to argue with your conclusion, I assume there's something I've missed, I assume you're right.
This is still a bad example to use for "see, simple HTML is better". What you're describing is a good example of why it makes sense to say, "see, convoluted table setups that are worse on the client are faster overall than clean, simple output."
Which is not a bad lesson to learn from HN. It's a great lesson, sometimes performance requires us to do hacky things. But it is a very different lesson from where this thread started. You still would never point at that and say, "this is a good example of what HTML should look like", you would say, "these are the kinds of messy sacrifices that might be necessary to maintain a performant backend."
> maybe it's calculating how to minimize threads on the fly completely clientside by iterating over the DOM, and maybe that's why the buttons don't work with JS disabled
Holy crud, I just opened the JS up and this is actually what it's doing. Heck me and my little 'not going to contradict you' statements, you might just be completely entirely right about what's going on I guess.
function kidvis (tr, hide) {
var n0 = ind(tr), n = ind(kid1(tr)), coll = false;
if (n > n0) {
while (tr = kid1(tr)) {
if (ind(tr) <= n0) {
I'm still going to reassert that any architecture that leads to someone doing this kind of logic every time a button is pressed is neither simple nor elegant, and at best this is an example of making architectural sacrifices and introducing complexity for the sake of performance; there's no way that this kind of page logic is easier to maintain or to understand than something built around a more semantic structure.
It's also definitely not easier on the client, I've seen some comments on here argue that HN might use all this weird stuff to save client battery life, and I feel more confident now saying that's not the reason, because if someone is somehow, someway legitimately in some incredible situation where they're actually worried about the battery drain of a browser rendering a table vs a some extra CSS, then this is not the code you would want to run every single time you press a button on the page.
But yeah, the "we just base everything off of an indentation integer and comment order" theory does seem a lot more plausible to me now, because I'm having a somewhat difficult time thinking why else collapsing comments would work this way.
I liked his point near the end of the article comparing blockchains to XML - overcomplicated and oversold and added to too many things due to marketing and consultant hype.
The obvious next question he didn't ask is, what is the JSON of blockchain? The one that's more flexible and efficient and ends up actually becoming ubiquitous?
Maybe it hasn't appeared yet? Maybe it shouldn't? I don't know, but the comparison is just waiting for that followup.
> Here's a metaphor. Blockchains today are like… XML in the early 2000s. A long-burning overcomplicated trash fire that a bunch of large, cash-rich, unscrupulous, consultant-filled mega-organizations foisted on us for years and years, that we all now pretend we weren’t dumb enough to fall for. Remember SOAP? Remember when we tried to make HTML4 into XHTML? Ew, no.
To answer your question, here are some suggestions for what might be the JSON of blockchain:
* Git - Cryptographic hashing, Merkle trees, and distributed architecture (pre-GitHub) to record a history of events.
* Databases (SQL, NoSQL, NewSQL) - Have been running the entire fincancial system for several decades.
* Credit cards - ubiquitous electronica payments "Credit card was the most used payment method in the United States in 2020, with 38 percent of point of sale payments being made by credit card." - statista.com
I gather it was used to regulate the temperature of the liquid coolant - but instead of just some pipes or whatever, the designers turned it into a nice "waterfall" feature. I think it even lit up.
It should be noted that anybody coming into Canada now from a foreign country, no matter their citizenship, is being told to self-quarantine for 14 days.
This isn't mandatory or enforced (yet) but it's not exactly a red carpet for folks to come visit for tourism or business meetings.
Flex has indeed figured it out, I use it for everything now and rarely touch margin: auto unless I'm being lazy or there's a very simple usecase.
But that said Flex still very much classic CSS: the awkward naming schemes, the excessive options for each parameter, the mixing of different options available, etc... it's still very much CSS in all it's quirky dirtiness.
CSS Grids kind of shocked me that they weren't entirely convoluted.
Maybe it's the design-by-committee stuff but even as CSS has gotten better: it still took way too long and it's still very weird. Maybe like JS this will slowly no longer become true, but I'm kind of happy I grew up without Flex/modern CSS because I'm unafraid of that quirkiness.
I like to think of Sisyphus a bit like someone waiting in line for a rollercoaster or a ski lift. The pushing is a slog, but then you reach the top and WOW BOOOM the rock cascades down the hill and it's AWESOME! Time to start pushing it back up again.
Yes yes I know Sisyphus is a metaphor for the pointlessness of life - but that doesn't mean you have to take it at face value.
> The pushing is a slog, but then you reach the top and WOW BOOOM the rock cascades down the hill and it's AWESOME!
In the original myth the rock rolls down alright, but it rolls down over our hero and then he has to go down and push it back up again knowing what will happen.
I loved EMACS when I first tried it. Granted, that was in around 2001 and my day job had required using a terrible bloated version of IBM WebSphere Application Developer which would leak 16 megs of RAM every time I tried to open an HTML page, forcing me to completely restart my 640meg Dell several times a day. EMACS, in Terminal.app on the then-new OSX, was so refreshingly fast and light (and comparitively good looking) that I finally felt like I could do some real work for a change.
I know that sounds kind of ridiculous, considering EMACS' history - but you never had to use that vintage IBM JSP suite!
Between this and the infamous hacker group called "The Shadow Brokers" I think it's time someone did a study on the influence of Mass Effect on tech culture.
Not me, though - I'm in the middle of some calibrations right now.
