5 ms·

> 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

by 9rx 1y ago

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

Dylan16807 1y ago
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.
- 9rx 1y ago
  > 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.
  - PaulHoule 1y ago
    "Look how quickly it can render the component 50 times!"
    - tobyhinloopen 1y ago
      "Look, it can render the whole app really quickly every time the user presses a key!"
      - PaulHoule 1y ago
        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/ https://react-hook-form.com/ which has a rational answer to the problems that turn up with uncontrolled forms.
        tobyhinloopen 1y ago
        That's neat, thanks for the link!
  - timeon 1y ago
    Isn't React one of the slower frameworks? https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
    - dmix 1y ago
      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).
  - NohatCoder 1y ago
    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.
atq2119 1y ago
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.
- 9rx 1y ago
  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.
  - lblume 1y ago
    > 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.
    - philipwhiuk 1y ago
      The slow web app is probably still faster than the previous solution.
  - renlo 1y ago
    > 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.
mvieira38 1y ago
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
- lukevp 1y ago
  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.
  - sebmellen 1y ago
    Sublime Merge gets you all those benefits, PLUS it’s really fast!
  - jeremyjh 1y ago
    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.
- SchemaLoad 1y ago
  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".
- 0wis 1y ago
  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.
underdeserver 1y ago
Eh, I think the HN crowd likes fast because most tech today is unreasonably slow, when we know it could be fast.
- RandomBacon 1y ago
  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.
  - FridgeSeal 1y ago
    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.
  - qingcharles 1y ago
    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.
asa400 1y ago
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_.
- lblume 1y ago
  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.
- alt227 1y ago
  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.
- 9rx 1y ago
  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.
didibus 1y ago
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.
- emmelaich 1y ago
  Really not sure about that. People will give up features for speed all the time. See git vs bzr/hg/svn/darcs/monotone,...
  - didibus 1y ago
    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.
- gherkinnn 1y ago
  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!
  - willvarfar 1y ago
    And is your fridge within line of sight of a window? :)
blub 1y ago
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.

by 9rx 1y ago

Dylan16807 1y ago

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.

9rx 1y ago
> 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.
- PaulHoule 1y ago
  "Look how quickly it can render the component 50 times!"
  - tobyhinloopen 1y ago
    "Look, it can render the whole app really quickly every time the user presses a key!"
    - PaulHoule 1y ago
      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/ https://react-hook-form.com/ which has a rational answer to the problems that turn up with uncontrolled forms.
      - tobyhinloopen 1y ago
        That's neat, thanks for the link!
- timeon 1y ago
  Isn't React one of the slower frameworks? https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
  - dmix 1y ago
    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).
- NohatCoder 1y ago
  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.

atq2119 1y ago

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.

9rx 1y ago
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.
- lblume 1y ago
  > 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.
  - philipwhiuk 1y ago
    The slow web app is probably still faster than the previous solution.
- renlo 1y ago
  > 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.

mvieira38 1y ago

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

lukevp 1y ago
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.
- sebmellen 1y ago
  Sublime Merge gets you all those benefits, PLUS it’s really fast!
- jeremyjh 1y ago
  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.
SchemaLoad 1y ago
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".
0wis 1y ago
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.

underdeserver 1y ago

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

RandomBacon 1y ago
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.
- FridgeSeal 1y ago
  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.
- qingcharles 1y ago
  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.

asa400 1y ago

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

lblume 1y ago
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.
alt227 1y ago
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.
9rx 1y ago
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.

didibus 1y ago

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.

emmelaich 1y ago
Really not sure about that. People will give up features for speed all the time. See git vs bzr/hg/svn/darcs/monotone,...
- didibus 1y ago
  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.
gherkinnn 1y ago
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!
- willvarfar 1y ago
  And is your fridge within line of sight of a window? :)

blub 1y ago

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.