This is a submission for the GitHub Finish-Up-A-Thon Challenge
What I Built
toastr-next v3 a complete revival of CodeSeven/toastr, o...
For further actions, you may consider blocking this person and/or reporting abuse
Very cool
The accessibility gap you fixed is the one that always gets deferred β
role="alert"and live regions sound simple until you realize the original library had no awareness of the DOM announcement lifecycle at all, meaning screen readers were just silently ignoring every toast. I ran into the same thing auditing a component library last year: the visual experience was polished, but assistive technology users got nothing. Theawait toast.dismissedPromise API is a nice touch too β it closes the loop on a pattern where most notification libraries fire-and-forget and leave callers polling or guessing whether the user actually saw the message.Thank you, I really appreciate this! Accessibility definitely gets pushed to the backlog too often, so Iβm glad this fix resonated with you. And I'm thrilled you liked the Promise API hopefully, it saves developers a few headaches. Thanks for the kind words!
the jquery removal alone is probably half the value here. every "why is this still installed" conversation gets shorter.
Reviving a 12k star abandoned library is basically open source necromancy at this point π
Also love how the old setup was:
βimport all of jQuery to show one toastβ
Frontend in 2015 was truly built different π
Open source necromancy is the perfect way to describe it π I am just glad to finally lay the old jQuery dependency to rest!
Fantastic job! Stripping the jQuery-shackled classic down to a ~4KB pure, native TypeScript architecture is the ultimate cleanup of technical debt. From the CSS-first approach to the precise WCAG accessibility role tuning, it shows a profound respect for low-level detail. Reviving a legendary library with such elegance is a massive win for the ecosystem!
Great work rescuing this library! 12K stars is a serious signal that people rely on it. I've always appreciated toastr's simplicity β it just works without the complexity of modern notification solutions.
Curious about the migration path from v2 to v3 β did you find many breaking changes in the DOM structure or was it mostly TypeScript cleanup? And are you planning to keep the jQuery dependency or eventually drop it?
Followed to see where this goes! π
Appreciate the support and the follow! π To answer your question: jQuery is already dropped entirely! That was actually the main goal of v3.
Itβs now a pure, zero-dependency TypeScript rewrite (~4 KB gzipped). We switched to native CSS @keyframes for animations and vanilla JS for the DOM. It also ships with all modern builds (ESM/CJS, etc.) and a React hook right out of the box so it plays nicely with modern setups. Thanks for following along!"
That's even better than I hoped β zero-dependency TypeScript rewrite with React hook support means it's essentially a new library built on toastr's design DNA. The 4 KB gzipped size is impressive for what it does.
The ESM/CJS dual build is a nice touch too. Are you planning to publish a migration guide for existing v2 users, or is the API similar enough that most people can just swap the import?
Thanks! There's already a migration guide in the README with before/after diffs.
For basic usage it's close to a drop-in toastr.success("Saved!") works the same, and the DOM/CSS class names are unchanged so custom styling carries over. Just swap the import (CSS auto-injects now):
A few intentional breaking changes:
Calls now return a ToastInstance instead of a jQuery object
jQuery animation options replaced with a single animation preset
escapeHtml changed to allowHtml (HTML is escaped by default now)
subscribe() now returns an unsubscribe function
The guide explains each change.
I was in a similar spot with 'There's already a migration guide in the README with before/...'. What worked for us was lighter in-memory caching. Curious if you considered that?
Great breakdown of 'There's already a migration guide in the README with before/...'. Did you run into edge cases with production traffic? We sure did π
Not yet, but Iβm pretty sure some edge cases will appear once it gets real production traffic π
I also tried it by creating a CodeSandbox environment and it worked really well there.
Curious what kind of issues did you run into?
From 87KB of jQuery guilt to 4KB zero-dep TypeScript β this is exactly the kind of cleanup the ecosystem needed. Well done! π₯
Thank you! It was wild seeing just how much weight we could drop by switching to modern CSS custom properties and native Promises. Zero-dep was the hill I wanted to die on for this rewrite! π―
Great work man π₯
Thanks so much! π€ Couldn't have done it without GitHub Copilot π€
Well Explained!
Thanks, man!
Great I like itποΈ
Thanks Harsh!
Simple, highly customizable, non-blocking toast notifications.
Indeed!
Excellent write-up and execution.
Thanks a lot! Really appreciate you checking out the write-up. π
Thanks man!