I tried to open different themes in tabs for comparison, but I would have to first open each one and then manually copy the URL into a new tab because you implemented your links as <button> (which prevents both middle-click and 'open in new tab' context menu option to work).
Yup, this is the incompetence that we see all over the place since these new frameworks have come and front end devs have no idea what HTML actually is or how it works.
Buttons are for submitting forms and nothing else.
In HTML a link is created using an <a> element.
React has a <Link> element for this purpose, it will be rendered as <a>.
Please OP, at least try to learn a little bit about the underlying technologies.
I get this. Just shipped the ability to create and edit themes locally, no auth required. The local theme gets persisted to localstorage and you can optionally save/share it later. It also works seamlessly with the fork / import features, so those can be used without auth as well.
Email magic links are dumb. On top of that, forms that don't let you specify whether to login or to create an account are extra dumb. With magic links, one can't log in with just their password manager, and with a stupid combo form, anyone who mis-types or mis-remembers their email address just accidentally created a new account (or a new link that creates an account).
Email magic links are inconvenient for the user, but they're not dumb. They're a pretty good option for a small project by a developer doesn't want to implement a whole auth flow, or pay for an OAuth provider.
It's a tradeoff. If you roll your own password flow, you need to add MFA to be secure. The complexity of what you need to build and maintain goes up.
A simple magic link flow for an app like this, where you are really only likely to log into it once per project you start.
Personally though, I also use a password manager. And I am annoyed enough by email magic links, that any of my personal projects will at least have a passkey implementation.
So I agree they're annoying. But they're definitely not "dumb". They're a tradeoff. This developer has chosen his own time over user convenience; which is a common tradeoff for small developers.
The problem with magic links is that the secret is sent with each login attempt. It's just like SMS verification codes - an attacker that controls the email address, or the phone number, can log right in. In this case, probably without even resetting a password. Plus, with no way to verify the account owner other than the email address, if the email address is lost or changed, the account's as good as gone.
Also yes they're super annoying for the user too. It's inconvenient and less secure.
We are on the same page about magic links. Email is also not a super-reliable medium of communication. Email can arrive straight into the junk mail, late, or even never. I think magic links should be strongly discouraged for serious projects, businesses, and government. Passwords and application-based MFA (not SMS or Email MFA) or webauthn/passkeys are much better.
This whole discussion started when @meindnoch wrote ">Sign in or create an account with your email. Into the trash it goes.".
I think magic links are acceptable for a small solo developer project. Expecting a solo developer so shoulder the burden of rolling their own auth, paying for an auth service, or self-hosting an containerised auth-service and wiring their application to it is a bit much for a tiny project like this.
Anything more than a small solo project should graduate to a better solution- I hope we can all agree with that.
As opposed to username/password, where... An attacker that controls the email address can log right in.
Unless you mean to say I should set up 2FA for my CSS theme variable helper website?
Passkeys and OAuth/social login are great, but everyone has an email. And I don't think any mainstream site supports only passkey as an auth method (and no other way).
"Passkeys and OAuth/social login are great, but everyone has an email"
big tech is only allowing Social login from another big tech anyway, they use whitelist and banning everyone that dont use that because they cant guarantee untrusted "third party"
Tweakcn is a great tool too. Main difference is I'm hoping ShadcnThemer will be more of a community-driven hub for sharing, starring, and forking themes - similar to how color palette websites have 1000's of user-made palettes. (I took this approach when building the Theme Studio for VS Code and it worked really well, 1000's of themes were designed and shared.)
Tweakcn also charges $ users to be able to share and save themes which I think is silly for a tool like this, should be 100% free and open source.
I also prefer the simple UX of ShadcnThemer better but I'm biased of course.
Not related to this directly, but shadcn drawer is built on the top of vaul which is unmintained, so who ever use this in production, keep this in your mind.
The only changes I see are colors but what if I want eg a different border radius on buttons or margin on labels or specific fonts on elements etc? I don’t find changing only the colors of components particularly valuable but would like to see more variance in the actual shapes and looks of things.
Global border radius is editable, that setting is at the bottom of the sidebar. The challenge with global shadcn theming is that you're limited to adjusting the css variables they provide. I believe there is a global spacing variable, but it is not so specific that you can target e.g. just label spacing. That would be something you could modify directly within your shadcn input components via adjusting the tailwind class(es).
I spent some time attempting to "derive" a theme given a primary and secondary color, but realized my color theory wasn't strong enough to build something reliable (I tried with both hsl and oklch). Curious if that's really possible.
I still can't believe this is still an issue. When lazy-loading/infinite-scroll appeared main problem was that your footer shouldn't contain any actionable information. And people still makes fall into the same issue years after.
I'm being very pedantic here in true HN fashion, but at most it's the default UI of VC-funded B2B SaaS startups. 95% of the internet-using world never comes across shadcn UIs.
Buttons are for submitting forms and nothing else.
In HTML a link is created using an <a> element.
React has a <Link> element for this purpose, it will be rendered as <a>.
Please OP, at least try to learn a little bit about the underlying technologies.
Also, React does not have a Link element. Please at least try to learn a little bit about the underlying technologies.
Into the trash it goes.
It's a tradeoff. If you roll your own password flow, you need to add MFA to be secure. The complexity of what you need to build and maintain goes up.
A simple magic link flow for an app like this, where you are really only likely to log into it once per project you start.
Personally though, I also use a password manager. And I am annoyed enough by email magic links, that any of my personal projects will at least have a passkey implementation.
So I agree they're annoying. But they're definitely not "dumb". They're a tradeoff. This developer has chosen his own time over user convenience; which is a common tradeoff for small developers.
Also yes they're super annoying for the user too. It's inconvenient and less secure.
Passkeys are awesome, yeah.
This whole discussion started when @meindnoch wrote ">Sign in or create an account with your email. Into the trash it goes.".
I think magic links are acceptable for a small solo developer project. Expecting a solo developer so shoulder the burden of rolling their own auth, paying for an auth service, or self-hosting an containerised auth-service and wiring their application to it is a bit much for a tiny project like this.
Anything more than a small solo project should graduate to a better solution- I hope we can all agree with that.
Unless you mean to say I should set up 2FA for my CSS theme variable helper website?
Passkeys and OAuth/social login are great, but everyone has an email. And I don't think any mainstream site supports only passkey as an auth method (and no other way).
big tech is only allowing Social login from another big tech anyway, they use whitelist and banning everyone that dont use that because they cant guarantee untrusted "third party"
True, every login must be standardized around social auth and oauth2
edit: would also love to be able to open preview on new tabs with middle-click.
Tweakcn also charges $ users to be able to share and save themes which I think is silly for a tool like this, should be 100% free and open source.
I also prefer the simple UX of ShadcnThemer better but I'm biased of course.
this is why ecosystem that stable like Go is better for vibe coding
Footer links:
GitHub repo https://github.com/miketromba/shadcn-themer
Three other links also in the footer but they only bring me to login screen:
Terms of Service https://shadcnthemer.com/terms
Privacy policy https://shadcnthemer.com/privacy
Contact https://shadcnthemer.com/contact
https://ui.shadcn.com/
Not sure why this upsets people, is it because it's popular and therefore bad?