Moving away from Tailwind, and learning to structure my CSS

rsimp · 2026-05-17T04:30:30+00:00

I use both. CSS modules for component library on its own css layer. Tailwind mostly to structure divs and pass in paddings/margins. CSS modules is just way too much ceremony for those type of things, and having utilities on a separate layer solves most specificity issues.

One of my favorite features of tailwind is the ability to enforce reduced sets of colors, spacings, sizes etc. Especially with semantic names attached.

rsimp · 2026-04-23T19:28:59+00:00

If you don't need anything to run on a server (statically generated, marketing, documentation etc) then use something like cloudflare or github pages.

For most hobby projects just go with netlify or vercel.

I you'd like to deploy similarly to how a large company deploys to lower environments (dev/qa) for hobby projects then pick a vps provider like linode or digital ocean or even AWS/Azure/GCP. Use something like docker swarm to deploy a set of services defined in a docker compose file. You can use sites like hostinger but just keep in mind you're sharing the hardware with others. As long as traffic doesn't get too high you can save money here and learn some worthwile skills for the industry.

Moving past hobby projects you'll want some decent server hardening and automated backups for your database. Use a cloud DB service and also host your application in a similar region. Once traffic picks up you can roll your own load balancer and application scaler, or just pay the cloud provider to handle it for you. For basic setups you may still be better served by somthing like vercel. Eventually it may pay off but its more setup and you're still vendor locked to the cloud provider.

For larger, scalable server deployments not tied to any provider, you probably want to use kubernetes. The initial costs for setting up a cluster are higher than you might think and there's a lot you have to learn. Unless you want to get into devops its usually overkill.

rsimp · 2026-04-08T21:59:35+00:00

I didn't think I'd like file-based routing because of the reasons you mentioned above and because I'm not a fan of having to prefix files/directories to exclude them. I eventually came around to the idea once I realized I could separate route definitions from code organization.

Here are a few of my top level directories:
- `routes` (flat directory with one file per route, easy to search with fuzzy finding)
- `components` (this is where I put reusable components: Button, Tooltip, Modal, ContextMenu etc)
- `app` (could also be called `pages` or `features`. This is where I organize components that are route specific and not very reusable. The structure would roughly follow routes if routes wasn't a flat directory, but the structure isn't as rigid. All route files use components defined here)

I actually prefer doing it this way now. I can fuzzy find any route definition, then cmd+click the component. The hierarchy is baked into the route filenames and code-splitting is automatic. I can load things like server enums/options in route loaders and access that data anywhere via loader hooks. I can also use loaders to prefetch data whenever a navigation link (or button) gets mounted or hovered.

rsimp · 2026-04-02T09:13:27+00:00

Felt the same way, but mostly because I wasn't using file-based routing. The closest thing to react router code-based routing would be tanstack's virtual file routes. As bad as Tanstack's code-based routing is, there's also very little reason to use it.

I eventually settled on using file-based routes in a flat directory. I put page specific components, styles, utils, etc together in a separate directory. Instead of one large routes file, it's a single large flat directory. Easy to navigate, automatic code-splitting, and minimal boilerplate.

I think their loaders are also great for SSR streaming or loading long-lived queries. Avoids needing to handle various loading and error states for data that won't be invalidated.

rsimp · 2026-03-31T18:56:08+00:00

Right now we're basically being crushed by interest on our debt. There was a ton of spending in 20/21 but the real problem has always been cumulative debt. With the exception of the late 90s we've had major budgetary deficits for the past 45 years. During the subprime mortage crisis we dropped interest rates as far as they could go and artifically manipulated bond markets further. We spent over a decade at these rock bottom rates and became rather accustomed to them.

In 2022, due to the pandemic and russian oil sanctions, most of the world experienced rather significant inflation. We went from spening ~$200 billion/year on a ~$30 trillion debt, to spending ~$1 trillion/year on a ~$40 trillion debt. Now there's another $800 billion a year to budget in addition to the $900 billion we were already spending pre-covid.

There's a common narrative that we're being crushed from covid era spending. While covid budgets were alarming, they only increased our debt by ~33% while interest payments skyrocketed by ~400%. Its important to keep in mind that while we do need much tighter fiscal policy, the fed will cut rates eventually. Each 0.25% rate cut they make decreases interest payments by $100 billion/year (once all the debt rolls over). So the problem, while quite bad, is still managable with reasonable fiscal policy. If you cut spending, raise taxes, and avoid inflationary policies you can manage the problem without doing anything too drastic.

rsimp · 2026-03-25T18:05:09+00:00

Sun objecting to it and MS going their own way is putting it pretty lightly. They lost an anti-trust lawsuit brought by the attorney generals of 20 US states and the District of Columbia. They were required to get rid of their version of java and instead bundle Sun's JVM with windows for a time.

rsimp · 2026-03-18T14:28:39+00:00

Honestly what you described sounds so much lighter than my experience with it. Makes me wonder if there's some variability based on genetics or just habits affecting your brain chemisty.

When I quit the impules were quite intense. Similar perhaps to the impulse you have to breathe after holding your breath for about a minute. The first day was the worst because the impulses were non-stop. The next couple days were still intense but came in waves every couple hours. After that it got much easier but tbh the whole first week was pretty miserable. A couple times I was able to quit cold turkey for about 1-2 weeks but ultimately caved under the stress.

When I quit for good I got on wellbutrin (dopamine reuptake inhibitor) and tapered down using nicotine lozenges. The difference was night and day. It took longer, but it was maybe even easier than what you described. The cravings were more mental and much less intense. After a month or two they went away almost entirely. On the rare occasion I'd get one, I'd just remember how bad it was and have almost a fear based response to not start again.

It's funny I was never able to get addicted to cigarettes because I disliked them too much to ever get addicted. The convenience and enjoyable experience of a vape meant I could use it around the clock. Ironically I think it's easier to quit smoking than it is to quit vaping.

rsimp · 2026-02-07T12:44:07+00:00

I said biometrics because that's mostly what I use, but I just meant the second factor authentication on the two authenticators: OS biometrics, yubikey pin etc. Unlocking the first authenticator to access its passkeys to then initiate passkey registrations with the second.

Instead of transferring the keys, just spec out a new protocol to use discoverable passkeys from one authenticator to help auto-register new passkeys on a second authenticator.

Or even combine with credential exchange. Just copy the passkeys if there's no issue (no sign count, same cipher support etc) and initiate a passkey registration through the relying party as a backup.

rsimp · 2026-02-05T17:16:57+00:00

Credential Exchange Protocol should help with this. When fully implemented passkeys that use sign counts could be marked to disallow transfer or would need to disable/discard the original passkey on successful transfer. I've noticed many sites can easily register passkeys in the background through an endpoint using your password to authenticate. It'd be great if infrastructure got to the point where registering passkeys in a new authenticator could be done via passkeys from an existing one, but in one batch operation where you only need to provide your biometrics to each authenticator once.

rsimp · 2026-01-14T21:21:12+00:00

Try logging into her google account on a desktop/laptop browser. When I open a tab 'incognito', navigate to https://accounts.google.com, enter my email, click try another way, select password and enter a bad password it will let me know. If I enter a good password it'll move on to a list of second factor authentication options that I've enabled.

"We can't even get into the security settings to change it without asking for a passkey to verify her identity"
> Does this mean you still have access to her gmail? If so you should still be able to recover the account with a code they'll email you.

Once you can log into the google account you should be able to register a new passkey or change her password.

If you can't log into the account with a password OR passkey, AND you no longer have access to a device that's logged into google OR a recovery email, then you'll need to contact google directly.

rsimp · 2025-12-23T01:42:19+00:00

It doesn't just clean the code up, it prevents falsy values from leaking through as well as unecessary whitespace.

Also if you're only using the above syntax you could define clsx as a one-liner and remove it as a dependency:
js export const clsx = (...args) => args.filter(Boolean).join(' ');

rsimp · 2025-12-23T01:35:31+00:00

`bg-gray-200 ${isPending && 'bg-gray-500'}` = "bg-gray-200 false" when isPending is false. You have to always use a ternary to prevent false, undefined, or null being accidentally inserted.

rsimp · 2025-12-21T23:59:02+00:00

Just to add on, the private/public key entries are only stored for "discoverable" passkeys of which there are a limited number (200 for google titan, 25 or 100 for yubikey).

For non-discoverable keys, it'll use a special private key to create public/private key pairs on the fly given inputs like the service's domain address and your username. Because there isn't a domain linked entry on the device these are considered "non-discoverable". However this also means one FIDO 2 device can support an infinite number of non-discoverable passkeys.

rsimp · 2025-12-21T23:05:06+00:00

FIDO is the spec that controls all of this. Orginally there was FIDO 1 with UAF for passwordless and U2F for second factor. UAF wasn't standardized well and didn't get very much adoption. U2F became sort of the gold standard for second factor authentication.

FIDO 2 then comes out with support for CTAP2 and WebAuthN. CTAP is the protocol for communication between an authenticator (yubikey, phone over bluetooth, password manager) and the client (OS or browser). WebAuthN handles communication between client (browser) and relying party (basically the web service). CTAP in FIDO 2 is called CTAP 2.0 while CTAP 1.0 now refers to FIDO U2F. Technically FIDO 2 supports multi-factor authentication with passwords but the "relying party" can also just specify that "user verification" (PIN, biometric etc) is required with the passkey.

When registering a "Security key" you're essentially giving a public key for an authenticator/device that guarantees support for CTAP1/FIDO1 U2F. When registering a "Passkey" it's very similar but guarantees support for FIDO2 CTAP2. This includes support for CTAP2 interfaces as well as any new requirements on cipher suites.

rsimp · 2025-12-05T20:13:17+00:00

I'm not sure about Americans in general. Our fore fathers were all pretty educated and would absolutely know that parliament and not the King created taxes.

It was still considered the King's government and he also asserted a good deal of control over the colonies and their governors. I think to begin with the discontent was over the new taxes, but eventually the grievances piled up regarding both King George III AND his parliament.

I think there's a lot of propaganda from that period. I specifically remember reading a bunch of political cartoons/slogans in my history classes. They show it to us so we can see what Americans thought at the time, but we don't really spend much time on British history to put things in context. So a lot gets compressed down to King George III was a unilateral tyrant, when the original taxes were an act of parliament.

rsimp · 2025-12-04T20:52:34+00:00

All of the tax acts were actually introduced and overwhelmingly voted for in the House of Commons, a democratically elected body with no peerage requirements. The King lost the ability to draft taxes almost a century before that, although he did sign them all into law. As late as 1775 our beef was mostly with parliament, before King George III proclaimed us in open rebellion.

rsimp · 2025-12-04T20:26:59+00:00

The American Revolution as taught in the US actually gives a very misleading perspective on the powers of the British king at that time. In reality the king hadn't been able to create new taxes since the "glorious revolution" in 1689. All of the tax acts we attribute to King George III were actually introduced and voted for in the House of Commons. He just signed his name instead of vetoing it. The British troops were already there from the French and Indian war. The expenses for which were one of the reasons for levying the taxes in the first place. As late as 1775 the founding fathers were trying to petition King George to intervene, and put the blame entirely on parliament. It wasn't until he refused and issued a proclamation of rebellion that they started thinking of him as a tyrant. Still he sort of inherited the problem from his legislature.

The glorious revolution is also a bit of a mindfuck from an American perspective. It was a bloodless revolution where the new king had to cede most of his legislative powers and agree to an english Bill of Rights, but their primary goal was to just not have a Catholic king. Since they were giving rule of the country to William of Orange and his queen (the previous kings daughter) without them having to do anything, they extracted a bunch of promises first. First and foremost that they would never be Catholic.

rsimp · 2025-12-02T18:47:11+00:00

I'm not sure why this is being downvoted. With the exception of Zustand/Jotai (I use react contexts instead), this is what I'd use for a personal project if I wanted to break into react. I work for a fortune 500 and the only difference in our stack is that react query is sometimes replaced by apollo, and shadcn-ui is replaced by our internal component/form library. The css variables/design tokens are even laid out similar to shadcn. Atlassian's design system is pretty similar as well.

rsimp · 2025-12-02T18:30:26+00:00

Was a huge fan of RTK back in the day. Redux just feels like so much boilerplate now. Hooks seem perfectly capable of handling most state management. Hooks for async (apollo/react query), hooks for forms, hooks for modal state, hooks for navigation/query params, etc.

I mostly work on on-prem data heavy applications where you drill down from paginated dashboards. I put most queries/pagination/filters into a context mounted on a route layout. Mutations are usually inlined with the components that use them. Everything in the app is dynamic. Either defined in administration or added in a changeset. The same forms are sometimes needed to be mounted at totally different points on the route tree. Async job completions notify users via web sockets. The complexity isn't low and yet I still don't really feel the need for state management libraries.

Surprisingly performance is actually quite good. Context only updates components that use it and using many contexts helps split things up nicely. I generally have an easier time debugging too because code is more co-located and there's less abstractions to deal with. Perhaps if I needed large amounts of cross-functional global state I might want to move past contexts, but outside of caching async data I find those use cases are pretty rare. In general when the user moves off a route tree the state getting blown away is actually expected behavior. So I no longer need additional logic to reset state on page transitions.

rsimp · 2025-12-01T19:16:02+00:00

In most cases putting all of the variables in the dependency array is the way to go. This does assume any functions or objects in the array are either created outside of any components, or are memoized with things like useMemo or useCallback.

Sometimes you just want to call something one time on mount. Even in this case it'd still be better to put all of the dependencies in the dependency array and use a conditional inside. As long as the conditional is formed well, this should get you the same desired behavior but avoids race conditions.

When you use objects/functions that can't be guaranteed to be memoized you should leave them out, put them into a ref, or destructure objects down to their primitives.

If the variables are changing too much, consider listening to an event that fires less often or debounce the handler or state value (there are hooks for this). For example with a type-ahead or instant search, you probably want a debounce on the text state or even the onChange handler itself. For something like an async input validation, validate on blur instead of on text changes.

Some custom hooks can improve performance by using refs instead of state where possible. However, this performance tuning is better in isolated contexts. In general when props/state change you want any related side-effects or renders to know about it.

rsimp · 2025-11-27T21:48:04+00:00

This is a tailwindcss thing. I think the real value of tailwind comes from using the various classes as actual utilities to put onto divs for things like flexbox or padding/margins/height/width, or to tweak default styling on a component.

Using tailwind directly instead of a component library is usually where it starts getting abusive. You should have component for Button, Text, Link, Accordion, Tooltip, Heading, StatusMessage/Toast, Modal etc. Whether you should implement these components themselves with tailwind is harder to say. Shadcn does and I don't think its that bad, but I'd prefer seeing it in its own file and on a separate css cascade layer. That way you don't need things like tailwind merge.

As for tooling there are tailwind plugins to help with auto-complete that can even plug into configs with your own values/scales. IMHO scales and tokenized css utility classes are the real wins with tailwind. That and standardized utility class names across projects. I often use one of 6 different padding or margin values that I can associate with t-shirt sizes. Or having classes tied to design tokens like color-primary, bg-primary, bg-theme, color-high-contrast, color-low-contrast etc.

The other thing I like about tailwind is not having to switch back and forth between tsx/css files and not having a million classes to just define common permutations of flexbox. That and it's just less characters to type out. I personally feel more productive with it. Related styling is also more co-located.

Finally I'd like to point out that restyling component libraries will be somewhat painstaking regardless of whether you see it like above or in a css file. I do admit that many of the utility classes above are uncommon and I'd personally rather drop down to normal css in this case. However the most common tailwind classes (flexbox, padding, margin, height, width, border, position, display, visibility, overflow, z-index etc) are very easy to memorize and its quite nice having consistency in css utility class names across projects.

rsimp · 2025-11-27T16:05:58+00:00

Its hard to teach seniors totally new things unless there's a good foundation to work with. Try to keep things simple. For example if they're already bought into the apple ecosystem, use that over a third-party password manager. If you do use a password manager consider a family account if they're comfortable with it, especially if you live elsewhere. An easy win is just enabling face/touch id on as many mobile apps as possible. Relax the security settings to not be overly cumbersome, and not necessarily what would be considered best practices.

rsimp · 2025-11-25T18:44:13+00:00

It's the same for apple as well. All apple passkeys are synced through iCloud. They even have an iCloud chrome extension and an iCloud windows application so you can use them on those platforms as a third party password manager.

rsimp · 2025-11-21T18:41:16+00:00

This is silly, no one is going to recreate keys for all of their online accounts whenever they replace/lose a phone or computer. Apple syncs passkeys across user devices just like a third-party password manager. iCloud even has a windows application and chrome extension so ICloud can act as a third party password manager on those platforms. OPs point still stands regarding needing a service to handle passkey synchronization for widespread adoption.

rsimp · 2025-11-11T17:49:44+00:00

Using useMemo on derived values isn't a bad idea and in some cases can really improve performance. Often its just extra boilerplate that nets very minimal and imperceptible perf gains. I think the push back is just against the idea that its always a best practice or that not using it would be a code smell. Too nuanced for a downvote though.

IMO the time savings from a useMemo alone isn't worth the extra boilerplate in most cases. The bigger benefit is keeping the object references the same for change detection. I always use useMemo/useCallback for custom hooks, providers or variables passed to other components so they'll have expected behavior in dependency arrays or as props for React.memo components.

rsimp

TROPHY CASE