171–180 of 191 posts
Earlier quoted context omitted.
> 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.
Is that so? From my memory, most people used tables for layouts, or full-out relied on div tags for everything. At some point, HTML5 brought headers and footers and navs and more, and if anything, that made the situation better since. But if the working groups continue to pretend HTML is for text documents instead of web applications, things will never get more semantic.
I mean, HTML is and will always forever be a system to display a few pages of text with some images thrown in. And even for that it sucks big time.
Anything standards committees have been throwing at it over the years are just haphazard hacks to make it into something it's not with no coherent goal in mind.
Earlier quoted context omitted.
Locality of Behaviour: "The behaviour of a unit of code should be as obvious as possible by looking only at that unit of code" https://htmx.org/essays/locality-of-behaviour/ Some people want "cleaner" and that's fine, I much prefer things to be "right there" as much as possible. Must be how my brain works
CSS is not behavior, but styling. Styling should be independent of behavior.
Earlier 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.
For a reason
Earlier quoted context omitted.
I feel we need a club for grumpy old men that yell at clouds! I'm only 34 but after 10 years doing this I now fully understand what my seniors were trying to teach me when I started. Boring technologies that work and will continue to work with the minimum of lock-in and fuss long into the future are what get me excited now.
I’m a bit older but I’m getting progressively more annoyed by this attitude of my peers, and increasingly think it’s an excuse not to learn new things. I know plenty people that are stuck in Python and are some middle mangers and just yell bah! at everything new. I’ve worked through the whole stack, am now heavily in elixir, work in a cutting edge LLM company and feel I’m better than I ever was. There’s a balance.
I can see a top tier game engine developer talking with skepticism about current web tech, but it's more often coming from something like enterprise java devs from the 2000s that used to take months fudging with class hierarchies to deliver a basic form GUI. The kind that must take any opportunity to denounce electron apps but would never give up VS Code and go back to Eclipse.
Earlier quoted context omitted.
It's not the same thing, though. Tailwind applies rules from your design system, not plain CSS values. Assuming you're updating your corporate design to use border-radius 2 vs 4 everywhere, with Tailwind it's a matter of reconfiguring your design system configuration; with styled components (and other approaches) you're going on a string hunt.
Styled components are code. You could easily have a value from a central config rather than a string, like ${company.padding.px}.
const StyledButton = styled.button`
background-color: ${props => props.theme.primaryColor};
`Earlier 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.
A big issue that these articles never mention is that using browser dev tools to debug CSS becomes a huge pain with tailwind. It also makes it harder for community to create custom themes/user scripts for your website/app since targeting specific elements becomes incredibly hard when no class names exist.
Not to mention, it basically puts a dsl on top of CSS.
CSS by itself is great, and with all the modern changes you hardly need to use preprocessors like SCSS (there's still some advantages but far fewer than say, 5 years ago).
I don't understand the people in the thread that hate writing CSS...
Earlier quoted context omitted.
CSS is not behavior, but styling. Styling should be independent of behavior.
It shouldn't, and it has never been independent of behavior. The original pipe dream of CSS is not the only separation of concerns that exists: https://twitter.com/simonswiss/status/1664736786671869952
Changing a theme shouldn't affect behavior (by default).
Decent arguments. Ultimately, I think your preference comes down to: - Do you care about how your html output looks? - I personally don't, just like I don't care about what my Webpack bundle looks like. Web standards will always be slower to evolve, which is why we build tooling on top. - How do you think web components will be used? - I believe they will be used sparsely, only by libraries. But if you want to replac…
also: - Do you care for bloat user needs to download?
Unlike, say, Youtube which ships 2.74 megabytes of css. With amazing non-compressable unique names like .`yt-mini-app-container-view-model__loading-icon-animation` and `.yt-spec-button-shape-next--size-l.yt-spec-button-shape-next--icon-button.yt-spec-button-shape-next--segmented-end`.
And re-inventing utility classes, badly:
.yt-spec-button-shape-next--size-xl .yt-spec-button-shape-next__icon{width:24px;height:24px}
.yt-spec-button-shape-next--size-l .yt-spec-button-shape-next__icon{width:24px;height:24px}
.yt-spec-button-shape-next--size-m .yt-spec-button-shape-next__icon{width:24px;height:24px}
.yt-spec-avatar-shape__button--button-extra-small{width:24px;height:24px}
etc.
Tailwind helps with this a bit: there's a fixed number of utility classes, you're supposed to use them inside components (so they are collocated, but unlike CSS-in-JS you don't write what are essentially inline styles, but chose from a fixed set of classes), and only those needed are shipped.