[HN Gopher] Building a Toast Component
       ___________________________________________________________________
        
       Building a Toast Component
        
       Author : FragrantRiver
       Score  : 74 points
       Date   : 2025-12-03 14:51 UTC (4 days ago)
        
 (HTM) web link (emilkowal.ski)
 (TXT) w3m dump (emilkowal.ski)
        
       | anilakar wrote:
       | Scrolling that web site on mobile is really choppy.
        
         | tpetry wrote:
         | Perfectly smooth on iOS for me.
        
         | urban_alien wrote:
         | VERY laggy on Android FF.
        
         | leosanchez wrote:
         | Perfectly smooth on Android FF.
        
         | slig wrote:
         | Exploded my mobile browser on Android.
        
         | onion2k wrote:
         | Looking at the replies to your comment makes me think that
         | _maybe_ the browser software isn 't the only factor that
         | impacts website perf.
        
       | robin_reala wrote:
       | Meanwhile, GitHub is removing Toasts from Primer, their design
       | system.[1] They're next to impossible to implement in a way that
       | retains accessibility across all needs, and if you try to
       | restrict their usage to places where accessibility doesn't matter
       | so much (simple ephemeral confirmations) people misuse them
       | anyway.
       | 
       | It's notable that accessibility isn't mentioned once in this
       | post, or, in fact, in the component's documentation.
       | 
       | [1] https://primer.style/accessibility/toasts/
        
         | CharlesW wrote:
         | > _It's notable that accessibility isn't mentioned once in this
         | post, or, in fact, in the component's documentation._
         | 
         | It's a red flag for sure. That said, there's nothing preventing
         | toasts from being accessible: https://react-
         | spectrum.adobe.com/react-aria/useToast.html
         | 
         | I think it would be accurate for GitHub to say, "GitHub no
         | longer uses toasts because _we didn 't want to make the effort_
         | to make them accessible or usable."
        
           | thunderfork wrote:
           | I think that toasts are kind of an attractive nuisance when
           | it comes to accessibility.
           | 
           | They can technically, with ample constraints and a great deal
           | of restraint, maybe end up complying with WCAG, etc., but all
           | it takes is one developer saying "well a toast is easy" or
           | "this isn't that important, make it auto-dismiss" and you're
           | back in bad pattern town.
           | 
           | You see this with government web design systems - they have a
           | very limited and constrained palette of patterns, because it
           | allows for more consistency and _reliable_ accessibility,
           | versus having a bunch of tools that you just generally
           | shouldn 't use.
           | 
           | (The GitHub page linked above also makes a great case for how
           | "making toasts accessible" isn't as simple as just having the
           | right aria roles - lots of details the Adobe design doesn't
           | seem to completely cover, unfortunately)
        
           | robin_reala wrote:
           | Spectrum's Toast docs don't mention how they make Toasts
           | accessible with screen magnifiers (more widely used than
           | screen readers based on the last WebAIM surveys I saw), so I
           | guess they didn't consider them?
        
         | chipheat wrote:
         | Not too hopeful with accessibility, as it isn't pleasant to use
         | at all with reduced motion enabled. They flicker when added and
         | linger around when swiped away.
        
       | jmercouris wrote:
       | Toasts are a great way to lose information. They are a terrible
       | design and should not be used. They distract the user, are not
       | dense with information, and provide no value. If a message is
       | important enough for the user to read, it should be a dialog box.
        
         | oulipo2 wrote:
         | Most of the time they're used for a quick visual confirmation
         | that "your operation went right"
        
           | jmercouris wrote:
           | The information that the user did something "right" should be
           | responsive next to where the user initiated the action- not
           | in a random corner.
        
             | nine_k wrote:
             | That control may not be visible by the time the operation
             | completes.
        
           | tyre wrote:
           | That's why confetti exists
        
         | ahallock wrote:
         | Developers reach for Toasts because they're zero effort. Good
         | user experience takes a lot of thought and you can skip all
         | that with Toasts haha.
        
           | robin_reala wrote:
           | Zero effort, _and they animate_. Components that have
           | animation baked in are drug-like in how they hook in
           | designers and devs who are only thinking about the visual
           | presentation.
        
         | jopicornell wrote:
         | Dialogs are a great way to lose information. They are often
         | dismissed by users that want to do their job and are
         | interrupted by modals. Users focused on their tasks blindly
         | dismiss dialogs.
         | 
         | Read the above as a critique to your strong opinion and not an
         | opinion of mine.
         | 
         | My opinion is that toasts are great for notifications that can
         | be reviewed/checked later, like chat notifications or finished
         | background tasks.
         | 
         | What should be avoided, just for the same reason as
         | modals/dialogs, is an overuse, causing fatigue.
        
           | mhitza wrote:
           | Dialogs don't have to be modal, and in the parent comments
           | context they aren't.
        
       | varun_ch wrote:
       | I'm far from a UX designer but whenever I use something with
       | toasts I feel like I don't notice them pop up in my periphery. I
       | think it would be better if the confirmation for an action I did
       | just showed up wherever I performed that action (like a button
       | changing state to a spinner and then either an error or a
       | confirmation)
        
         | hungrymagnum wrote:
         | This can be applied for a success (change the button to a green
         | tick mark) or an unsuccessful action (change the button to a
         | red x mark).
         | 
         | But what if you want to give details on why the action was
         | unsuccessful? How do you show it near the button or change the
         | button itself?
        
       | Waterluvian wrote:
       | Despite being the first point made, i feel that it's likely the
       | name didn't contribute to its success, and possibly worked
       | against it. It's not discoverable and it doesn't tell the reader
       | much of anything. It's the kind of name you get away with when
       | your product is established by other means.
        
       | nine_k wrote:
       | > _While I'm sacrificing discoverability and clarity, it feels
       | elegant to me_
       | 
       | Sigh. So much of modern "UX design" seems to be lured by this
       | siren call :(
        
       | djbarnwal wrote:
       | This was a great read!
        
       | jgalt212 wrote:
       | > It's now downloaded over 7,000,000 times per week
       | 
       | Why do all these packages have so many downloads? Are all the CI
       | / CD routines always downloading a fresh copy and not caching?
        
         | mmarvin wrote:
         | Yes, exactly that's the case.
        
       | araes wrote:
       | Was really hoping it was an article about making electronics out
       | of fried bread products. "With electrodes wired to our margarine
       | covered breadboard we were able to accomplish ... "
        
       ___________________________________________________________________
       (page generated 2025-12-07 23:00 UTC)