Do you prefer to use Tailwind in your Phoenix projects? (Poll)

[arcanemachine]

This was the first question on my mind when I saw this other thread by @AstonJ.

I’m curious how many Phoenix users actually like using Tailwind.

Do you prefer to use Tailwind in your Phoenix projects?

• Yes
• No

[tfwright]

I understand the criticisms of Tailwind, but I see it as a nice midway point between bland/difficult to maintain Bootstrap-y component classes and unintuitive, clunky vanilla CSS. It suits me as a ““full-stack”” backend developer, which I also think happens to be a good pitch for the average person getting started with Phoenix. Then again I haven’t had to professionally maintain CSS in a while, and from what I observe my FE colleagues doing I’m guessing it’s probably a bit in the way. But like most experienced Phoenix users, I’d guess they make heavy use of the --no-assets option.

[Eiji]

I don’t like it for a few reasons:

1. It’s forced by default in a way it’s not easy to remove. Standalone it would be not a big deal if we talk only about a single generator, but if we have to rewrite each generated template then we simply waste time and it’s against Elixir’s 10x rule where we focus on writing the app’s logic.

2. .css files is not some kind of an old standard that’s currently useless - it exist for a reason. Styles are supposed to be separated from templates and not be part of them. If that would be the case then we would use style attribute instead of class for Tailwind. The Tailwind is overusing class attribute making it harder to read especially for people that does not know all of it’s shorter naming.

3. I’m definitely ok with an idea to keep template code and it’s styles in the same place as I said in another post, but same place (with extra macro above template function or so) does not mean part of template. This makes templates code longer and therefore harder to read. Think if someone would not format templates and would put all element attributes in same line with class as a first attribute. This way we would have to scroll the code just to find things like phx-click which sounds more like anti-pattern than a standard.

4. Tailwind defines a shortcuts for styles. It does not introduce anything besides it. It would be nice if above template function there is a single line macro, but in a more complex case it’s just a long string of abbrevations our brain has to parse over and over again. It’s not using advanced CSS and SCSS rules like nesting, variables, counters, scopes and many more. It’s kind of pre-generated CSS abbrevations you have to configure and a framework that forces you a way of writing your code. It’s more like a framework that forces you to do things in specific way rather than a library that gives you useful tools.

5. I remember that José Valim mentioned that the environment could be simplified (by getting rid of a node staff and so on) and it really happened and then they have added their own dependencies (Tailwind, DaisyUI). I would prefer to see Phoenix templates using SCSS features and variables that we can simply reuse in our code rather than what we have right now. The DaisyUI could be replaced with variables and a simple Colocated Hook, that saves theme to LocalStorage. Not only it would be a very good for learning purposes by using existing LiveView patterns, but also it would not be a theme framework that works over other framework.

6. Tailwind may have compatibility bugs. It happened at least once and it was mentioned some time ago on forum for old macOS version. Neither CSS nor SCSS causes such a problems. Such problems are unacceptable for me. I don’t want that a JS file would not work, because I have too old or too new hardware..

I just wanted to explain that Tailwind and DaisyUI projects solves some problems in a way that does not fits Elixir/Phoenix/LiveView well. SCSS mixins and other functions are more than enough to make styles much shorter. esbuild for JavaScript and dart_sass for SCSS seams like more than enough dependencies we really need. The rest are some extra macros to make templates next to styles and a set of Phoenix variables, SCSS mixins and so on …

Please pay attention how SCSS extends CSS and how Tailwind limits CSS. There are many things that Tailwind needs a workaround to make some things working which just means more short naming than ever needed. If you ever wrote a CSS do you really feel a need to make @media query any shorter? What about a new CSS features that would be not supported until Tailwind would introduce another workaround for them? What’s the reason of using a terrible long class attribute if at the end in complex styles you still write your own CSS?

Tailwind was never an option for me. It’s not about how good or bad it really is. It’s about the way you want to write a code. It’s not like that everyday you fill a need to write some OOP code in Elixir, right?

[dimitarvp]

I can’t vote because I honestly don’t know the alternatives. I am trying to make a partial comeback to being a full stack but I am not rushing it at all and I might also give up. So far I am not impressed, people make stuff complex for reasons that I can’t easily decipher.

To me the maximum that should be done is to insert a tool in your chain (akin to rollup a while ago) that live-recomputes your CSS in dev env and makes a complete file in prod. Everything else is a distraction and it becomes a separate thing to maintain.

I do not want to pay attention to all this. It should have been solved 10 years ago.

[garrison]

@Eiji

is not some kind of an old standard that’s currently useless - it exist for a reason. Styles are supposed to be separated from templates and not be part of them. If that would be the case then we would use style attribute instead of class for Tailwind.

Separating the styles from the markup was always a terrible idea. There was a notion that you could mark up your documents “semantically” with elements and then re-use styles across documents and documents across styles. This has systematically failed. Nobody does this.

So instead you’re just left cross-referencing a giant CSS file with a giant set of HTML templates. Total mess. Zero benefit. Bad idea.

In fact, just using the style attribute would be a wonderful solution, except for the fact that it sucks. It’s ancient and it wasn’t designed for this.

The correct way to do composability and re-use is not to apply the same styles to different elements but to group elements and their styles into components and compose there. This is what everyone does now. We do it with Phoenix too.

Tailwind, as a library, solves three problems:

• Styles should be co-located with components
• Styles should be composable (no name conflicts)
• Design systems should work out of the box

Unfortunately, the utility class approach is fundamentally degenerate: it can never fully express CSS, and CSS is the thing which browser vendors actually support. So you are always playing catch-up.

The series of increasingly ridiculous hacks they have come up with to fit CSS into a class-shaped hole is something to behold. First they needed a compiler to strip the unused classes. Then they started dynamically generating styles at runtime with a made-up class syntax. So then they had to start shipping binaries just to compile CSS, and now they’ve even had to introduce a new Rust codebase to keep things performant.

There is a much simpler solution: web frameworks are already responsible for providing a component framework (we have HEEx). They should also be responsible for providing a scoped CSS implementation to go with it, and an extensible design system out of the box.

(See my comment in the other thread (linked in the OP) for an example of how this can be done.)

[sodapopcan]

c) Indifferent with a slight preference toward vanilla CSS.

Tailwind is great on projects where I’m the sole developer and I have to do everything including design on my own. I like to create my own components as opposed to using a CSS framework that gives you styled stuff out of the box, so Tailwind is great for that. I also find having style right in the markup easier to figure out coming into a project blind or looking at something for the first time in several months. Heavy emphasis on easiER, though, I meant that relatively.

I do know I’m sick of debating whether or not it’s generally a good idea.

[Eiji]

@garrison

So instead you’re just left cross-referencing a giant CSS file with a giant set of HTML templates. Total mess. Zero benefit. Bad idea.

Just one false assumption does not require me to respond to the whole point - that’s a terrible mistake from your side. Who said one giant file? Why you are assuming something that was not told? Why you put words in someone’s mouth? If you would read what I wrote you would know that I prefer SCSS and just like with esbuild the dart_sass allows to work on multiple files and merge them into single one.

I’m terribly sorry to shock you, but at least Bootstrap uses SCSS and does not use Tailwind. Whatever god you believe Tailwind is nowhere a common standard that could stand next to CSS or JavaScript. I didn’t check, but I guess same goes for other CSS frameworks …

@garrison

Nobody does this.

And that’s true, because … you say that? Bootstrap devs are “nobody”? Do you follow all projects in the world including private ones? If I would say that nobody likes ice cream and you don’t agree with that then you are wrong, right? This is inappropriate way of discussion. As you said:

@garrison

Zero benefit. Bad idea.

(for the community)

@garrison

In fact, just using the style attribute would be a wonderful solution, except for the fact that it sucks. It’s ancient and it wasn’t designed for this.

Oh, so the class attribute was designed for Taliwind … let’s check the dates … no. In theory there is no limit for classes as there is no only one right “limit” that would be ok for all projects, but putting 50 classes because you want to keep styles in template is the most messy thing I heard about. Using short naming is also a trouble.

Sure, we can talk with shorts all the time like when chatting using SMS messages many years ago, but this would be childish and hard to read for many people. As a senior developer I prefer rather explicit naming rather than shorting literally anything just to … what exactly? Write less characters? Since there is no tw- or tailwind- prefix there is no way to tell if let’s say hidden comes from tailwind, global styles or both. How does it even close to be a clean solution?

@garrison

The correct way to do composability and re-use is not to apply the same styles to different elements but to group elements and their styles into components and compose there. This is what everyone does now. We do it with Phoenix too.

Yes, indeed. Wait, actually not … We write a hooks and currently a Colocated JavaScript and Colocated Hooks that are not the contents of phx-click and other attributes, but lives in standalone script element. I wonder from what alternative world you came actually. Tailwind is the only popular solution in Elixir ecosystem I know that is focused on putting everything into a single attribute.

And once again “nobody does this” or “everybody does that” is telling what they are supposed to that as otherwise they are wrong. This is not a forum discussion, but an order and a very bad one as typically people that found modern CSS features and SASS more useful in their projects are not going to listing to someone who is saying that they do wrong, because someone said that.

@garrison

Styles should be co-located with components

Oh, so you know the naming - that’s a good start. Now look twice how much JavaScript code you put in phx-click and other attributes and tell everyone that if they are not using JavaScript there it means they are all wrong.

@garrison

Styles should be composable (no name conflicts)

That’s why in programming we use prefixes. If you pay attention you would find many of them … -webkit-, phx- and so on … There is no need to force an extra dependency just to skip prefixes. Like I understand that point. When I was starting with developing I also tried to short everything, make everything myself to make it the fastest and in that way I never finished any project, simply because I have focused on irrelevant things instead of delivering features.

@garrison

Design systems should work out of the box

If you want out of box solution then you use Bootstrap. You really don’t have to write any style unless you are going to add your own components … This way you would have out of box solution and a clean class attribute. Everybody wins. For sure out of box solutions force some styling and design, so all Bootstrap pages looks similar, but this is what you got for a ready and clean solution.

@garrison

Unfortunately, the utility class approach is fundamentally degenerate: it can never fully express CSS, and CSS is the thing which browser vendors actually support. So you are always playing catch-up.

Edit; As mentioned in response below I focused on bad word and didn’t read carefully. It was because of 2 previous things already mentioned. Sorry, for this one.

@garrison

The series of increasingly ridiculous hacks they have come up with to fit CSS into a class-shaped hole is something to behold. First they needed a compiler to strip the unused classes. Then they started dynamically generating styles at runtime with a made-up class syntax. So then they had to start shipping binaries just to compile CSS, and now they’ve even had to introduce a new Rust codebase to keep things performant.

Those argument are in fact ridiculous … We are talking in the context of colocated styles, right? From where stripping unused classes just came from? Why bringing compiler to topic when same could be done in the old-good metaprogramming?

@garrison

There is a much simpler solution: web frameworks are already responsible for providing a component framework (we have HEEx). They should also be responsible for providing a scoped CSS implementation to go with it, and an extensible design system out of the box.

That’s what I was talking about? Either macros or colocated styles … I don’t care which one would be better. Both would be completely different than what Tailwind provides. Still I would expect SASS support and I would still write some global CSS like some theming or layout variables added to :root selector or so. I’ve only mentioned that sometimes people need advanced CSS and SASS features and in that cases even if we would have to do that a bit manually it would be a much better. It depends on the project of course.

If you mention scoped styles then why you over protecting Tailwind then? It makes no sense. You defend one or suggest an alternative … In my point there is a real need for a CSS/SASS support in or around templates (implementation details are not that important if it fits well the rest). If I maintain the whole CSS or SASS code then I don’t have to worry about unused classes and optional features may be done using mixins and other features provided by SASS and soon also by CSS.

[Eiji]

@sodapopcan

I do know I’m sick of debating whether or not it’s generally a good idea.

No, you are not. You’ve brought a very good arguments!

@sodapopcan

Tailwind is great on projects where I’m the sole developer and I have to do everything including design on my own.

Exactly, otherwise it’s a complete mess as you don’t have comments and other things that makes your code clear for a bigger team.

@sodapopcan

I like to create my own components as opposed to using a CSS framework that gives you styled stuff out of the box, so Tailwind is great for that.

That’s also very good argument, but you can do it in CSS or SASS too and for only this you don’t need Tailwind.

@sodapopcan

I also find having style right in the markup easier to figure out coming into a project blind or looking at something for the first time in several months.

For me that’s not true as a single line of short naming that may even require extra scrolling does not looks well and easier to read. It would be more true if there would be a colocated styles that are scoped within specific component.

[garrison]

@Eiji

Those argument are in fact ridiculous … We are talking in the context of colocated styles, right? From where stripping unused classes just came from? Why bringing compiler to topic when same could be done in the old-good metaprogramming?

The section you quoted is about Tailwind. I first listed the problems Tailwind solves, and then described how that solution goes off the rails.

When Tailwind first started out they were shipping the entire set of utility classes. That quickly became too many, so they used a PostCSS pipeline to strip all classes which do not appear in your templates (by regex, basically).

But there is still a combinatorial explosion of modifiers (because they are hacked on top of classes) so in order to handle dark:sm:hover:bg-gray-100 and so on they wrote a compiler that instead reads the template source, extracts the classes, and generates them (as opposed to stripping them). They then went on to rewrite the compiler in Rust. As one does when one runs out of things to do I guess (sorry @dimitarvp lol).

@Eiji

That’s why in programming we use prefixes

Prefixes do not compose. Now you have to worry about prefix collisions instead. Hopefully you only have one component in your entire organization named button.

And yes, I am aware that there are various attempts to add more levels to this hierarchy and no, that is not a legitimate solution. By the time you’re done mangling your class names by hand your templates will look just as bad as Tailwind.

@Eiji

If you mention scoped styles then why you over protecting Tailwind then? It makes no sense.

Because I have noticed in general (and this is not aimed specifically at you) that there is a whole lot of Chesterton’s Fence thinking going on in Tailwind conversations, where people complain about the downsides (which are considerable) while ignoring the reasons people do use Tailwind.

By recognizing the factors behind Tailwind’s success we can construct a better alternative. Personally I think scoped styles are a good candidate.

@Eiji

3rd time … “degenerate”. Why so many attacks for all the innocent people that does not like your favourite tool?

I think you have misunderstood my comment. The “utility class” approach is the approach taken by Tailwind. I am calling Tailwind degenerate because it will never be as expressive as the CSS it generates.

[dimitarvp]

@garrison

They then went on to rewrite the compiler in Rust. As one does when one runs out of things to do I guess (sorry @dimitarvp lol).

Haha, I appreciate the call out. Really.

Obviously writing stuff in Rust does not make it good per se. But they reached for it because they really liked their approach and did not want to do something else so they at least wanted the performance to not stand in the way. But I’ll agree if you say that writing that in Rust was a way for them to not budge on their philosophy. That… seems a touch interesting of a choice, especially having in mind how crushingly true the following is:

@garrison

But there is still a combinatorial explosion of modifiers

Personally I have not gotten all the way to learning modern CSS or relearn SCSS / SASS. I might never do it, too, it’s really unclear what my direction will be even 2-3 weeks from now. I am getting super tired trying to always be a functioning fish out of the water – current work requires me to be super good with Ash and LiveView, both of which I knew next to nothing about just some two short months ago – and me saying “frak this CSS crap” next week is a very real possibility.

What truly baffles me is why isn’t all this stuff figured out already. Must we always clash on philosophical differences and make our own lives harder, and those of the people who use our stuff as well? How about we just build a thin layer on top of CSS that makes it less verbose while still being CSS and let people figure out what to do after? But I am guessing this has been tried as well, though I’ll happily admit almost full ignorance of this area.

It all seems like meaningless busywork though, when you zoom out and try to analyze it.

[garrison]

@dimitarvp

Obviously writing stuff in Rust does not make it good per se

Oh I was 100% trolling, rewriting it in Rust was probably perfectly legitimate. Shipping a full NodeJS binary is more insane tbh.

@dimitarvp

How about we just build a thin layer on top of CSS that makes it less verbose while still being CSS and let people figure out what to do after?

Tailwind does not exist to make CSS less verbose. That requirement stems purely from their need to fit all of CSS into the class attribute without completely obliterating the markup (and yet the results are not great).

Actually all that is needed is to write normal CSS and then scope it. The components come out looking like this. I’m biased but I think it looks just fine!

But more importantly, the class names cannot collide because the selectors are mangled automatically (as opposed to by hand) by the compiler.

Another benefit which I have yet to mention in either thread is that this approach also looks great in browser DevTools. Unlike Tailwind which has no CSS classes to group by (because everything is CSS classes).

[Eiji]

@garrison

I think you have misunderstood my comment. The “utility class” approach is the approach taken by Tailwind. I am calling Tailwind degenerate because it will never be as expressive as the CSS it generates.

Yeah, agree - I have edited my post - sorry.

@garrison

dark:sm:hover:bg-gray-100

That’s 25 characters and all of them for just a single background style. What’s the worst is the fact that’s not even the longest one possible. Besides that you need color, many layout classes and other - all of those in various versions and so on …

You either split class attribute into multiple lines making it longer than the whole element without it which is just insane - or you keep it in a single line and scrolling every element just to find the right class. There is no way that it would be any close to clean solution. We don’t need any other arguments besides this one.

Tailwind may seem nice at start, but the more complex your template is the worse it looks like.

@garrison

By recognizing the factors behind Tailwind’s success we can construct a better alternative.

What’s success? It was forced and many posts were created to ask how to get rid of it completely, how to install some CSS framework and so on … The way it was forced is terrible to maintain and customise if you don’t want to use Tailwind. I can’t call it a success at least in Elixir ecosystem.

@garrison

Because I have noticed in general (and this is not aimed specifically at you) that there is a whole lot of Chesterton’s Fence thinking going on in Tailwind conversations, where people complain about the downsides (which are considerable) while ignoring the reasons people do use Tailwind.

Unfortunately I found such way of thinking giving terrible results in practice. You can’t just ignore downsides, because we didn’t talk about reasons … When introducing something new we shouldn’t add more problems than we already had.

For mentioning what was forced in past regardless of downsides for some idea your post may be flagged, so I can’t provide an example, but I guess millions of people know at least few “mainstream” things, right? For me the not readable code is not a fence, but a wall that should never be reached at first.

Elixir allows developers to focus on business code and by introducing Tailwind we unfortunately went in the opposite way as we either focus on removing it or designing everything from start. If you write all CSS or SASS code by your own then you don’t have to worry about stripping unused classes. This only applies to frameworks that introduces additional classes, but it does not apply to frameworks that only introduce custom mixins and use related SCSS features.

It does not matter what Tailwind provides - if using it makes my code less readable then I can’t even consider it. SASS extends vanilla CSS and I believe that all libraries should be based on it. There should not be any CSS library since as you said there is no sense to adding unused classes. There are just much better tools that does similar thing just a little bit different and I really can’t wait to see a support for it in Phoenix.

[garrison]

@Eiji

Unfortunately I found such way of thinking giving terrible results in practice. You can’t just ignore downsides, because we didn’t talk about reasons

But I am not ignoring downsides. I listed the downsides in my post! I agree they are very bad.

But you cannot just ignore upsides, either!

@Eiji

What’s success? It was forced and many posts were created to ask how to get rid of it completely

I think you are seriously underestimating how popular Tailwind is. It’s been “the new Bootstrap” for like half a decade now. It’s the default for a huge number of frontend devs.

This community is a bubble with a strong bias against mainstream frontend frameworks. Which is understandable (that’s literally why I’m here too lol) but you have to recognize the good and incorporate that.

@Eiji

The way it was forced is terrible to maintain and customise if you don’t want to use Tailwind. I can’t call it a success at least in Elixir ecosystem.

I have called the introduction of Tailwind a mistake in the past and I stand by that. If it was up to me it would be removed from Phoenix tomorrow and replaced with scoped CSS.

But it is not up to me and I would rather spend my time on the positives (advocating for alternative solutions) rather than the negatives.

I agreed with much of your original post. Especially this:

@Eiji

Please pay attention how SCSS extends CSS and how Tailwind limits CSS.

You have perfectly described the problem, but failed to provide an adequate solution. The positives of Tailwind, for most people, outweighed the negatives of The Old Ways (like Sass). That’s why it’s so successful.

The path forward is to design a solution that incorporates the learnings of Tailwind. Particularly: the component-first workflow and the friendly design system (and colors!).

[dimitarvp]

@garrison

Oh I was 100% trolling, rewriting it in Rust was probably perfectly legitimate. Shipping a full NodeJS binary is more insane tbh.

True, but I was not trolling at all. And your trolling had a solidly big grain of truth to it.

@garrison

Actually all that is needed is to write normal CSS and then scope it. The components come out looking like this. I’m biased but I think it looks just fine!

I am not denying it but you should not underestimate the huge lengths people like me go to to avoid learning CSS proper. Of course, as I am writing this, I finally started realizing that I would probably expend much less energy and time by actually learning it proper and doing away with most of the middlemen by using stuff like PostCSS / SCSS / SASS et. al.

That is only the smaller side of the coin though, you inevitably go to work somewhere and you have to learn their own opinionated way of doing things.

With time I burned out. I hate the frontend in general, I just never in my life and career (and I do computers for ~33 years now, since a pre-teen) found solving the problems in the frontend interesting or even mildly engaging; they were always met with impatience, rolling my eyes and the very unproductive “let’s just get this over with and move on to the more interesting things” which of course never ended well.

/rant.

My comment comes from that place. I am a backender at heart and will die a backender at heart. I am just wondering, can it be that, just at least once in this super deficient IT area we have, somebody else figures stuff out and makes it good and universally easy to use?

Of course not.

@Eiji

It was forced and many posts were created to ask how to get rid of it completely, how to install some CSS framework and so on

You’re getting a touch extremist here. The Phoenix team’s core competences by definition cannot include the best ways of doing CSS in a web app['s framework] because nobody can agree on that one best thing out there.

They also want a nice out-of-the-box experience. A lot of people would bail out of Phoenix’s tutorial if it does not come with nice default styles. A lot of people would appreciate naked CSS and super minimal CSS – I think Phoenix used milligram.css at one point? – but most people will go to the website after a HN / Reddit post with zero context and zero care about Elixir itself.

This is a hugely important context. Marketing matters. First impression matters a lot.

I agree with your broader point though: anything that is supposed to make CSS easy is, you know, supposed to actually make it easy, not completely replace one set of problems with another set of problems. Here you’re actually spot on but as I am unlikely to ever become a truly good frontender, I am left to rely on a bunch of 20-25 year olds working in influential FAANG-like companies and those kids are somehow left unchecked to steer hugely important architectural decisions on the frontend.

[garrison]

@dimitarvp

I am not denying it but you should not underestimate the huge lengths people like me go to to avoid learning CSS proper. Of course, as I am writing this, I finally started realizing that I would probably expend much less energy and time by actually learning it proper

Yes, you would.

Tailwind is essentially a mediocre DSL of CSS. The classes mostly map very closely to CSS, and you will not understand them unless you also understand CSS.

This also goes both ways. I have seen people criticize Tailwind by saying it’s “another thing to learn”, which is patently absurd. If you know CSS the meaning of nearly all of the classes is extremely obvious.

In general Tailwind does a great job with naming actually. It’s just a matter of “didn’t stop to think about whether they should”.

[dimitarvp]

@garrison

Yes, you would.

Sure but all of us are instances of a hugely complex struct with different values. Different spawn stats in gaming lingo, if you will. I have tried being a frontender multiples times in my life and came away disgusted every time. It’s just not for me.

Mind you I’ll still force myself through it, if not for anything else but to make my own thing AtOnePoint™. But that will be at my own pace and not forced by work.

@garrison

Tailwind is essentially a mediocre DSL of CSS. The classes mostly map very closely to CSS, and you will not understand them unless you also understand CSS.

I mostly understand CSS. I don’t understand it deeply though, and this is where the problems started for me and for many other backenders who were dragged kicking and screaming into the “we can’t afford to hire a frontender specifically, you can help us with this, right? it’s not so difficult, right?” thing.

But nowadays, yeah. If you want something done right, you have to do it yourself. It’s not the time yet for me, too much other stuff going on and it’s too chaotic still, but when I get to it I’ll learn it and write it down.

I am likely just dreaming though. I am sure thousands of devs like myself thought they can make a heroic effort once and not work on this again… and failed. But we’ll see. Any recommendations in the meantime are welcome. (I’ve read every reply and made some notes.)

[Eiji]

@dimitarvp

You’re getting a touch extremist here.

I don’t agree, extreme things or being on one of two edges is exactly what Phoenix is doing. For sure I don’t care what’s used by default, but Tailwind cannot be just removed by using some option. You have to edit all current and newly generated templates and edit them by hand. That’s pretty edgy if you ask me.

@dimitarvp

They also want a nice out-of-the-box experience. A lot of people would bail out of Phoenix’s tutorial if it does not come with nice default styles.

This has nothing to do with forcing anything. You can make things easily to configure and maintain or hardcode them. I would always call hardcoding a wrong and edgy no matter what awesome stuff it gives.

@dimitarvp

This is a hugely important context. Marketing matters. First impression matters a lot.

Unfortunately I can’t agree with it for a few reasons … First of all Tailwind is just a tool - it does not give first impression in look and feel. CSS frameworks like Bootstrap do, but not tools … Also one more point … marketing today? Really? See mainstream, see all scam and tell me that you need to have amazing product to do a good marketing result … That’s todays sad reality. Otherwise if Tailwind would give out-of-box styles like Bootstrap then I would almost fully agree or like fully agree with my own preferences being still different.

One point here is that I still respect some frameworks that deliver first page as simple as possible and focus rather on how to integrate out-of-box styles in guides rather than come with something fancy that some % of people would remove anyway. Each tool should focus on it’s own thing and I believe that all fancy stuff should be reserved for Phoenix main page rather than the generated pages.

Personally if I would have developed generators I would focus on harder things like a correct HTML5 markup with a full ARIA support as it’s much bigger problem for many devs than integrating said Bootstrap or write custom styles. Correct ARIA would be same for many projects while styling is different in each project. Nobody expects from you to pre-style generated pages to your likes, but everyone want things delivered fast, so they can work on features asap.

To summary … fancy things to official page rather than generated one. Documentation over forcing styles. Ease of configuration and maintenance over hardcoded solutions. I have no negative feelings to any tool - only code readability preferences. Whatever would be hardcoded in every template I would be against of it. Whatever would put dozens if not houndreds of characters into a single class, phx-click or any other attribute I would not like it. I don’t believe it’s extremism way of thinking …

[hauleth]

I do not see the value of Tailwind at all. It still requires me to learn CSS, but on top of that I also need to learn their own custom nomenclature full of abbreviations and custom units. If I need to do that, then why not just simply learn CSS and skip all the Tailwind magic?

When I do p-7 what is that 7 mean (or maybe that is -7? Who knows)? How does it relate to something like size-48? If I want to have some colour to stuff I need to use grey-700? How does that relate to grey-300 or orange-300? If I do grey-700 on purple-300 will it have enough contrast or what?

Modern CSS also adds a lot of useful stuff that provides a simple way to avoid most of issues that people had previously.

• Cascade layers provide simple way to avoid specificity issues in CSS resets or libraries
• Relative colours provide a way to modify colours in sensible way
• CSS Nesting provides a way to improve readability and to not repeat yourself over and over again
• Custom properties (aka variables) provide a way to name values

There are even more upcoming things like typed attr() CSS function, which will allow me to use just HTML attributes for customisation if needed.

In addition to above - with semantic CSS I can style using ARIA attributes, so it will “force” me to implement proper a11y features from day one, and when I come back to the code, I can read what does the values mean instead of deciphering arcane shortcuts.

<form>
  <input type="text">
  <button type="submit">Action</button>
</form>

Vs

<div class="container display-flex my-md mx-sm">
  <form class="form shadow-md my-md mx-sm align-center">
    <div class="input-wrapper border-radius-sm">
      <input type="text" class="input text-color-gray placeholder-color-light-gray focus-outline-blue">
    </div>
    <div class="button-wrapper border-radius-sm">
      <button type="submit" class="button bg-color-blue text-color-white focus-light-blue hover-light-blue">
        Action
      </button>
    </div>
  </form>
</div>

Honestly - TailwindCSS, with all tooling that is created around it, seems like designed for AI slop and to move complexity around (and IMHO in the wrong direction).

And now, whenever I start new Phoenix project, it is yet another thing that I need to go through codebase and remove. That is becoming so painful, that I probably will need to sit and just write my own generator, because “default one” became so full of pointless cruft.

[garrison]

@hauleth

I do not see the value of Tailwind at all.

This is exactly the same attitude I was referring to above. I do not understand this insistence on refusing to study the good parts of a popular solution. You are essentially just telling people “I don’t care about the problems you have” and then are surprised when they ignore you and use the thing that solves the problems they have!

Here are the problems, again:

1. Styles should be co-located with components
2. Styles should be composable (no name conflicts)
3. There should be a configurable design system that works out of the box

@hauleth

Modern CSS also adds a lot of useful stuff that provides a simple way to avoid most of issues that people had previously

Let’s now review how modern CSS solves zero of these problems:

1. There is no way to co-locate styles with components (the style attribute is bad)
2. Nesting does not solve the naming problem and also still does not compose properly (think about what would happen if you used HEEX slots)
3. Lol, lmao even. The only genuine improvement here is oklch, and that’s a stretch.

@hauleth

When I do p-7 what is that 7 mean (or maybe that is -7? Who knows)?

It’s literally just a scale. It’s configurable! What does rem mean? How many physical pixels are in a logical pixel?

@hauleth

If I want to have some colour to stuff I need to use grey-700? How does that relate to grey-300 or orange-300? If I do grey-700 on purple-300 will it have enough contrast or what?

They are just color scales, chosen by hand to look decent as it turns out that used to be really hard. Maybe we can finally move on from this nightmare with oklch, though. But this has nothing to do with Tailwind, many do the same thing with variables (I do).

@hauleth

Honestly - TailwindCSS, with all tooling that is created around it, seems like designed for AI slop and to move complexity around

This is nonsense, Tailwind became mega-popular well before the LLM apocalypse.

@hauleth

And now, whenever I start new Phoenix project, it is yet another thing that I need to go through codebase and remove. That is becoming so painful, that I probably will need to sit and just write my own generator, because “default one” became so full of pointless cruft.

Agreed. But does --no-tailwind not work anymore? I haven’t generated a Phoenix project recently.

[Eiji]

@garrison

Here are the problems, again:

1. Styles should be co-located with components
2. Styles should be composable (no name conflicts)
3. There should be a configurable design system that works out of the box

@garrison

Let’s now review how modern CSS solves zero of these problems:

Let’s review how Tailwind solves all of those problems creating new ones:

1. Overuse of a single attribute makes markup terribly long, hard to read and maintain
2. We are not allowed to name a button like a button, but there is no problem with Tailwind naming - it’s using class names too! None of them are prefixed or protected in any way!
3. Tailwind does not have one. It only replaces CSS variables with classes and requires from you to design everything - there is even no real solution here …

@garrison

Lol, lmao even.

and that’s the best summary

@garrison

It’s literally just a scale. It’s configurable! What does rem mean? How many physical pixels are in a logical pixel?

Scale X or scale Y? It’s not a scale at all
What does it change that’s configurable? It’s like the one-letter variable i.e. something that’s rather seen as bad practice used by beginner developers.

@garrison

What does rem mean?

Even if you don’t know it then you know that’s a part of syntax. There is no rem in CSS. There is a 1rem, 1.5rem and -137rem. Because it’s all about syntax and code highlighting we know that’s a size unit. That’s terribly easy to research. No tell me how would you search for p? Algorithms have often a problem with context, so even if you write Tailwind p then you may not found the expected result in your personalised search …

@garrison

They are just color scales, chosen by hand to look decent as it turns out that used to be really hard. Maybe we can finally move on from this nightmare with oklch, though. But this has nothing to do with Tailwind, many do the same thing with variables (I do).

Why even mentioning oklch?

color: hsl(from rgb(255, 0, 0) h s 10%);

That much more clear piece of code.

@garrison

This is nonsense, Tailwind became mega-popular well before the LLM apocalypse.

Do you know what you are saying? Do you values everything based only on popularity? That’s really a nonsense. Well … good luck with spying Windows as this is the most “popular” solution.

As I already said in various places LLMs are nothing new. The AI rebranding is relatively new, but the original works that were foundations for current so-called “AI” started in early 1990s. Of course dates don’t prove anything, but just for the context the initial release of Tailwind CSS is 1 Nov 2017. It’s not so old solution. It’s even younger than Elixir (2012).

@garrison

Agreed. But does --no-tailwind not work anymore? I haven’t generated a Phoenix project recently.

It only removes the mix dependency and it’s configuration. All generated and newly generated templates still have “utility classes” that could conflict with existing styles if not removed carefully.