> We live in a world where custom elements (aka ) are fully supported and enabled by modern browsers. Don't we need to define the custom element using javascript first? All my knowledge about custom elements comes from this Mozilla doc: https://developer.mozilla.org/en-US/docs/Web/API/Web_compone... If custom elements is the way to go, it sounds like a lot of javascript and coding overhead that I have to take. Doesn'…
Depends on what you're going to use them for. If you need the actual JS functionality web components can offer, then yes. Though at this point you're in JS land anyways and probably using some kind of web component library (or your custom-built helpers/wrappers/etc.), which usually handles this for you. If all you want to do is prevent the "div/span-tag soup" as he calls it, you don't have to register anything, thoug…
Tailwind Isn't for Me
61–70 of 191 posts
Re: Tailwind Isn't for Me
#62Earlier quoted context omitted.
My biggest issue with Tailwind is point #5 on the article: Tailwind encourages div/span-tag soup. Together with the class name soup my HTML becomes unreadable.
> HTML becomes unreadable To be honest, I don't find that a problem. Most frontend development is done in a higher-order abstraction like React. For the most part, I don't read HTML and I don't write HTML. If you use the right level of composition, "div soup" should never really be a problem.
Re: Tailwind Isn't for Me
#63Re: Tailwind Isn't for Me
#64People want painkillers, not vitamins. That's why there is this endless flow of snake oil frameworks like Tailwind and all the others. People see some fancy demos and think "wow, so cool so easy" and "This is the newest framework, so it must be the best" and go for it. Then over time, they get caught in a web of problems that the complexity of the framework produces. Then a few people go for the vitamins route (plain…
Just because something is old doesn’t mean it’s correct, this is such a curmudgeon take. Things we have have evolved over a long time, have been started hastily (JavaScript) and there’s no reason to believe we’re not in a local minimum and something much better is out there. I personally believe the js model is completely wrong for the browser and something like an actor model would fit much better. I’m not saying we…
I'm puzzled to see the popularity of such frameworks while boring technologies often are well documented, well tested, highly stable, provide acceptable dev efficiency, readable by any dev, and often comes with much better performance.
I'm probably just a grumpy old man yelling at clouds.
Re: Tailwind Isn't for Me
#65I love tailwind. I strongly feel that most modern CSS solutions are massively overthought. In engineering we have bigger problems to solve than a key/value list that makes a div blue. Tailwind removes the thinking around CSS, naming, preprocessors etc etc, it just lets me write good CSS and focus on components and other engineering problems. I seem to be one of the few people who can read CSS properties horizontally…
Why not Styled Components? I've been using them for years now and I'm extremely productive. Tailwind on the other hand looks like a hellish nightmare, horizontal reading, proprietary syntax, no selector targeting of other components.
Is "horizontal reading" worse than reading two files?
What if the other file is actually 30 files compiled with SASS?
What if they're 30 files, compiled with SASS, and written by a bunch of devs who don't know CSS well, didn't use BEM or anything to name things well, and didn't organise them at all?
Tailwind isn't better than great CSS, but it's significantly better than bad CSS.
Re: Tailwind Isn't for Me
#66I can understand and appreciate what Tailwind is all about. It's a standards approach to naming conventions and puts all the details in the markup. Which has its value.
I've found a happy balance to be:
1. utility classes for layout and structural details
2. custom classes for look/feel details
3. after x utility classes, its time to combine into a single class
x is very much based on situation and intuition not a hard rule.
I'm still using LESS because of nested css, and classes can be composed.
One benefit of LESS is the style code is decoupled from react/angular components and more importantly the shadow dom.
Re: Tailwind Isn't for Me
#67The endless roundabout of discourse on which technology choice you should or shouldn’t make is exhausting. As a senior engineer im able to sift through the bullshit on this but as a junior I remember these discussions were draining and also made me feel like shit about decisions I’d made. I guess it drills into a part of human nature where we are always measuring ourselves and our things against others.
Technology-choice as fashion needs to die. There are suitable tools for the job, and unsuitable ones. Deciding between them gets harder when loads of amped up juniors are selling each other on the benefits of the latest and greatest without actually putting them to the test over the course of years/multiple projects/iterations.
Re: Tailwind Isn't for Me
#68Earlier quoted context omitted.
My biggest issue with Tailwind is point #5 on the article: Tailwind encourages div/span-tag soup. Together with the class name soup my HTML becomes unreadable.
> HTML becomes unreadable To be honest, I don't find that a problem. Most frontend development is done in a higher-order abstraction like React. For the most part, I don't read HTML and I don't write HTML. If you use the right level of composition, "div soup" should never really be a problem.
Re: Tailwind Isn't for Me
#69I can’t stress enough how easy it is using Tailwind, it just works! I don’t care about the long ass lines because for how I’m used to format html pages, I’d have to go to a new line anyway, it’s just that now I can understand what’s happening in react components without too many troubles.
Another plus is that by checking other people’s html code, I can immediately see their tailwind tags, without searching through files for css definitions, I see how they change their stuff there and I can immediately learn how to replicate their patterns. Imagine how fruitful saving time is, especially when using framework like nextjs, you can literally launch a prototype in few days of work with these technologies.
Don’t get me wrong, I know that you’re not going to build the next Facebook or Microsoft with Tailwind and Nextjs, they have their drawbacks, but their impact on the critical path from the idea to a working MVP can’t be ignored.
Re: Tailwind Isn't for Me
#70Earlier quoted context omitted.
If horizontal reading bothers you so much it resembles a hellish nightmare (Dante would like to have a word with you), nobody stops you from going like this: Submit And you actually can target other components. There are lots of sibling selectors, including named groups: Name
> removes the thinking around CSS, naming, preprocessors etc
Without Tailwind, you'll have to come up with a unique, declarative, distinctive name for each and every element you're piling styles upon. At first it's a button, then there's buttons that should look like links, and then clickable icons. They share some properties, but not others, and before you know it, you've invented an ad-hoc description language in CSS classes that nobody except you can understand right away. With Tailwind, you may have sequences of tokens that seem confusing at first, but at least it's the same -- few -- sequences in every single Tailwind project under the sun.
No side effects, no blurry concerns, no more specificity issues. If you don't appreciate that, you haven't seen large enough projects yet.