Help & Support

I understand that some companies can't sponsor open source software for various reasons and require a commercial license for invoicing purposes. For those users, I'm happy to offer commercial support licenses in lieu of a sponsorship. Please message me on X or Bluesky for more information.

Yes. You can sponsor Quiet on GitHub to unlock access to a sponsors-only discussion forum where you can get help directly from me, the maintainer, as well as other members of the community. I typically respond within 24 hours.

I will always do my best to help you and I typically reply within 24 hours. However, a sponsorship doesn't guarantee that I'll be able to fix your problem every time.

I prioritize bug fixes that affect sponsors first. I try to submit fixes quickly, but some bugs are tricky and require more time, research, etc. I will communicate my progress with you so you're always aware of what's happening.

The forums are located here. Please note that the page will appear as a 404 error unless you're an active sponsor!

You can cancel your sponsorship through the GitHub Sponsors dashboard, but you will lose access to all sponsors-only benefits when your sponsorship period expires. Unfortunately, GitHub Sponsors does not provide a way to issue refunds.

Bugs should be reported on GitHub. You do not need to be a sponsor to report a bug, but priority is given to sponsors. For best results, please include a minimal reproduction with your report.

Features can be requested on GitHub. You do not need to be a sponsor to request a feature. Please search before posting to prevent duplicate requests and use the 👍 reaction to vote.

I generally don't accept sponsorships for specific features. This lets me focus on what's best for the project. That doesn't mean I ignore feature requests — it means I'm not willing to let money influence the roadmap.

Quiet is the result of many years of experience and my commitment to painstakingly curate the project. I want people to sponsor it because they see the vision, not because they want to change it.

Framework SSR was created to solve problems introduced by client-side frameworks. When we moved to rendering everything with JavaScript, we broke SEO, social media previews, and page load performance. While framework SSR can be helpful in some scenarios, it's often misused to justify shipping massive JavaScript bundles that leave pages looking ready but completely unresponsive until everything loads and hydration completes.

The idea behind framework SSR is that fetching and hydrating can be done in the background before the user is likely to interact with the page. As such, it first sends the user a "fully painted" picture they can't actually do anything with while waiting for the browser to download and process a multi-megabyte bundle. However, it's become common to see 5+ seconds until TTI in the wild, leaving many users confused and frustrated.

Quiet isn't interested in supporting the framework SSR fallacy. As part of the platform, web components can be server-side rendered traditionally like all other HTML elements have since the early days of the Web. Just generate the appropriate HTML tags, import the components, and you're good to go.

If you're using Quiet's autoloader, it will only fetch the components you're actually using on the page. And to eliminate FOUCE, the most common reason people reach for SSR when using web components, Quiet provides some simple and effective tools.

The key to a great experience on the web isn't SSR, it's less JavaScript. If you're of the belief that you need framework SSR and all the needless complexity it brings to a project, this library isn't for you.

Component tag names, e.g. <quiet-button>, cannot be changed without modifying the source code due to the way tags are referenced in code and styles. Attempting to change tag names, e.g. by extending the associated classes, will cause unexpected breakages and isn't a supported feature of the library.

While components are written as classes, they aren't designed to be subclassed. This is not supported and isn't an objective of the library. Instead, use composition when possible.

Because custom elements are registered globally, I don't recommend using Quiet in a micro frontend architecture unless you move it to the top of the stack. Avoid loading the library multiple times, as this will cause version conflicts and load more code than is necessary.