131–140 of 191 posts
Earlier quoted context omitted.
I'd like to like web components, but their reliance on JS to instantiate along with all the chaos of the shadow DOM keep them off the table for me. I think they are a great concept defeated by the implementation.
google "html web components"
Earlier quoted context omitted.
Why does the name matter? If it's a Wrapper or a Container or an InnerWrapper or whatever. It's just a 'label'.
Because there is a Stylesheet called main.css with 5000 lines, and somewhere in there is a block like this: .InnerWrapper { padding: 3px 7px; margin-left: -9px; } The design just got a makeover, and you’re tasked with updating all buttons to have a wider spacing. Good luck catching everything, including this class and its usages, without manually reviewing everything that is used like a button, inspecting the HTML, t…
Earlier quoted context omitted.
Not really? It's just an element with some attached styles. styled.div`color:red` is a red-colored div. Hardly fuzzy.
The equivalent styled component of the default Tailwind button of "bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded" is "styled.div`background-color:#8888ff;color:white;font-weight:bold;padding-y:2px;padding-x:4px;border-radius:4px;&hover{background-color:#aaaaff}`". Obviously you wouldn't actually write it like that because it's inline in your code so you can format it better, but the Tailwind ve…
Earlier quoted context omitted.
This isn't about decision paralysis, but picking good names that other people will understand. But they won't, not all of them at least. No matter how great you're at naming things, you are going to do it differently than other people do. That doesn't matter on your personal home page, but it breaks down with a larger team. Inevitably, naming principles will drift apart, and after a few years, you'll have a mess. Don…
Why does the name matter? If it's a Wrapper or a Container or an InnerWrapper or whatever. It's just a 'label'.
Earlier quoted context omitted.
Hmm, I’ve always considered tailwind like the spice to make css actually usable, kinda like elixir is to erlang, typescript is to javascript or C is to machine code. Its still CSS just the stuff that you _actually_ want to build is pre-packaged and thought out for the use case. And I’m not dissing on CSS - just those tools try to solve different problems. CSS is the ground truth, and it kinda has to support all the w…
What makes tailwind feel wrong for me is that you put the css classes everywhere exactly like you would set inline style attribute. I would prefer using the css slectors and select by an id or class name and apply a css like that. I avoid frontend but this is how I see it used in my team. Would be nicer if you could do it like selector > color-xyz text0xyz paddifng-xyz and never add those classes inline
Earlier quoted context omitted.
Because there is a Stylesheet called main.css with 5000 lines, and somewhere in there is a block like this: .InnerWrapper { padding: 3px 7px; margin-left: -9px; } The design just got a makeover, and you’re tasked with updating all buttons to have a wider spacing. Good luck catching everything, including this class and its usages, without manually reviewing everything that is used like a button, inspecting the HTML, t…
But we're talking about Styled Components
Disclaimer: I’m extremely newbie in front end, probably less than 6 months of experience combined in the last 6 years. I 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 plu…
I don't quite get the hate for having CSS in another file. Do you also put all your react stuff in one single file ? That same logic and argument can be applied against all modularization. And really 20-50 tailwind classes in a single element is VERY hard to read and keep in mind. No - it does not make things clear or understandable. One tends to need to re-read and scan over from the beginning and eyes glaze over. E…
For example: using loops, breaking things into smaller reusable components, etc.
Tailwind devs specifically recommend against making your own abstractions in your CSS that coincide with your abstractions in your programming language.
So for example instead of CSS classes for buttons just make components for the buttons to be used directly.
Earlier quoted context omitted.
The equivalent styled component of the default Tailwind button of "bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded" is "styled.div`background-color:#8888ff;color:white;font-weight:bold;padding-y:2px;padding-x:4px;border-radius:4px;&hover{background-color:#aaaaff}`". Obviously you wouldn't actually write it like that because it's inline in your code so you can format it better, but the Tailwind ve…
"Less verbose" I guess by a few characters... at the expense that you're not writing real CSS rules. So you're having to translate every rule into whatever Tailwind's syntax is for the same thing.
Earlier quoted context omitted.
I don't know about you, but I've never seen anyone create a user interface by writing down the full, semantic markup, and then proceed to create CSS for that finished HTML structure. Instead, it's usually an iterative process of adding HTML, styling that, then adding more content. That isn't even related to Tailwind, or any other CSS framework -- just that Tailwind allows you to stay in the HTML (or component) contex…
> I've never seen anyone create a user interface by writing down the full, semantic markup, and then proceed to create CSS for that Indeed, not in the past 7-8 years. But we used to do it, and the outcome was great - semantic, accessible and machine-readable HTML was the norm. It’s unfortunate that we lost this in the transition to components.
You know, there are still people alive who lived through this Golden Age of 10 years ago? 20 years ago? And they call bullshit on your statement.