This thread pretty much sums up my thoughts on #Tailwind:
While it can be useful for rapid prototyping, too often our prototypes get shipped as “MVPs”, which are then never given the space to really be cleaned up.
As a result, shit like this lives on and we continue the cycle of “front-end needs to be over-engineered so people will respect us!”
I always wondered why people writing #Tailwind all day are so aggressive. Especially if you don't want to use it.
Then I had to use Tailwind for a while. Now I understand. If I had to do this every day I would be aggressive too. And they probably just want someone who suffers with them.
I definitely will stick with #CSS. That sparks joy.
My guess is that both are clashing in the way they're setting style rules
My only question would be: if we're using Tailwind already, why are we using an opinionated component library like MUI anyways?
All the utilities and frameworks have been kind of decided on before I joined the team and if I ask to restructure the whole thing I'm gonna be met with rather stark opposition with some argument that will boil down to sunk cost fallacy :drgn_hide:
I need a good graphics designer to help with a landing page and maybe even some logo design work. Preferably using #Tailwind for the landing page. I don't have crazy amounts of money for this project but it does pay.
Can you recommend anyone for this? Please DM me if you know a good person.
Boost it if don't know anyone but want to help connect me anyway. :)
I don't have it in me to do any markhor this weekend, but I'm wondering if I should try to wedge tailwind in there rather than trying to carry forward the semantic-ui stuff from the original React version.
It does the thing I want from #Tailwind - Locality of Behavior - but without the verbosity and build step, and you are more or less using CSS as it is.
I think rather than hating on #tailwind it's more useful to think about the problems it solves for its target audience.
In my experience, while CSS should be well-structured, named, easy to edit etc, it rarely is.
Blame developer sloppiness, rushed deadlines, fickle designers asking constant changes, whatever, but in most sites I've seen it devolves into a mess given a long enough timeline.
Second, CSS is hard. The high level concepts are easy, but the detail is not (like k8s).
Just finished migrating my side project to #python 3.12. Also swapped out Black for rust format and mailhog for mailpit.
The project is pretty much "done" other than updates & bug fixes, thinking of making a cookiecutter template for it, if I get some ideas for new projects over the winter.
I've got a new website up! It's a showcase for all of my #Python#AdventOfCode solutions!
I've got every solution since 2020. Each day is a step-by-step walkthrough aimed at engineers of all skill levels. It assumes basic Python proficiency, but teaches everything you need to know to solve the problem past that.
Oh, and I wrote a bit about my experience standing up a small static site in 2023. I was hoping to take my pre-existing #Markdown and produce simple #HTML with some pre-applied #CSS
I ended up using @astro and a classless CSS framework (h/t to @kevinleedrum for the pointer!) over #Tailwind, which was pretty painless.
Quite pleased with how the whole thing turned out!
#css “Loose coupling makes you think content first. There is no need to write a component for every situation because you can use external CSS to do the heavy lifting.”
Loose coupling.
«The key best practice of Tailwind is tight coupling. That is: the structure and styling are tied together. The semantic approach is the opposite: the structure and styling are loosely coupled»
For me the main reason to steer away from #tailwind (and lesser extend boostrap and bulma and such) and to just use semantic #css.
@Konafets@koehnlein@josefglatz It leads to having redundant code. At each <button> there are then 15 #tailwind classes, partly in different order, so that a search/replace is no longer possible when changing the layout of the button. And the same then with <h1> <h2> <h3> etc. If you avoid this and work consistently with @apply, then I think it's fine.