That's my main way to find interesting links, especially as I usually find comments more interesting than the featured links. I default to the "top 20".
I absolutely love it. I find it empowers me more than ever before, and my satisfaction is at all time highs. I'm even building projects now (videogames) that I probably wouldn't have started before.
Here's where I'm at:
- Your subjective taste will become more important than ever, be it graphic design, code architecture, visual art, music, and so on for each domain that AI becomes good at. People with better taste will produce better results. If you have bad taste, you can't steer _any_ tool (AI or otherwise) into producing good outputs. So refining your taste and expanding it will become more important. re: "Yeah, I could've prompted for that too.", I see a parallel to Stable Diffusion visual art. Sure, anyone _can_ make _anything_, but getting certain types of artistic outputs is still an exercise in skill and knowledge. Without the right skill expression, they won't have the same outputs.
- Delegating the things where "I don't have time to think about that right now" feels really good. As an analog, e.g., importing lodash and using one of their functions instead of writing your own. With AI, it's like getting magical bespoke algorithms tailored exactly to your needs (but unlike lodash, I actually see the underlying src!). Treat it like a black box until it stops working for you. I think "use AI vs not" is similar to "use a library or not": you kinda still have to understand what you need to do before picking up the tool. You don't have to understand any tool perfectly to make effective use out of it.
- AI is a tremendous help at getting you over blockers. Previous procrastination is eliminated when you can tell AI to just start building and making forward progress, or if you ask it for a high level overview on how something works to demystify something you previously perceived as insurmountable or tough.
> Nothing feels satisfying anymore
You still have to realize that were it not for you guiding the process, the thing in question would not exist. e.g., if you vibecode a videogame, you start to realize that there's no way (today) that a model is 1-shotting that. At least, it isn't 1-shotting it exactly to your vision. You and AI compile an artifact together that's greater than the sum of both of you. I find that satisfying and exciting. Eventually you will have to fix it (and so come to understand parts you neglected to earlier).
It's incredibly satisfying when AI writes the tedious test cases for things I write personally (including all edge cases) and I just review and verify they are correct.
I still find I regret in the long term cases where I vibe-accept the code it produces without much critical thought, because when I need to finesse those, I can see how it sometimes produces a fractal of bad designs/implementations.
In a real production app with stakes and consequences you still need to be reading and understanding everything it produces imo. If you don't, it's at your own peril.
I do worry about my longterm memory though. I don't think that purely reading and thinking is enough to drill something into your brain in a way that allows you to accurately produce it again later. Probably would screw me over in a job interview without AI access.
- hiragana / katakana / number / time reading quizzes
- vocabulary quizzes based on wordlists you define and build
- learn and practice kanji anki-style (using FSRS algo)
- the coolest feature (imo) is a "reader": upload Japanese texts (light novels, children's books, etc), then translate them to your native language to practice your reading comprehension. Select text anywhere on the page (with your cursor) to instantly do a dictionary lookup. A LLM evaluates your translation accuracy (0..100%) and suggests other possible interpretations.
I just revamped the UI look and feel the other day after implementing some other user feedback! I'm now exploring ads as a way to monetize it.
- hiragana / katakana / time reading / number reading quizzers
- learn kanji with FSRS, anki-style
- vocab quizzer
- the coolest feature (imo) is a "reader": upload Japanese texts (light novels, children's books, etc), then translate them to your native language to practice your reading comprehension. Select text anywhere on the page (with your cursor) to instantly do a dictionary lookup. A LLM evaluates your translation accuracy (0..100%) and suggests other possible interpretations.
It's all elixir+liveview+postgres+pgroonga (though there are times when I would like to have SolidJS).
I've been considering open-sourcing it due to lack of commercial success, but might try an ad-based approach first.
grok-code-fast-1 has been my preferred model lately, but I don't see any mention of it as part of this release. I'm wondering if this might be better? Even if grok-code-fast-1 might be slightly worse than Gemini 2.5 Pro, the speed of iteration can't be beat.
I tried a bunch. The popular one is Screen Studio, but its a crazy subscription price. I made this with Focusee (https://focusee.imobie.com), which from what I can tell has all the features but a one time price!
Some feedback: it's too easy to get into a "dead chat".
> Sorry, an error occurred while processing your request.
No way to retry or resubmit or edit anything to get things moving again. Too terminal.
If I just type "try again" (lacking a retry mechanism), having it say "Here is the current image I'm working with" seems unexpected (my follow-up request was going to be for 4 entirely new variations with more specific aspects)
If I go back to the home page and attempt to begin what I imagined is a new chat, it appends this new message onto the previous chat's history. Not sure if that's a visual / caching bug, but it's also jarring
I'm surprised that a lot of the comments seem to be missing the reason that this project exists.
In many tailwind projects, you inevitably end up wanting to standardize how a button looks, how a field looks, etc., rather than copy+paste the same 20+ tailwind classes that you need to implement a nice looking button in tailwind.
Can you just apply it to `button { @apply flex items-center blahblahblah; }` in app.css? Of course you can. Or you can use the btn from DaisyUI.
I think DaisyUI is just a shortcut for many common UI components that you will inevitably want to build out and that you will necessarily eventually standardize in any app that grows large enough.
How does it differ from bootstrap? Well, you can continue to use tailwind for everything else that DaisyUI has not implemented. It's just an additive layer to tailwind. The project is at its core just a shortcut for common UI components.
As a user, my criticism is that many of the DaisyUI components seem to be lacking good contrast, so some just don't seem to be usable. The theming situation is really interesting and quite cool to use, but if you look at the example page, it just feels hard to read. I can't really find a light and dark default theme that look good to me (re: contrast and brightness). I think the color hooks might just not be there but I didn't dig far enough in.
For me, I've found a lot of value in being able to easily copy+paste parts of DaisyUI source code, e.g., a particular widget and modifying it to fit my design system, rather than use it in its entirety.
> In many tailwind projects, you inevitably end up wanting to standardize how a button looks, how a field looks, etc., rather than copy+paste the same 20+ tailwind classes that you need to implement a nice looking button in tailwind.
CSS classes already support this natively.
The whole point of CSS was move up a level of abstraction, so you could collect related styles into a class and reference that class everywhere you need that same grouping of styles instead of copy/pasting your HTML2 attribute-based styles all over the place.
But then we got Tailwind, which uses CSS classes to emulate the pre-CSS behavior of specifying styles at a hyperfine granularity everywhere.
And now we get DaisyUI, which emulates class based styling on top of a toolkit that emulates attribute based styling on top of the class based system of CSS.
After while we have to admit that this tech stack contortion is the result of picking a tool because of familiarity and not because it is the best fit for the problem.
Just because you have Tailwind in your codebase doesn't mean you can _only_ use Tailwind. I often use a mixture of both when it makes sense. The Tailwind classes are often terser. Tailwind is not great for all things.
> which emulates class based styling
IMO, what DaisyUI does is how you are meant to be using Tailwind. You aren't supposed to use _only_ TailwindCSS classes in HTML directly (although you can). It's faster for prototyping, then once the prototype solidifies and becomes a pattern, you can extract your long tailwind string into a nice utility class.
It happens to use things like `@apply gap-2` internally in its src, so that if you want to override "how large the gaps are" in Tailwind, Daisy will also inherit that override.
I've been complaining about this for years, even writing an article on it. When the article initially made it's rounds on HN it was divisive. People seem to have cooled off a bit on tailwind since then, which is good, but you still see it being dumped into new projects, or originating things like this that attempt to build a facsimile of what we get "for free" in the browser
Yes to all you have written here. That helps me feel less insane.
If React had scoped styles like Vue has, I don't think tailwind would have gained such traction. Lack of scoped styles in native CSS has always been a fundamental shortcoming (always, except for the brief moment in like 2013 when @scope was spec'd and implemented, only to be snuffed out shortly thereafter). But it's coming for real now, maybe...
We've got @scope back now, and, while it's not exactly the same as it was in the early part of the 2010s, it's still pretty good, as it let's you set both upper and lower bounds for a block of css. Being able to say "these selectors don't apply below this point" is immensely powerful, letting you build donut styles for components very easily
It wasn't quite ready when I wrote a sort of follow up article[1] about new CSS features largely eliminating the need for scss, but it's basically baseline now.
My personal new favorite feature is color mix and the other color compositional functions. You can do really neat tricks with them, current color, and variables, that are otherwise impossible, even with scss
Yes, Tailwind's CSS reminds me of the same unoptimized HTML tag soup that editors of the 2000s era web used to spit out. Tailwind is created by designers for designers. It's perfect for how designers think about layout and works well for them in a world with strict design specs.
Unfortunately, it's also incredibly bespoke and since it's found in most recent well designed templates, engineers must also learn how to work with it. Something 5 years ago that would have died from its own complexity weighing it down for the new shiney, is now kept alive by the ease at which AI can keep it going.
The original motivation of CSS was the cascading aspect of it. During its development, the web was largely seen as a web of documents. Style sheets tried mimicking how traditional publishers style their documents, books, etc. There is also a need to reconcile document styling applied by the user agent, the site author, and possibly other sources. This is where cascading comes into play.
Problems start to occur when using a system designed around traditional publishing to declare the layout of a web application. This is why CSS eventually gained layout-related functionality (flex, grid, container queries, etc.), among other features.
Tailwind provides two things out-of-the-box that make it convenient for building web applications: (1) it comes with a ready-to-use style system; (2) it allows styles to be colocated with markup. The second point is mostly useful for building UI components. Everything strictly related to presentation can be stored within a single file.
Before using Tailwind, I was a strong advocate of CSS modules (and I still strongly advocate for CSS modules if one wants to avoid Tailwind). With either approach, one can achieve isolated styling between components. Repeated styling or markup is a strong indicator that you should extract something into a component.
The first thought that came to my mind reading the DaisyUI website was "Is this an April Fool's joke?". I wouldn't normally post something like that, as it's entirely unfair to the hard work and dedication that someone has put into this. However, I think it captures my surprise by how smack on the nose this is in terms of the spiral of tech abstractions - this is exactly what CSS was designed to solve, and things like tailwind appear to be leading to people forgetting that.
Had the same initial reaction - have we come full circle to Bootstrap 20 years later?
But after playing around with their theme builder[1], I think there's real value here - you can quickly spin up a custom-ish set of Tailwind components. I'd rather it output an actual component library though more like shadcn.
I built apps for a long, long time without Tailwind, just using CSS, sometimes Sass. And I still do at work because our build system doesn't support Tailwind compiler. But for all my side projects, of which there's a few, I use Tailwind. It's just so much easier. I don't see how this experience is compatible with a Emperor's no clothes situation.
Tailwind is better understood as a more powerful replacement for inline styles like <p style="color:blue;">, rather than a less powerful replacement for the full functionality of CSS.
Tailwind is an implementation of "Atomic CSS," and the biggest arguments to use Tailwind are the arguments in favor of Atomic CSS, which are well-known.
> But then we got Tailwind, which uses CSS classes to emulate the pre-CSS behavior of specifying styles at a hyperfine granularity everywhere.
I think it's unfair to tailwind, the point of it that it provides you sensible defaults to choose from. It's perfect for hobby write-once stuff, prototyping, then once you're happy, create a class and @apply.
It has to work like this to provide fast feedback cycle during development. Why tailwind folks insist that copying and pasting it final product is okay, I don't know.
Most of my Tailwind objections have gone away with the availability of CSS layers. Now using a library for a utility layer, which can surgically override your component layer, makes perfect sense. And using a library for that component layer that adheres to the same design token API as the utility layer also makes sense.
One benefit of tailwind is that while all of the classes look like they set properties with fixed values, they are actually almost all controlled by variables. This makes it easier to retain a coherent design during redesigns. Doing the same in CSS is absolutely possible, but tailwind is terser.
> And now we get DaisyUI, which emulates class based styling on top of a toolkit that emulates attribute based styling on top of the class based system of CSS.
I mean, no. Daisy doesn’t emulate anything, it is class based styling. It happens to have a build system that that emulates attribute based styling on top of the class based system of CSS, but Daisy’s classes appear in your CSS as normal CSS classes.
That's what components are for. One of the issues with classes is that you inevitably run into a behavior that requires additional dom nodes or js. For example, what if your most of your buttons need to show loading states [^1].
Bootstrap is actually not as bad as I remember, but I still see quite a few examples where their api requires complex & specific combinations of elements. Just compare their Accordion to ShadCN's.
For simple buttons you may get away with classes only (not worth the risk imo), but anything more complex than a dropdown should be a component. Case in point: daisyUIs dropdown doesn't support arrow key navigation or escape.
Depends on the conventions of the project. Tailwind is acceptable (shadcn is a great starting point), but if I write them from scratch, I use css modules.
You don't write component styles that often so the context switching and repetition don't matter, and css modules are close to the standard while still being locally scoped.
So your <Button> component still has 60 tailwind classes on it?
I think that might work in React, but might have a payload impact on server-rendered React.
Another interesting point for using something like this (specifically, using shorter semantic class names instead of multiple tailwind classes) is: Phoenix LiveView
LiveView streams DOM changes over the websocket, so afaik can't really meaningfully be compressed to eliminate bytes. By using `btn` instead of 30 tailwind classes, your payloads will be smaller over the wire.
A bit niche, but something to think about.
The fact that your `<Button>` React component renders 60 tailwind classes might not seem bad (because gzip or otherwise might actually make it ~negligible if you have a ton of buttons on the page and you're server rendering with compression enabled), but in LiveView's case, I don't think there's really any other option (not enough of a text corpus to compress?).
Not sure if this was a factor in Phoenix's recent default inclusion of DaisyUI or not.
Even in Phoenix, I'm still using a `<.button>` Phoenix component, but that uses a smaller semantic classname most of the time
> So your <Button> component still has 60 tailwind classes on it?
Yes, and this is better I think, because you still have only one button. So you just reuse the component.
But if you make a .button class, now people are going to be tempted to use that to style their own buttons. And now, you have a dozen buttons and your app breaks in tiny little ways and your codebase is a hot mess.
There has never been an application where I worked that anyone is happy with the base design of the button. There is always some variant, some edge case, some requirement that doesn't fit. This is the whole reason why BEM became a thing briefly and it was tedious. Tailwind solves all that. Just have a base set of styles, pass in any additional styles to the component based on the specific requirements and where the component is used, use tailwind-merge in the component and now I never have to care ever again.
> In many tailwind projects, you inevitably end up wanting to standardize how a button looks, how a field looks, etc., rather than copy+paste the same 20+ tailwind classes that you need to implement a nice looking button in tailwind.
Isn't this called classes and Ids in CSS? Is Tailwind just CSS on top of CSS?
Tailwind is a set of utility CSS classes you can use that tend to guide you into writing CSS that looks like it "fits" together. E.g., consistent gaps if you use `gap-1`, `gap-2`, etc., rather than a hodgepodge of "hmm did I use margin-right: 2px or 1em or what" that can emerge in a large CSS codebase with many developers. We can use a `m-1` or `p-1` class to define a base padding, and as long as everyone knows that `1` is the amount of space to use by default, everything will generally look like it fits together.
Later, you can optionally redefine what `1` means if you want more space in your design. In a way, using tailwind can be like variablizing your CSS at compile time (in a faster way than just using writing and using CSS variables).
For a lot of things, using just 1-3 tailwind classes on a div is sufficient for many common tasks, e.g., `flex flex-row gap-1` boom done. You can put this directly in the HTML, and is considered "fine".
This is everything needed to make a button look nice in tailwind, and obviously it would be insane to copy+paste this every time you want a nice looking button in your HTML (not to mention the byte size, it's just unreadable).
The best thing to do is define a `.btn` or `.button` (usually I might avoid `button` DOM level selector for future flexibility) and encapsulate these styles as a semantic component in your .css file. You can write them with raw CSS or `@apply bg-zinc-100 border ...;` using tailwind style @apply.
This is what DaisyUI provides you, a shortcut to common nice looking UI components.
> In a way, using tailwind can be like variablizing your CSS at compile time
Isn't this what SCSS or Sass did though? They were around long before tailwind. Is there a reason to pick Tailwind over those? I assume most projects were using them then decided to migrate to tailwind once it became popular, but why did that happen? Was it just keeping up with the cool kids or some actual differentiating features?
I still just handwrite my frontend code so I'm rather ignorant on this topic, it seems like a lot more extra hoops than just writing by hand which actually isn't very difficult (but I'm a single dev on rather smaller projects)
Tailwind is just a set of utility classes (that also tends to be compiled), while SCSS is a full-on CSS compiler that offers no utility classes by default.
A lot of the features that SCSS enabled are now natively part of CSS, so it has fallen somewhat out of favor (because: why compile when you can use the same features for free without compiling?). Nesting is in CSS now, which was the killer feature at the time. & scoping too. Variables especially are better in raw CSS because you can re-assign them and have them transition/animate, which is not possible in SCSS. SCSS helped to evolve CSS.
I initially thought Tailwind was very stupid, but after using it, it is somewhat freeing to write some "1-off inline CSS" (essentially) on the DOM node itself. Sometimes inline CSS is OK (and it's nicer to do so with an easy to remember and powerful utility class rather than via `style=`).
For some, it eliminates `MyComponent.css` that has literally 1 rule with 1 style inside it. Colocation with the DOM in some cases making it easier to modify + reason about, less context switching.
It's not supposed to, the big value of those is variables and combining rules together in a modular way. You'd define your own gap-1. It's not supposed to be a design system.
If I recall, the low effort way to do it in the past was to bring in another CSS framework eg. bootstrap, bulma, foundation, etc. So it seems, tailwind has brought it all together along with the improvements that were mentioned
The hole point of having a Component-Library is to reuse Components. And a component is markup, style and functionality. Not only the CSS. E.g. you want to use the same Button-Component all over the place in your project and not re-declare <button class="btn btn-secondary">text</button> again and again in your project. If you think about more complex Component like a sort able table, it becomes more obvious.
Imo the main benefit of Tailwind (or any other style-in-JS approach) is parameterization. Styling often changes based on runtime state. Mapping runtime states to css classes/ids (or scss functions et al) is brittle and doesn't scale well.
Historically, the way to standardize how a component appears with Tailwind is to use component abstraction in whatever tool you are building with to accomplish that. Define a button once somewhere and then throw on whatever classes it needs.
If you were copy-pasting long strings of Tailwind classes all over, you were already doing it wrong before you even heard of Daisy.
Sure, you might make a `<Button>` UI component (assume React), but if it embeds 30 classes in it, when you server-render this, every button on your page is contributing ~30 classes worth of bytes to the payload sent across the wire.
The thing with Tailwind, however, is it reduces your options by picking a certain set of values, where with CSS you can choose whichever, so it becomes easier to have something that is more symmetric and looks better using Tailwind rather than CSS for this reason.
This can also be solved by having good design sense, and doesn’t necessitate a builder library. Having your own style also breaks websites out from all looking the same.
> In many tailwind projects, you inevitably end up wanting to standardize how a button looks, how a field looks, etc., rather than copy+paste the same 20+ tailwind classes that you need to implement a nice looking button in tailwind.
I think in most projects people are using some sort of component system outside of tailwind. A react component, for example, could have the tailwindcss classes. Then that component is used multiple times.
Yes, they'll typically have a UI component that accepts props and may have some internal state.
DaisyUI is operating at the style layer, so you might use it to achieve the visuals for your UI component (regardless of how you achieve your UI component, be it React/Vue/server-rendered/etc)
I'm suggesting that just because you have a UI component, it doesn't mean you should be sending 30 tailwind classes for this button across the wire (in a server-rendered approach), and DaisyUI is 1 mechanism to achieve this with approximately 1 component CSS class.
Thank you for the rational well-argumented answer.
> I'm suggesting that just because you have a UI component, it doesn't mean you should be sending 30 tailwind classes for this button across the wire (in a server-rendered approach), and DaisyUI is 1 mechanism to achieve this with approximately 1 component CSS class.
Aesthetically/ideologically I like that efficiency, but I have to wonder: if we measured that wire with gzip and a lot of redundancy (all the classes) if I would be able to measure any difference in the size or in the cpu decompressing it? Still I like the idea of making it efficient by default.
> In many tailwind projects, you inevitably end up wanting to standardize how a button looks, how a field looks, etc.
You should be using components for this, in whatever backend or frontend framework you have.
And if you say "well this button needs to have this specific piece of data or text but other buttons don't" - great, extract that from the component. There's no reason to create 12 different buttons.
But I mean, Tailwind exists to make you quickly prototype and standardize upon a personal look & feel for your site and reuse these styles with components. The standardization/reuse aspect is absolutely part of it.
I think you're agreeing with me. DaisyUI is 1 implementation of a standardization shortcut so you don't have to e.g., develop your own button, dropdown, modal, nav, etc (whatever you are interested to consume from DaisyUI)
The docs up through version 3.x explicitly called this out as not recommended and a poor choice, but the justifications were... sort of lame. "You'll have to come up with class names, your css bundle might be bigger, etc". I did read a more technical github issue on @apply vs theme() which called out the apply behaviour as doing a bit more than expected. I don't recall 'theme' being a thing in earlier tailwind versions, but I'm not an expert at it, so I might have missed that.
@apply to me I only use if I have no other choice, such as if I need to build a CSS file that needs to have classes with specific names. (Such as giving our company styling to a third party service).
Basically all the bonuses of Windows re: gaming, with a great developer experience (like Linux/OSX).
The prime annoyances are:
- exposing a port to the entire LAN (for local phone debug) is non-trivial
- I imagine Android or phone dev might be a bit harder re: simulator, luckily I don't do this
- dev that spawns native windows would by default spawn through some WM layer with X11 or something (and they are laggy)