I started a new phoenix project with --no-tailwind and found friction:
delete tailwind classes from core components
delete tailwind classes from layout files
figure out how to add my own style sheet (not obvious that I needed to import it in app.js )
I believe this is technically working as intended as the docs say:
the generated markup will still include Tailwind CSS classes, those
are left-in as reference for the subsequent styling of your layout
and components
However, I feel that they are more of a hindrance. Most people using -no–tailwind probably have no interest in learning what all the class names mean.
I’d like to contribute a PR to phoenix that removes the tailwind classes when the project is created with --no-tailwind. Additionally, I’d like to add a very basic style sheet. This would make the generated pages a bit more usable and provide a nice example/starting point on adding additional css.
I want to gauge the interest/feasibility from the community before spending time on this though. Thoughts?
This has nothing to do with phoenix, it is related to esbuild.
You should consult the source code first, there must be a reason those classes are not removed when --no-tailwind option is used, my thinking is that it will create a lot of boilerplate ifs in the generated templates, but once again it would be great to not have the classes for projects that are not using tailwind.
It‘ll be the exact same problem given your proposed solution. Just added on top that it would require learning a custom css setup, which is not vastly documented with lots of resources online.
And I wouldn‘t expect the phoenix team to be interested in maintaining multiple versions of the same, or worse similar, styles in tailwind as well as in a custom setup.
@LostKobrakai yeah, I agree now that we shouldn’t add another style sheet, good point about maintenance burden.
@D4no0 I looked at the source code and yeah, it wasn’t obvious how to implement this. I agree that an if statement in every html element isn’t a viable solution. What about applying a post processing script that strips the value from every class="blah blah" after the files are generated?
I’m still curious if any non-tailwind users find the tailwind classes useful in the generated code.
Personally I like tailwind, I just don’t think it’s the right fit for every project.
Yes, because there is definitely no point in complicating defaultphoenix generators and by default a developer should think about writing it’s own generator, but …
For what reason LEEX and whole component system has been introduced? Wouldn’t that be easier if all Tailwind classes would be used in core_components.ex only? Assuming that we want to create a phx.new like generator all we want to do is to use a single flag and provide our own core_components..ex when needed.
The topic should already end here and I honestly don’t see why core developers decided to force Tailwind in a way it takes extra time to rewrite generated templates which is exactly against the component concept.
We could argument it wider. One of important thing in Elixir is 10x rule, so we need to write 10x less LOC focusing on main application features + the other rule saying Elixir is easy to extend which was mentioned for example when introducing nx project. In this case however we need to spend time on rewriting already generated templates or part of existing phx.new generator before we would work on our original idea. Ok, we can easily copy-paste the mix tasks, but going this way should we also provide our own Elixir core features? I guess it’s a bad practice and wrong way of thinking, no?
As senior developer I understand the decisions of core developers including whyTailwind is a default choice, but at the same time I can’t agree with a way of introducingTailwind in phx.* generators (having in mind component stuff as an easy alternative).
That’s another edge-solution. Much simpler would be as said using components end-to-end and simply not generate core_components.ex file. If somebody wants to have a bootstrap application then simply would need to write a custom components or use an existing library which is not focused on maintaining a copy of phx.* tasks, but on said components.
Exactly, same as PostgreSQL. Now let everyone think how hard is to change database? Same should be done with all the CSS stuff.