Fast • Hacker News Board

Re: Fast

#211

Post by NobodyNada » Wed, Jul 30, 2025, 11:04 PM UTC

KPGv2 wrote: post #157

Eji1700 wrote: post #114

Earlier quoted context omitted.

Information density and ease of identification is the antithesis of "engagement" which often has some time on site metric they're hunting. If you can find what you want and read it you might not spend 5 extra seconds lost on their page and thus they can pad their stats for advertisers. Bonus points if the stupid page loads in such a way you accidentally click on something and give them a "conversion". Sadly financial…

The one and only thing I'd do is make the font bigger and increase padding. There's overwhelming consensus that you should have (for English) about 50–70 characters per line of text for the best, fastest, most accurate readability. That's why newspapers pair a small font with multiple columns: to limit number of characters per line of text. HN might have over 100 chars per line of text. It could be better. I know I c…

A narrow column of text can make it easier to read individual sentences, but it does so by sacrificing vertical space, which makes it harder to skim a page for relevant content and makes it easier for me to lose track of my place since I can't see as much context, images, and headings on screen all at once. I also find it much harder to read text when the paragraphs form monotonous blocks spanning 10 lines of text rather than being irregularly shaped and covering 3-5 lines. I find Wikipedia articles much harder to read in "standard" mode compared to "wide" mode for this reason.

Different people process visual information differently, and people reading articles have different goals, different eyesight, and different hardware setups. And we already have a way for users to tell a website how wide they want its content to be: resizing their browser window. I set the width of my browser window based on how wide I want pages to be; and web designers who ignore this preference and impose unreadable narrow columns because they read about the "optimal" column width in some study or another infuriate me to no end. Optimal is not the same for everyone, and pretending otherwise is the antithesis of accessibility.

Re: Fast

#212

Post by fHr » Wed, Jul 30, 2025, 11:09 PM UTC

hn_throwaway_99 wrote: post #104

Just want to say how much I thank YCom for not f'ing up the HN interface, and keeping it fast. I distinctly remember when Slashdot committed suicide. They had an interface that was very easy for me to scan and find high value comments, and in the name of "modern UI" or some other nonsense needed to keep a few designers employed, completely revamped it so that it had a ton of whitespace and made it basically impossibl…

HN interface is goated

Re: Fast

#213

Post by ilyakaminsky » Wed, Jul 30, 2025, 11:12 PM UTC

sipjca wrote: post #171

ilyakaminsky wrote: post #69

Fast is also cheap. Especially in the world of cloud computing where you pay by the second. The only way I could create a profitable transcription service [1] that undercuts the rest was by optimizing every little thing along the way. For instance, just yesterday I learned that the image size I've put together is 2.5× smaller than the next open source variant. That means faster cold boots, which reduces the cost (and…

ive approached the same thing but slightly differently. i can run it on consumer hardware for vastly cheaper than the cloud and don't have to worry about image sizes at all. (bare metal is 'faster') offering 20,000 minutes of transcription for free up to the rate limit (1 Request Every 5 Seconds) https://geppetto.app I contributed "whisperfile" as a result of this work: * https://github.com/Mozilla-Ocho/llamafile/tre…

> i can run it on consumer hardware for vastly cheaper than the cloud

Woah, that's really cool, CJ! I've been toying the with idea of standing up a cluster of older iPhones to run Apple's Speech framework. [1] The inspiration came from this blog post [2] where the author is using it for OCR. A couple of things are holding me back: (1) the OSS models are better according to the current benchmarks and (2) I have customers all over the world, so that geographical load-balancing is a real factor. With that said, I'll definitely spend some time checking out your work. Thanks for sharing!

[1] https://developer.apple.com/documentation/speech

[2] https://terminalbytes.com/iphone-8-solar-powered-vision-ocr-...

Re: Fast

#214

Post by frutiger » Wed, Jul 30, 2025, 11:15 PM UTC

hn_throwaway_99 wrote: post #104

Just want to say how much I thank YCom for not f'ing up the HN interface, and keeping it fast. I distinctly remember when Slashdot committed suicide. They had an interface that was very easy for me to scan and find high value comments, and in the name of "modern UI" or some other nonsense needed to keep a few designers employed, completely revamped it so that it had a ton of whitespace and made it basically impossibl…

The HN UI could do with some improvements, especially on mobile devices. The low contrast and small tap areas for common operations make it less than ideal, as well as the lack of dark mode.

I wrote my take on an ideal UI (purely clientside, against the free HN firebase API, in Elm): https://seville.protostome.com/.

Re: Fast

#215

Post by tialaramex » Wed, Jul 30, 2025, 11:16 PM UTC

cyanydeez wrote: post #139

hn_throwaway_99 wrote: post #104

Just want to say how much I thank YCom for not f'ing up the HN interface, and keeping it fast. I distinctly remember when Slashdot committed suicide. They had an interface that was very easy for me to scan and find high value comments, and in the name of "modern UI" or some other nonsense needed to keep a few designers employed, completely revamped it so that it had a ton of whitespace and made it basically impossibl…

Ive wanted tp poll HN about how many people actively track usernames. With IRC its basically part of the task, but every forum i read, its rare that i ever consider whose saying what.

I routinely notice a handful of people, such as Thomas Ptacek, whose opinions I have opinions about, and then in context I notice e.g. Martin Uecker for C and especially the pointer provenance problem (on which he has been diligently working for some years), or Walter Bright (for the D language), or Steve Klabnik (Rust)

There are people who show up much less often and have less obvious usernames, Andrew Ayer is agwa for example, and I'm sure there are people I blank on entirely.

Once in a while I will read something and realise oh, that "coincidental" similarity of username probably isn't a coincidence, I believe the first time I realised it was Martin Uecker was like that for example. "Hey, this HN person who has strong opinions about the work by Uecker et al has the username... oh... Huh. I guess I should ask"

Re: Fast

#216

Post by EGreg » Wed, Jul 30, 2025, 11:18 PM UTC

My sites. In order of increasing complexity. Are they fast?

https://magarshak.com

https://miracles.community

https://qbix.com

https://intercoin.app

Here is some extensive advice for making complex websites load extremely quickly

https://community.qbix.com/t/qbix-websites-loading-quickly/2...

Here is also how to speed up APIs:

https://community.qbix.com/t/building-efficient-apis-with-qb...

One of the biggest things our framework does as opposed to React, Angular, Vue etc. is we lazyload all components as you need them. No need for tree-shaking or bundling files. Just render (static, cached) HTML and CSS, then start to activate JS on top of it. Also helps massively with time to first contentful paint.

https://community.qbix.com/t/designing-tools-in-qbix-platfor...

All this evolved from 2021 when I gave this talk:

http://www.youtube.com/watch?v=yKPKuH6YCTc

Re: Fast

#217

Post by RandomBacon » Wed, Jul 30, 2025, 11:19 PM UTC

underdeserver wrote: post #121

9rx wrote: post #12

> Rarely in software does anyone ask for “fast.” They don't explicitly ask for it, but they won't take you seriously if you don't at least pretend to be. "Fast" is assumed. Imagine if Rust had shown up, identical in every other way, but said "However, it is slower than Ruby". Nobody would have given it the time of day. The only reason it was able to gain attention was because it claimed to be "Faster than C++". Watch…

Eh, I think the HN crowd likes fast because most tech today is unreasonably slow, when we know it could be fast.

It's infuriating when I have to use a chatbot, and it pretends to be typing (or maybe looking up a pre-planned generic response or question)...

I'm already pissed I have to use the damn thing, please don't piss me off more.

Re: Fast

#218

Post by fuzzfactor » Wed, Jul 30, 2025, 11:19 PM UTC

IshKebab wrote: post #196

bitpush wrote: post #74

> Superhuman's sub-100ms rule—plus their focus on keyboard shortcuts—changed the email game in a way that no one's been able to replicate, let alone beat. https://blog.superhuman.com/superhuman-is-being-acquired-by-... Being fast helps, but is rarely a product.

I often hear this sort of thing "Facebook was a success using PHP therefore language choice isn't important" or in this case "superhuman made their product fast and they still failed so speed isn't important". It's obviously wrong if you think about it for more than a second. All it shows is that speed isn't the only thing that matters but who was claiming that? Speed is important. Being slow doesn't guarantee failur…

>Being fast helps, but is rarely a product.

>Being fast doesn't guarantee success.

Sometimes it can be a deciding factor though.

Also sometimes speedyness or responsiveness beyond nominal is not as much of a "must have" compared to nominally fast performance in place of sluggishness.

Re: Fast

#219

Post by tomrod » Wed, Jul 30, 2025, 11:23 PM UTC

stavros wrote: post #165

tomrod wrote: post #101

Earlier quoted context omitted.

I'm consistently seeing personal and shared anecdotes of a 40%-60% speedup on targeted senior work. As much as I like agents, I am not convinced the human using them can sit back and get lazy quite yet!

Eeeh, I spend less time writing code, but way more time reviewing and correcting it. I'm not sure I come ahead overall, but it does make development less boilerplaty and more high level, which leads to code that otherwise wouldn't have been written.

I wonder if you observe this when you use it in a domain you know well versus a domain you know less well.

I think LLM assistants help you become functional across a more broad context -- and completely agree that testing and reviewing becomes much, much more important.

E.g - a front end dev optimizing database queries, but also being given nonsensical query parameters that don't exist.

Re: Fast

#220

Post by RandomBacon » Wed, Jul 30, 2025, 11:24 PM UTC

raldi wrote: post #120

chamomeal wrote: post #28

Only sorta related, but it’s crazy that to me how much our standards have dropped for speed/responsiveness in some areas. I used to play games on N64 with three friends. I didn’t even have a concept of input lag back then. Control inputs were just instantly respected by the game. Meanwhile today, if I want to play rocket league with three friends on my Xbox series S (the latest gen, but the less powerful version), I…

Or how channel surfing now requires a 1-2 second latency per channel, versus the way it was seemingly instant from the invention of television through the early 1990s.

Having a lot more channels is cool I guess, but it was much better to watch and listen to a staticy analog channel 20 years ago, than a digital channel today where there is no audio and the image freezes.