Live data from Hacker News

Tailwind Isn't for Me

spicyweb.dev

101–110 of 191 posts

Re: Tailwind Isn't for Me

#101

Earlier quoted context omitted.

> Web standards will always be slower, which is why we build tooling on top. I don't follow. I don't see how frameworks or tools have anything to do with standards being slow.

* Slow to evolve As in: it took years to get something thats even remotely comparable to framework components. Tooling can move fast and course correct, the standards have to get things right the first time.

I still don't see the relationship. Framework components are using the standard to create what they create, and that's how it's meant to be.

I wouldn't expect the standard to ever really offer most of what a framework does.

Re: Tailwind Isn't for Me

#102
> The problem is that all these tokens are defined…in JavaScript. A CSS framework. Using JavaScript for its design tokens. In 2021.

And THAT right there is the core problem of such frameworks.

The trinity of frontend technologies, by design, have a clear separation of concerns: HTML structures, CSS styles, JS implements logic.

Of these 3, JS is, by necessity, the most powerful, and the one that can change the other 2 the most. So, as programmers like doing cool things, the temptation is always there to just write some JS that grabs the other 2 and does whatever with them.

This would, in theory, be fine...if there was a universally agreed way to do this. The problem is, there isn't. We still pretend, and can even implement it in a way, where the concerns are actually separated (thanks to serverside rendering we can even do so dynamically), and we have not one method of violating this separation of concerns, but a gazillion ways, spanning the full range of compatibility from "no problemo" to "are you crazy?".

This needs to stop, I say desperately, while being fully consciouss of the fact that it never will, since the genie is already out of the bottle and has been for a long time.

Re: Tailwind Isn't for Me

#103
post #57
post #35

Earlier quoted context omitted.

My personal opinion is that styled components creates an unnecessary and fuzzy extra abstraction on top of components.

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 version is less verbose and easier to read if you did.

Re: Tailwind Isn't for Me

#104
post #86

Earlier quoted context omitted.

If you need to adopt the HTML to fit a certain style, you're doing it wrong. HTML should be a semantic markup, it shouldn't change much when you need to change the styling/CSS. So you don't really go "back-and-forth" to architecture CSS, you just write your CSS. But maybe it's a Tailwind thing that you need to add additional elements to HTML just to be able to style it correctly, I'm not sure. It's like saying you sh…

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.

Re: Tailwind Isn't for Me

#105
post #86

Earlier quoted context omitted.

If you need to adopt the HTML to fit a certain style, you're doing it wrong. HTML should be a semantic markup, it shouldn't change much when you need to change the styling/CSS. So you don't really go "back-and-forth" to architecture CSS, you just write your CSS. But maybe it's a Tailwind thing that you need to add additional elements to HTML just to be able to style it correctly, I'm not sure. It's like saying you sh…

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 don't understand the big problem with switching different files. Don't we write components and tests in separate files? When we develop a component we add it to other components/views. When you need to add new props to a component, you open up the component file, add your prop, open up your component test file write your tests, if there are any tests fails you go back to component file and fix it there, then if everything works you add your props in the view components. Especially when we are talking about components and component libraries, you don't change the styling every other day especially when design tokens comes from centralised places (spacing, colors, fonts etc.).

What people misses out is CSS should be written in state-based architecture. For example for a button you have idle, hover, active, focus, focus visible, disabled states, and combinations of each button intent (default, primary, destructive, confirmation, warning) and color scheme (dark, light, high-contrast, low-contrast) states. Each of these states should enable-disable or modify some prop of the element, in most cases combination of different elements (sibling, child-parent). Trying to write them in inline classes is a PITA, especially the main concern for choosing that direction is just so we don't have a separate CSS file or need to find a name for the class (if you have a component, which Tailwind creators recommend you should, then you already need to find names for your components).

Also in addition to having separate component, component test and view/layout components; we also have separate hook files, separate state/context/store files. Even the component files doesn't encapsulate its own logic inside the same file anymore as to increase reuse of such logic. Somehow we practice separating almost every thing in the frontend to its own file, but when it comes to CSS it's too much "back-and-forth".

Re: Tailwind Isn't for Me

#107
post #98
post #79

Earlier quoted context omitted.

> Without Tailwind, you'll have to come up with a unique, declarative, distinctive name for each and every element you're piling styles upon I can honestly say I've never spent more than 5 seconds thinking about what to name a styled component, do you really get decision paralysis with this?

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…

[deleted]

Re: Tailwind Isn't for Me

#108
post #86

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.

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.

Re: Tailwind Isn't for Me

#109
post #61
post #48

Earlier quoted context omitted.

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…

You... Can't. You literally cannot define a custom element without Javascript.

Like I said: If you want to use the JS-based functionality, you obviously have to register it. Simply using any made-up element in your HTML and styling it via CSS just works ouf the box. See https://codepen.io/dkoch-org/pen/yLwPVYG for a quick example.

Re: Tailwind Isn't for Me

#110
post #93

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"

They still rely on JS to instantiate though unless I've misinterpreted?
Post reply on HN