I used to be part of the music scene back in '95 and it basically changed my life. I'm so proud to have a presence somewhere in the dark corners of the scene.org FTP.
This is what I personally do. I have small needs when it comes to backups (< 1TB), so I have one backup that's just a regular HDD stored in a drawer, and another one that's on a Scaleway cold storage container.
I don't get Tailwind. In my book, CSS is here to facilitate the style of multiple webpages by modifying a set of rules, and classes are here to mutualise said rules.
With Tailwind, it looks like you design by writing HTML, which is the opposite of what CSS aims at. So if you wish to change your design, you'll have to update multiple templates instead of one CSS rule.
Every time I've had to work with Tailwind, it felt like a chore and it was an unpleasant experience.
> So if you wish to change your design, you'll have to update multiple templates instead of one CSS rule.
Changing the CSS to apply site-wide changes sounds great in theory but after working in front-end since IE6, this almost never happens in practice. You're never certain how the styles cascade and indirectly affect things so you're afraid of changing the core CSS.
Styles isolated to components is a much more scalable approach in my opinion and then it doesn't really matter whether you use Tailwind, CSS-in-JS or scoped CSS (Vue etc).
I do use tailwind and I find it terribly convenient for some things, but this argument still seems to mostly stem from too many people doing css who are not great at designing css and are doing things they really should not.
How will I ever keep track of where I used px-6 and where md:px-4 in my templates and why, without semantic classes? Of course I can then build more solutions around that. Or I can accept that good css design is hard, just like any good software design is hard.
Let's solve that by switching to a different abstraction that proves to be more useful. In this case, isolation-by-component instead of isolation-by-class.
I'm not the person you're replying to, but I'm in a similar position, and while I'm not in love with Tailwind*, it's successful because it's oriented around components rather than classes. In every project I've worked on, it has been far easier to manage the complexity of components over classes, because components link style and structure together, which usually end up very tightly coupled anyway. This limits the scope of the CSS you're writing a lot, making it a lot simpler to understand what any individual declaration is going to do - you know exactly where it's being used, you know exactly the HTML structure it's operating on, you can see exactly what it will do as a result.
* I use it a lot at work because it's very easy to get something written, but I find the pseudo-CSS DSL irritating if I need to write more complex queries. Something like CSS modules requires a bit more boilerplate to use, but you end up writing real CSS queries, which I find more natural. But this is personal preference.
Its hard keeping track of different usernames on here.
From my perspective, "almost never" and "won't actually happen" aren't that different. Both indicate that the probability of success is very low. It seems to be, if the probability is already really low, is not worth extending effort maintaining it.
> You're never certain how the styles cascade and indirectly affect things
Then your DOM is too complex. You're formatting a text document; that shouldn't get you in a position where you lose track of what cascades where. If it is you have a bigger problem than styling.
I agree with you. As a developer I like the separation of style and content. We also gain better readability when the code says "<div class="product-price">199</div>" than a long list of tailwind classes.
CSS styles are also more reusable across different web sites. I can to some degree see that you can increase re-usability when using shared React components, but then you just create technical debt for those who want to test other frameworks
It seems to me that Tailwind is only a semi-scalable solution for those who use React components or similar. But as mentioned above, that causes problems when you want to make other webapps in another framework
Can you explain something about why you prefer the separation of style and content? From my perspective all that it accomplished is making me modify two files (html template and CSS) instead of one.
There are several advantages of separating CSS and code from my point of view.
- I generally dislike inline CSS styles, and the benefits of Tailwind is not enough to overcome that.
- Reusability across systems. At least in mature businesses, they often have CMS systems, different frameworks etc. Using Tailwind kind of encourages everyone to use the same internal React component library.
- Easier to read PR and git logs. Adding a single tailwind class to a component may mark the entire line as changed, and you need to figure out what has changed (including checking the code, because you don't know if that also changed).
- Designers can make changes in CSS without having to learn React.
As soon as you have recurring product prices, you’re encouraged to use @apply to group those classes. In practice, however, you’re using components of some sort anyway, whether in Frontend or backend code, so this isn’t really an issue.
It’s a completely viable solution for certain situations, say, having a .button class. The things mentioned in that twitter thread have nothing to do with that.
I was commenting on "As soon as you have recurring product prices, you’re encouraged to use @apply to group those classes. ". It's certainly technically possible to create a CSS class. But AFAIK the recommendation is loudly and clearly to use components https://tailwindcss.com/docs/reusing-styles#extracting-compo..., and for good reason.
I follow, but even that part of the docs acknowledges the use cases solved by @apply. No denying it’s a powerful gun to shoot your foot with, but it has its merits. Especially in the OPs context of some bespoke e-commerce CMS, which might not even have a frontend pipeline more sophisticated than grunt or something.
> if you wish to change your design, you'll have to update multiple templates instead of one CSS rule.
this comes up on every tailwind post and it isn't true. tailwind encourages you to not repeat yourself by making reusable components (or fragments etc) instead of reusable classes. that way if I want to see how the button both looks and works I only have one place to look
even if you don't do this, with tailwind you encode your design system (colours, spacing) etc in the config file so even copy pasting everything will get you something consistent
I don't feel this point is strong because when you look at some of the most popular Tailwind components or templates in the ecosystem, such as the one made by the Tailwind people, the Tailwind code is still pretty crazy.
I think your last point has legs, for sure. It makes sense that some other language will compile to wasm and make some app development more straightforward, but I don’t think the end result will be that different.
The web platform is not going to move away from current paradigm without an overwhelming shift in priorities or needs. Wasm still generates html and outputs it on the screen.
My biggest reason to use tailwind is maintainability. Having everything right in front of me with only the tiniest of abstractions, makes it really simple to refactor and maintain. I can confidently delete “CSS” and know it has no side effects. I can cut and paste a block of html and it will render EXACTLY the same. I don’t have to worry that Steve used a generic sibling selector in a CSS file 3 years ago that is screwing with my layout/design.
Is the HTML more bloated than if I had written “normal” css? Yes, but I think it’s worth the trade-off. It’s important that we can agree that their are trade-offs and then it’s up to each project to decide if those are worth it for their use case.
I’ll also mention the actual CSS file is crazy small as well since the tool only generates classes that are actually used in your project. No more ever-growing css that other people are afraid to delete for fear of breaking some legacy page!
> Wasm still generates html and outputs it on the screen
Sure it can. More usefully to my point though, it can also use any of a number of C++/Rust/etc. UI libraries to render directly to a buffer or canvas, which is in my opinion a better long term solution for true applications (vs websites).
When you do that you get total layout control with no need for CSS or worrying about browser defaults.
As a random example here is the Rust egui library demo app running in a browser using WASM (no HTML): https://www.egui.rs/#demo
The speed and “native application” feel are hard to replicate in JS/HTML, as they are just not great tools for the job or rich desktop (or desktop-like) applications.
In my understanding it somehow abstracts the process of styling a website or whatever and make it easy for people who for any reason don't want to write CSS.
Although I have the sensation many people find hard to write CSS and even despise it (I've read people here in HN who seem to think we should've kept doing layouts with HTML tables and don't agree layout is the job of CSS!) I definitely agree having dozens of classes in your HTML is messy and weird.
It’s all stuffed in classes because that’s the limitation given and this information belongs in the markup.
The above is much cleaner to me than: div.class(“primary”). I need to go find primary. What is the parent class. What happens if this isn’t a div now etc. what happens if the parent isn’t a div?
Tailwind just spells it out for you right alongside the layout so that you have all the information in one place.
For me personally, I was able to do things in tailwind I could never do in raw css, but I bet I got better at css as a result.
The docs are also incredible for tailwind. As good as mdn is, you need to already know what you’re looking for.
It's much easier in Tailwind for me to see locally what's going on with that styling. If I lived in this code all the time, or I was good at structuring CSS, then maybe the first would be more appealing. But I'm a shit at CSS, it always turns into an unmaintainable mess, and I look after a lot of different projects that I might not touch for 6 months. So Tailwind's approach is easier for me.
My solutions to the problems you raise, in order of preference:
1. Not worry about it, it probably won't happen on the projects I'm working on. YAGNI.
2. OK, it's happened. Get some coffee, make all the changes. Can I use a regex? Make the changes incrementally? Delegate it to a junior?
3. This is going to change a lot. Let's make a re-usable component, a named colour like 'primary' (in Tailwind config), or re-usable class like .button-default. The right solution will depend on the requirement.
In styling, I'd rather have 1000 obvious changes than 1 difficult one. The risk of having the wrong shade of red is not high enough for me to worry about abstracting it.
I appreciate that good, full-time CSS devs have much better solutions for this, but those solutions involve being good at CSS as a starting point. I don't have that luxury.
In tailwind you'd probably use a named color such as `primary` or `border-primary` or something like that, so you still have the ability to change it in one place. I don't really like tailwind myself, but I don't think that's an issue
1. Given the example actually provided here, do you see an opportunity to do that?
2. Suppose you change the example to use named colors. Where does this name-to-color-value mapping live?
****
> I've noticed that moving the goalposts is extremely prevalent on HN, which makes for pretty frustrating conversations (or just reading). And then sometimes it's a tag team. E.g.:
> Person A writes their comment. Person B1 offers a rebuttal. Personal A offers their response. Person B2 offers a second rebuttal that abandons the premise behind B1's rebuttal, and may actually be at odds with it. Person A ends up either deflated or looking defeated.
> It's like the cross product of a Gish gallop and a DDoS.
As stated elsewhere, if you're using a component based UI, this isn't a problem. You're also free to mix regular CSS with Tailwind.
As for the "git gud" school of CSS, should we also abandon React, Svelte and the like and revert to hand-cranking DOM manipulation like it's 1999...?
Sure, if you're manually editing a large volume of .html by hand, Tailwind is bad news, but given the plethora of static site builders out there (brief shout out to Astro which is excellent), manually authoring individual .html pages seems like masochism.
Sounds like a boring Friday afternoon job, or something I could give to a junior contractor. It's also something that doesn't happen very often on the kinds of projects I'm working on.
In React at least, often you can live with One Component = One File at least for simple components. Adding separate CSS files, as the OP says, causes context-switching.
This is not true in svelte, where a component file can have both a root tag for the component, and a <style> tag that the framework/compiler automatically scopes to this component (and a <script> tag for the code, since you don't have the JSX inversion-of-control principle).
You can utilize the Functional CSS approach to eliminate the redundancy of architecture and behavior across various instances (JSX and CSS). Furthermore, it offers superior performance when compared to OOCSS.
One example is if I was using react it would be used to encapsulate a react-router Link and an anchor tag in a component, and use props to differentiate between inbound and outbound links.
Suppose we want to change just one link? Would it be better to make a new class with all the same attributes except the color and apply that to the specific link.
> Suppose we want to change just one link? Would it be better to make a new class with all the same attributes except the color and apply that to the specific link.
Why copy the attributes? Just override the one you want to change. You can even use style="…" if you're sure that it's just one link.
The tailwind version is actually horrible, don't do this: you are supposed to style all the links in the same way, as with the css example, not style each link in it's own way; or you will get a link red, another one blue, another one yellow, and your ux will be crappy and your code unmaintainable
Horrible.... for you. For me, it's lovely. My UI productivity and satisfaction has massively increased with Tailwind, and I've been using it for 3 years now.
That isn’t a Tailwind feature though? That’s been like a basic feature of CSS frameworks for 10+ years. Even Bootstrap was going this route way back when.
Who rolls the basic boring CSS classes like border-red or border-primary by themselves? People have been doing it for free for over a decade.
That misses the point. This is still worse than seeing all your styles in the place where they apply. SASS/LESS just make it faster and more succinct to write styles in css files rather than in the components in which they live and even more importantly—on the actual ELEMENTS that they apply to.
I think the framework is meant to be used by other frameworks and not by humans.
It is an unpleasant chore if you use it by hand and I have given up on it but I can see that if it's just used in components and then html is not written by hand but made dynamically it could work better.
It's basically a CSS framework for JS frameworks and not for writing HTML.
In a recent thread someone explained Tailwind was best used with component frameworks, and that made it make a lot more sense and I could see the appeal.
It’s actually one less layer. My layout and styling are finally together, and well documented. I don’t mean in the same file like a .vue file. I mean they are TOGETHER.
Looking at FEZ levels instantly made me want to see if there was something hidden in the levels' names. I've yet to finish it, and boy is this game amazing.
I've had the pleasure to build a small website with Kirby and it was such a joy to use as a developer. The only problem I faced was with my client as he was used to Wordpress and making the transition to Kirby was a bit rough for him.
Can you unpack this a bit? What was rough? How much of that was the client not being able to change?
I'm lightly looking into alternatives to WordPress. Obviously CraftCMS come up, but being a paid product - nothing work with that per se - does limit its appeal for some projects / client. So maybe there's a place for Kirby?
> Just give me an app that can handle nicely markdown files
You know what does that well? The filesystem.
I've tested pretty much all note-taking software out there. What ended up working for me is a bunch of markdown files inside folders, synced using Github.
I have search, formatting and preview thanks to VSCode, and I can access my notes on any machine that syncs with Github.
I agree. BJJ brought me to a place of happiness that was amazing. I felt completely connected with my body.
Then I hurt my back three years ago doing weight lifting. I haven't been able to practice BJJ ever since, and I've been suffering with constant anxiety for the past three years. Every day since has been a struggle, with some really bad days, and some better ones.