Hacker News Reader

Comment by 9rx | Hacker News Reader

> 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 HN for a while and you'll start to notice that "fast" is the only feature that is necessary to win over mindshare. It is like moths to a flame as soon as something says it is faster than what came before it.

View on HN

Only in the small subset of programmers that post on HN is that the case. Most users or even most developers don't mind slow stuff or "getting into flow state" or anything like that, they just want a nice UI. I've seen professional data scientists using Github Desktop on Windows instead of just learning to type git commands for an easy 10x time save

GitHub Desktop is way better for reviewing diffs than the git cli. Everyone I’ve ever worked with who preferred cli tools also did an add and commit everything, and their PRs always have more errors overall that would be caught before even being committed if they reviewed visual diffs while committing.

Sublime Merge gets you all those benefits, PLUS it’s really fast!

The best interface is magit, IMO. I use a clone of it in VS Code that is nearly as good. But you get the speed of CLI while still being very easy to stage/unstage individual chunks, which is probably the piece that does not get done enough by CLI users.

They do mind, which is why we see such a huge drop off in retention if pages load even seconds too low. They just don't describe it in the same way.

They don't say they buy the iPhone because it has the fastest CPU and most responsive OS, they just say it "just works".

Not everyone is conscious about it but I feel like it’s something that people will always want.

Like the « evergreen » things Amazon decided to focus on : faster delivery, greater selection, lower cost.

You're taking the wrong conclusion, "Fast" is a winning differentiator only when you offer the same feature-set, but faster.

Your example says it, people will go, this is like X (meaning it does/has the same features as X), but faster. And now people will flock from X to your X+faster thing.

Which tells us nothing about if people would also move to a X+more-features, or a X+nicer-ux, or a X+cheaper, etc., without them being any faster than X or even possibly slower.

Really not sure about that. People will give up features for speed all the time. See git vs bzr/hg/svn/darcs/monotone,...

Hum, personally I've always found git having more features than those, though I don't know them all, at least when git released it distinguished itself by its features mostly, specifically the distributed nature and rebase. And hg/bzr never looked to me like they had more features, more so similar features +/-, so they'd be a good example of git has the same features+faster so it won.

I hate it but it's true. Look at me, my fridge as an integrated tablet that tells me the weather outside. Never mind that it is a lil louder and the doors are creaky. It tells me the weather!

And is your fridge within line of sight of a window? :)

Maybe for languages, but fast is easily left behind when looking for frameworks. People want features, people want compatibility, people will use electron all over.

> 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 "Hold up. What I'm currently using actually sucks. I'd better reconsider."

"Fast" is deemed important, but it isn't asked for as it is considered inconceivable that you wouldn't always make things "fast". But with that said, keep in mind that the outside user doesn't know what "fast" is until there is something to compare it with. That is how some products can get away with not being "fast" — until something else comes along to show that it needn't be that way.

"Look how quickly it can render the component 50 times!"

"Look, it can render the whole app really quickly every time the user presses a key!"

That gets into a very interesting question of controlled vs. uncontrolled components.

On one hand I like controlled components because there is a single source of truth for the data (a useState()) somewhere in the app, but you are forced to re-render for each keypress. With uncontrolled components on the other hand, there's the possible anarchy of having state in React and in the actual form.

I really like this library

https://react-hook-form.com/

which has a rational answer to the problems that turn up with uncontrolled forms.

That's neat, thanks for the link!

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).

It is only fast compared to a really dumb baseline. But you are right that the story of React being fast was a big part of selling it.

And yet we live in a world of (especially web) apps that are incredibly slow, in the sense that an update in response to user input might take multiple seconds.

Yes, fast wins people over. And yet we live in a world where the actual experience of every day computing is often slow as molasses.

The trouble is that "fast" doesn't mean anything without a point of comparison. If all you have is a slow web app, you have to assume that the web app is necessarily slow — already as fast as it can be. We like to give people the benefit of the doubt, so there is no reason to think that someone would make something slower than is necessary.

"Fast" is the feature people always wanted, but absent better information, they have to assume that is what they already got. That is why "fast" marketing works so well. It reveals that what they thought was pretty good actually wasn't. Adding the missing kitchen sink doesn't offer the same emotional reaction.

> you have to assume

We don't have to assume. We know that JavaScript is slow in many cases, that shipping more bundles instead of less will decrease performance, and that with regard to the amount of content served generally less is more.

Whether this amount of baggage every web app seems to come with these days is seen as "necessary" or not is subjective, but I would tend to agree that many developers are ignorant of different methods or dislike the idea of deviating from the implied norms.

The slow web app is probably still faster than the previous solution.

> The trouble is that "fast" doesn't mean anything without a point of comparison.

This is what people are missing. Even those "slow" apps are faster than their alternatives. People demand and seek out "fast", and I think the OP article misses this.

Even the "slow" applications are faster than their alternatives or have an edge in terms of speed for why people use them. In other words, people here say "well wait a second, I see people using slow apps all the time! People don't care about speed!", without realizing that the user has already optimized for speed for their use case. Maybe they use app A which is 50% as fast as app B, but app A is available on their toolbar right now, and to even know that app B exists and to install it and learn how to use it would require numerous hours of ramp up time. If the user was presented with app A and app B side by side, all things equal, they will choose B every time. There's proficiency and familiarity; if B is only 5% faster than A, but switching to B has an upfront cost in days to able to utilize that speed, well that is a hidden speed cost and why the user will choose A until B makes it worth it.

Speed is almost always the universal characteristic people select for, all things equal. Just because something faster exists, and it's niche, and hard to use (not equal for comparison to the common "slow" option people are familiar with), it doesn't mean that people reject speed, they just don't want to spend time learning the new thing, because it is _slower_ to learn how to use the new thing at first.

This is a disingenuous response because I made it plenty clear what I meant with "fast": interactive response times.

And for that, we absolutely do have points of comparison, and yeah, pretty much all web apps have bad interactivity because they are limited too much by network round trip times. It's an absolute unicorn web app that does enough offline caching.

It's also absurd to assume that applications are as fast as they could be. There is basically always room for improvement, it's just not being prioritised. Which is the whole point here.

I’ll tell you what fast is.

I’ve mentioned this before.

Quest Diagnostics, their internal app used by their phlebotomists.

I honestly don’t know how this app is done, I can only say it appears to run in the tab of a browser. For all I know it’s a VB app running in an ActiveX plugin, if they still do that on Windows.

L&F looks classic Windows GUI app, it interfaces with a signature pad, scanner, and a label printer.

And this app flies. Dialogs come and go, the operator rarely waits on this UI, when she is keying in data (and they key in quite a bit), the app is waiting for the operator.

Meanwhile, if I want to refill a prescription, it fraught with beach balls, those shimmering boxes, and, of course, lots of friendly whitespace and scrolling. All to load a med name, a drugstore address, and ask 4 yes/no questions.

I look at that Quest app mouth agape, it’s so surprisingly fast for an app in this day and age.

Molasses can be fast if you leave it in the packet and hurl it!

Seriously though, you're so right- I often wonder why this is. If it's that people genuinely don't care, or that it's more that say ecommerce websites compete on so many things already (or in some cases maintain monopolies) that fast doesn't come into the picture.

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.

Press enter.

Wait.

Wait for typing indicator.

Wait for cute text-streaming.

Skip through the paragraph of restating your question and being pointlessly sycophantic.

Finally get to the meat of the response.

It’s wrong.

What's sad is that I always open grok.com if it's a quick simple query because their UI loads about 10X faster than GPT/Gemini/Claude.

The claim was not that Rust was faster than C++, they said it’s about as fast.

C and C++ were and are the benchmark, it would have been revolutionary to be faster and offer memory safety.

Today, in some cases Rust can be faster, in others slower.

To a first approximation HN is a group of people who have convinced themselves that it's a high quality user experience to spend 11 seconds shipping 3.8 megabytes of Javascript to a user that's connected via a poor mobile connection on a cheap dual-core phone so that user can have a 12 second session where they read 150 words and view 1 image before closing the tab.

Fast is _absolutely not_ the only thing we care about. Not even top 5. We are addicted to _convenience_.

The fact that this article and similar ones get upvoted very frequently on this platform is strong evidence against this claim.

Considering the current state of the Web and user application development, I tend to agree with regard to its developers, but HN seems to still abide by other principles.

This kind of slop is often imposed on developers by execs demanding things.

I imagine a large chunk of us would gladly throw all that out the window and only write super fast efficient code structures, if only we could all get well paid jobs doing it.

It's not that they convinced themselves, but that they don't know how to do any better. It is as fast as it can be to the extent of their knowledge, skill, and ability.

You see some legendary developers show up on HN from time to time, sure, but it is quite obvious that the typical developer isn't very good. HN is not some kind of exclusive club for the most prestigious among us. It is quite representative of a general population where you expect that most aren't very good.

Reply on news.ycombinator.com