Ah let's see, do they still want you to LOGIN, in order to use a local dev tool? Yes, yes they do. No thanks Docker. You can keep your buzzword reasoning as to why this is needed.
He said his app is a one time payment. Presumably there isn’t a backend and he relies on App Store purchases. I know, it’s shocking an app could just be an actual application rather than a web view.
I see you have a .button, cool! So did you load the entire context of your project into your mind, and calculate every possible iteration of kind, size, color etc this button may have? And once you did that, did you come up with a semantically correct naming scheme that is clear and will not succumb to the inevitable .button_checkout_special_page_cta_widget a particular page will end up requiring?
No? Neither did I. I stopped thinking about CSS entirely almost a decade ago. Thanks Tailwind.
It’s funny, as someone that’s been using CSS for decades I don’t really know how to respond because the scenario outlined here is not one I recognise. My button would be a <button>, so no, I wouldn’t have a .button class, it’s superfluous.
What I would have is:
- a global palette specified via CSS variables
- overrides for dark mode etc specified at the global level so I don’t have to worry about it at the component level
- CSS module files so I specifically don’t need to care for the context of my entire project, just the classes for my current component
Of course, you stopped thinking about CSS a decade ago so you don’t know about any of these improvements. Which is fine but it strikes me as a little strange to be so boastful of ignorance.
As someone who has barely touched Tailwind I’m genuinely curious: if you wanted, say, a consistent border color for use across your project how would you? Are you defining a class name in JS for use with $framework_name? And do you really style each component separately for dark mode? Repeating the same modifiers over and over?
You just make a design system in your tailwind.css, following the documentation. You can optionally use something like daisyui if you do not have designer skills or the time.
That handles consistent sizing, spacing, text, colors, dark mode, and anything else your design system needs. It all compiles down to css in the end, so no runtime overhead and gives you the superior tailwind dx during development.
It's a utility to generate deduped/treeshacken css classes - according to a config file the parent mentioned
It's not some grand framework or something.
It's literally doing exactly what the grand parent said. Define root css variables, and generate the applicable/used css classes that were used in the code
I use Tailwind for work and hobby projects and what you said is exactly what I think Tailwind is and why I use it.
I don’t understand where the disagreement is. I was only pointing out a lot of the “magic” from Tailwind’s abstraction isn’t as magical as the GP you referred to implies.
The poster I responded to, specifically asked for how to implement this in tailwind, with a worry about "do you really style each component separately for dark mode? Repeating the same modifiers over and over?"
I simply answered his question - tailwind is indeed just plain old CSS with a more ergonomic DX.
We are stuck with CSS, but all these CSS styling frameworks just tell me CSS needs to be bulldozed. I looked up DaisyUI that you mentioned. The example on the home page gets rid of chained classes and replaces them with one:
// Styling a simple button
<button class="btn">
daisyUI Button
</button>
Are you suggesting to style the tag name directly? Because that would create chaos in a codebase. <button> is for semantics. It's possible that other design system components need the same semantic element.
No, I’m suggesting that .button.something-else wouldn’t make any sense. You’d just do button.something-else… not that it would really be that useful to do so.
And as you say, it’s for semantics so I wouldn’t use .button anyway as it doesn’t carry the right specificity for styling.
You still have to remember what sizes or whatever to use for what to make it consistent, it’s just they get packed into the “class” attribute. It’s not uncommon to see very long class attribute lines with tailwind with all kinds of p-this and mx-that or whatever. I’ve also seen quite a lot of p-[whatever] tags, at which point all the consistency goes out the window.
So you end up wrapping the components (if you’re using react or something similar) so that you can centralise the styles and use a set of consistent components instead. And at that point it really doesn’t matter if you use tailwind, custom classes, per component css modules, style attributes, css-in-js, or what have you. At this point I prefer to drop the extra dependency and use per-component css files with css module imports. (Or when I do less custom styled UI’s, I prefer to use Mantine and use its attributes for layout and styling)
Don’t you need to keep more context in your mind if you use Tailwaind to make .button_checkout_special_page_cta_widget while staying somewhat consistent?
Could you give us a few examples with and without Tailwind, including CSS variable and compose in preprocessors?
you just add `checkout` class or `big` class to your button. or use `.checkout-page .button` to modify look/size of your whatever button on the checkout page if it's style is truly unique and not used anywhere else.
I know what you mean. But somehow that doesn't bother me. In fact it forces me to think about consistency of the design and often makes me think of a more general schema and simplifications in styling, or getting rid of something too specific/special.
Hey may I suggest CachyOS + KDE? It’s very gaming oriented and you have a lot of great built in features. Everything just works.
So far in 6 months I ran into a single issue: On day 1 of the new Subnautica early access I had to do some debugging and downgrade nvidia drivers to a previous release. But this was fixed after about a week.
No other game gave any issue what so ever. I run everything on the cachy proton version. 4090, 5070 Ti, 5090. All work perfectly. DLSS, Frame gen, older titles too.
If you want to there’s convenience flags to auto upgrade things like DLSS to latest versions etc. It’s not something you have to use, but I found it really nice compared to the Windows equivalents.
I’m so beyond happy to have zero Windows left in the house. :)
I would like to add that CachyOS also supports Niri, a scrolling tiling WM.
As someone who long had "papercuts" from floating WMs I've had great success with it and even prefer it to something fully tiling like hyprland.
Another vote of confidence for CachyOS + KDE! This is my setup and literally the only issue I've had which presented a problem to me is that OpenRGB doesn't like my mobo at all, it's stuck in 'unicorn vomit' mode when I wanted tasteful accent lighting. Games work with minimal farting about, the desktop is great out of the box and customisable in plenty of ways, and it generally treats you like an adult.
I'm not on Cachy OS myself but just normal Arch with KDE, and HDR is working fine there at least. Using an RTX 4070. I hear some people can still have issues with it though, but especially when running Wine/Proton in Wayland which is possible nowadays I haven't had any issues regarding that. You still have to use environment variables to enable it though (PROTON_ENABLE_WAYLAND=1 PROTON_ENABLE_HDR=1). Hopefully that will soon just be automatic.
That is for games specifically. For video with mpv it just works in my experience. Browser support is still a quite hit or miss.
I really want to like this. Ideologically I'm on board. Who wouldn't want to avoid all this multiplexing complexity and pitfalls? But deferring the window management to the OS sounds great in theory, but in practice it falls short (at least for me).
I work on both MacOS and Linux. Even if I were to figure out a perfect window management approach, I'd have to do it twice, and then figure out a way to "attach" to a layout of windows essentially. And then make it cross-platform... or live with zero organization, or at best some kind of flat structure. That's a immediate non-starter. Even if I focused only on a single OS, I still don't consider this a viable approach. It would be like removing browser tabs, and saying let's let the OS manage all this nasty UI stuff.
So then the next immediate idea is let's just have the Terminal itself manage UI. Ghostty supports tabs, splits etc. Great. But if I need to restart Ghostty for whatever reason, my entire layout vanishes and I have to set it all up again?
For me tmux is not just about the attach/detach part. A session is a personal "layout" of the workspace I've organically landed on for this task. Maybe it's a few windows with splits. Maybe it's just the single window with or without a split. Maybe it's a more browser-like just X amount of windows (tabs). If/when things get overwhelming I branch off into a new session for one (or more) sub-tasks. Little fzf-based utilities allow for nice fuzzying over sessions and what not. Or maybe you just run the different sessions in actual different physical OS windows. You can mix and match however you feel that day.
So if I'm in project x, working on feature y, and I detach and walk over to my other computer I can SSH over and continue as if nothing at all changed and retain the exact layout of what I was using before. Simultaneously in another physical window (or a tab) I can just switch to another local (or not) session and instantly be mentally in a different context, working on a different project or feature. Or I can SSH into a server and resume a debugging session left (intentionally) open for a while (which may consist of a few splits/windows/what not).
Maybe I'm missing something. I'm curious how your day-to-day workflow looks like. I imagine if I was 100% bound to a single machine, I could make it work with a tiling wm. But even then Ghostty crashes or something else happens and poof your entire work layout is gone and needs to be re-created (even if the individual pieces are safe).
If you do most of your work on a central server and treat your other devices as thin clients, then (afaik) Tmux/Zellij are the way to go – not to mention if you want to multiplayer with colleagues.
(I know Wezterm has remote session multiplexing in beta, but I’d be surprised if you can re-attach from a different machine.)
Lately I’ve been experimenting with embracing the total scriptability of my favorite terminal, Kitty. Its creator is famously outspoken about non-native multiplexers, precisely because of the pitfalls you mentioned and because they hold back the terminal ecosystem.
Couple of recent issues I’ve had: washed-out colors in Claude Code, desktop notifications not passing through, scrollback weirdness, and image protocol mismatches.
I used to treat Zellij as an OS to build my own IDE in. Now it’s Kitty.
I save layouts as a Kitty session. Important limitation: this doesn’t persist running processes. And so enter zmx. Whenever I need a process I can reattach to I wrap it in zmx.
A terminal agent can interact with the kitty cli to create splits and such. I’m still on the fence as to whether that’s safe. Probably not. Also, tmux is likely better represented in the training data. Currently experimenting with running claude inside tmux (multiplexing) inside nono (sandbox).
Niri is a perfect window manager approach, in my opinion. I don’t need tmux. Just Niri + Foot (terminal) and it’s perfect for the way my brain works. If you haven’t tried it, I highly recommended it.
Huh. The person you're replying to specifically mentioned they connect to the same tmux session from different computers. Niri is great, but how's it relevant here?
Turn off vim mode if you use it. There is some kind of bug with it I found it basically unusable. With vim mode off it sort of works ok. Only breaks occasionally.
Just got this via email. Well that's great, just as I moved a high bandwidth client to them a couple months ago. I love the "if you don't like it feel free to cancel" in the email also. SMH.
I have tested all of these also, and settled on borg + borgmatic. It has been absolutely rock solid. Borgmatic just rounds everything together in such a nice way. The documentation is great.
I'm pushing it all to a Hetzner storage box, as well as a local NAS. Super affordable!
Add me as another vote that misses them. I totally understand you need a break and other obligations take more time, but I hope you can still find the time to do them occasionally. :)
