Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fast

catherinejue.com

Post reply on HN
Print view View original

231–240 of 450 posts

Re: Fast

#231

Post by sien »

cruffle_duffle wrote: post #227
HarHarVeryFunny wrote: post #176

Earlier quoted context omitted.

I don't think it was UI that killed Slashdot. The value was always in the comments, and in the very early years often there would be highly technical SMEs commenting on stories. The site seemed to start to go downhill when it was sold, and got into a death spiral of less informed users, poor moderation, people leaving, etc. It's amazing that it's still around.

For me, Slashdot became full of curmudgeons. It’s pretty tiring when every “+5 Insightful” on a hard drive article questioning why you’d ever want so big of a drive, or why you’d require more than 256 colors or whatever new thing came out… like why are you even on a technology enthusiast site when you bitterly complain about every new thing? Basically either accept change or get left in the dust and slashdot’s crowd…

Kuro5hin was far less about technology though.

It was interesting in a different way though.

Like Adequacy.

Did you also move over to MetaFilter ?

Re: Fast

#232

Post by noisy_boy »

SatvikBeri wrote: post #63
Aurornis wrote: post #32

> Rarely in software does anyone ask for “fast.” We ask for features, we ask for volume discounts, we ask for the next data integration. We never think to ask for fast. Almost everywhere I’ve worked, user-facing speed has been one of the highest priorities. From the smallest boring startup to the multi billion dollar company. At companies that had us target metrics, speed and latency was always a metric. I don’t thin…

At 6 out of 8 companies I've worked at (mostly a mixture of tech & finance) I have always had to fight to get any time allotted for performance optimization, to the point where I would usually just do it myself under the radar. Even at companies that measured latency and claimed it was important, it would usually take a backseat to adding more features.

That is how it is most of the time. If you want to experience the other extreme, go to HFT or low-latency projects.

Re: Fast

#233

Post by erwincoumans »

deergomoo wrote: post #208
constantcrying wrote: post #39

I think that people generally underestimate what even small increases in the interaction time between human and machine cost. Interacting with sluggish software is exhausting, clicking a button and being left uncertain whether it did anything is tedious and software being fast is something you can feel. Windows is the worst offender here, the entire desktop is sluggish even though it there is no computational task wh…

Apple software, especially lately, can be really bad for it too. Single core perf is slightly better on my iPad than my MacBook Pro and yet everything feels an order of magnitude slower. If I am impatiently tapping the space I know a button will appear waiting for an animation to finish, some aspect of software design has gone horribly awry.

iOS (iPhone, iPad) UI is typically smooth and fast though. If only car navigation and UI could be as responsive.

Re: Fast

#234

Post by makeitdouble »

pron wrote: post #152
cycomanic wrote: post #146

Earlier quoted context omitted.

I've already written about this several times here. I think the current trend of LLMs chasing benchmark scores are going in the wrong direction at least as programming tools. In my experience they get it wrong with enough probability, so I always need to check the work. So I end up in a back and forth with the LLM and because of the slow responses it becomes a really painful process and I could often have done the ta…

Programmers (and I'm including myself here) often go to great lengths to not think, to the point of working (with or without a coding assistant) for hours in the hope of avoiding one hour of thinking. What's the saying? "An hour of debugging/programming can save you minutes of thinking," or something like that. In the end, we usually find that we need to do the thinking after all. I think coding assistants would end…

In general agreement about the need to think it through, and she should be careful to not oraise the other extreme.

> "An hour of debugging/programming can save you minutes of thinking"

The trap so many dev fall into is assuming code behaves like they think it is. Or believing documentation or seemingly helpful comments. We really want to believe.

People's mental image is more often than not wrong, and debugging tremendously helps bridge the gap.

Re: Fast

#235

Post by cruffle_duffle »

devnullbrain wrote: post #228
andsoitis wrote: post #201

Earlier quoted context omitted.

Their joke could have also been interpreted as sarcasm and when you’re going to be sarcastic you want to be doubly sure that you’re correct. But I also concur with you that it is good to bring some levity to “serious” conversations!!

https://whatever.scalzi.com/2010/06/16/the-failure-state-of-... Required reading for internet comedians.

Thanks for that! I miss old school blogs

Re: Fast

#236

Post by sb057 »

This page (consisting of 693 words) took a full second to load for me because it had to import multiple fonts from Google (which also constitute over 70% of the page's size).

Re: Fast

#237

Post by dmix »

sb057 wrote: post #236

This page (consisting of 693 words) took a full second to load for me because it had to import multiple fonts from Google (which also constitute over 70% of the page's size).

Do you mean finish loading?

Google Webfont loader is (usually) non blocking when done right, but the text should appear fine before

The page loaded instantly for me

Re: Fast

#238

Post by amiga-workbench »

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…

I use HN zoomed in at 133%. Its a lot more comfortable even when I'm wearing my glasses.

Re: Fast

#239

Post by dmix »

timeon wrote: post #170
9rx wrote: post #25

Earlier quoted context omitted.

> fast is easily left behind when looking for frameworks. Nah. React, for example, only garnered attention because it said "Look how much faster the virtual DOM is!". We could go on all day. > People want features, people want compatibility Yes, but under the assumption that it is already built to be as "fast" as possible. "Fast" is assumed. That's why "faster" is such a great marketing trick, as it tunes people into…

Isn't React one of the slower frameworks? https://krausest.github.io/js-framework-benchmark/current.ht...

Reactivity as an idea allowed you to manage data and dom/UI updates in a more performant way than the approach prior to React being popular.

But React started a movement where frontend teams were isolated from backend teams (who tend to be more conservative and performance minded), tons of the view was needlessly pushed into browser rendering, every paged started using 20 different JSON endpoints that are often polling/pushing adding overhead etc. So by every measure it made the Web slower and more complicated, in exchange for some slightly easier/cohesive design management (that needs changing yearly).

The particulars on the vdom framework itself are probably not that important in the grand scheme. Unless it's design encourages doing less of those things (which many newer ones do but React is flexible).

Re: Fast

#240

Post by yellowapple »

The flip-side of this is that if something is too fast, it raises doubts about whether it actually happened at all. I'm reminded of the TurboTax case, where Intuit found that adding a bunch of artificial loading screens to make it look like TurboTax was taking its time to really pore over customers' tax returns ended up being more appealing to users than not doing so. The actual "analyses" happen within less than a second, but that was (allegedly) too fast for users to believe.
Post reply on HN