by shayac2 on 4/12/21, 8:07 PM with 117 comments
by brundolf on 4/12/21, 9:26 PM
One tends to think of parsing/compiling as a fairly esoteric skillset that a relatively small number of programmers ever actually need at their jobs, but it always makes me glad to see examples like this where a little DSL was a genuine boon to productivity in a real product. Once you know how to do it, you start to notice more and more little opportunities where it could be useful.
by mike1o1 on 4/12/21, 9:36 PM
This part from the blog post kind of confused me a bit, though.
"The promise of Tailwind UI is that it's just a code snippet"
Am I the only one who never looks at the code snippets/tab for Tailwind UI, and instead jumps straight into inspect element? As blueprints the components are great, but I almost always want to make some small tweaks or changes to fit my application. Are there other people out there actually copying/pasting the snippets as they are?
by welder on 4/12/21, 10:15 PM
<Button className="bg-gray-100 rounded-full flex" ...
How do you remember the names of all your classes? Should your IDE know about these classes? Can you autocomplete class names? Where's the import statement for these classes so you know where they're defined and what they do. There's a better way:
Use site-wide themes (Objects with keys like colors.heading.primary having value '#000') and withStyles[1] and React.PureComponent[2]. Having your React component render the same result given the same props and state makes things so much easier to work with. Also, the compiler knows about your theme so your IDE helps auto-complete and makes sure the style you're using is actually defined.
[1] https://github.com/airbnb/react-with-styles
[2] https://reactjs.org/docs/react-api.html#reactpurecomponent
by willhoyle on 4/13/21, 1:43 AM
I often wonder whether we need yet another UI framework implementation? I touched on this in my post a couple days ago: https://williamhoyle.ca/blog/2021/vue-has-too-many-ui-framew...
To summarize:
We have 20+ UI frameworks written in Vue. Surely there's enough common ground/code to combine the implementation details for all these common components. For example, OP mentioned the complexities of implementing a modal with some corner cases for 'ESC' behaviour. This is a universal concept whether you're using WidgetUI or TailwindUI. How many times are we going to re-implement a modal/button/dialog/menu?
We have to learn another set of APIs, props, component names, etc... Of course, no one is forcing us to use this. But it seems like we're going in circles re-implementing the same UI patterns over and over again.
I wish we could standardize on a library. Imagine just pulling in GenericUI and sprinkling in your CSS of choice (e.g. tailwindCSS, Bulma, Material, etc...).
I'm a Vue guy, but I think my argument still stands for the React ecosystem.
by AlchemistCamp on 4/13/21, 2:52 AM
by brianzelip on 4/13/21, 10:17 AM
Adam's (author) podcast Full Stack Radio is useful like this too [1].
[0] https://www.w3.org/TR/wai-aria-practices/examples/menu-butto...
by ssijak on 4/12/21, 9:12 PM
I even built something like Tailwind UI but for Chakra (link is in my bio if you want to check it out)
by rwieruch on 4/13/21, 6:12 AM
One year ago I had to do something similar and used Web Components (https://www.robinwieruch.de/react-web-components). Did you consider using Web Components or a Web Components library such as lit-html in the first place?
by CapriciousCptl on 4/12/21, 8:58 PM
by pansa2 on 4/13/21, 1:22 AM
I assumed that I would use Tailwind UI's HTML for these and write vanilla JS for interactivity, but now I am rethinking, especially having read this quote in the article: "If we tried to write it in custom vanilla JS, well we'd be making it harder for literally everyone".
So given this announcement, in my situation would you recommend against vanilla JS, and instead to adopt one of React or Vue?
by franciscop on 4/12/21, 9:49 PM
<Menu.Items className="absolute mt-1 right-0">
<Menu.Items absolute mt-1 right-0>
by ablekh on 4/13/21, 3:35 AM
by sudhirj on 4/13/21, 4:25 AM
by 734129837261 on 4/12/21, 11:13 PM
Personally, I write CSS this way:
1. Select based on cascaded semantic HTML elements; 2. Don't repeat yourself; 3. No unnecessary classnames; 4. No style-descriptions in classnames.
Only when you have troubles selecting an element based on its position in your DOM you should choose a classname. It should not be ".text-gray-500" (like Tailwind does) but it should be "p.author-role".
In my case the classname is semantically descriptive whereas Tailwind is not. In my case you just need to update the CSS and in the case of Tailwind you need to change your HTML and then probably also create a new CSS class.
But still, ideally, you'd simply select it like this:
The author name:
figure.author figcaption h5 { ... }
figure.author figcaption h6 { ... }
by sbacic on 4/13/21, 6:34 AM
1. @apply as a JS function that I can use in CSS in JS.
2. Some way to override existing Tailwind classes with new ones (ex: Generic Button => Specialized Button => Unique Button).
by connorlay on 4/14/21, 10:09 PM