Can anyone more versed care to illustrate on the matter, since I am learning css properties and don’t expect to abandon the process, isn’t it more of a hassle to need to learn the TW classes now?
Now I know I can rip TW components from all over the place but would that really give me freedom to create?
Pfff! so many questions now that it is introduced into cwicly
Like, is it convenient if the html output is so ugly, doesn’t it create the bloated websites we are trying to avoid?
Well, since this is a discussion board I would like to get some feedback or if there are any other topics I might have missed, I would like to know your thoughts.
It may be useful if the cwicly team share some kind of workflow that suggest why and how TW is superior to bem, dry development and the use of components in terms of ease of use.
Tailwind is the opposite of bloated. It only adds classes used in the website to your stylesheet.
Plus you don’t have to use it, it’s optional. Or you can mix it in with your own css, you literally have the best of both worlds.
I’ve always kept Tailwind aside, thinking that it was not for me for about the same reasons that you mention, but at the same time very intrigued by it.
I read a lot recently and I can see now a lot of pros and a few cons.
I prefer not telling myself because I don’t know enough, and have not practiced at all.
@JulianM I believe that creates a conflict of interest. Kevin stated he would be making ACSS compatible with Cwicly in a future version. He is rather opinionated is all I will say, each to their own I reckon.
In the spirit of asking valuable questions, here is my view on balance:
Does it increase the size of the html output? Yes.
Can it potentially decrease the overall size of the CSS output? Yes
Does it make the html output less semantic? Yes
Can we still develop semantically? Yes, with Shells (added by Cwicly)
Does it add a lot of classes to the inspector in Tailwind mode? Yes!
Does it have some advantages for rapid development? Yes
I personally advocate for a semantic development approach for maintainability and reusability, which to some degree is the antithesis of the Tailwind approach.
As Cwicly has added Shells, even though we don’t get semantic html output, we can still develop semantically in the same way and receive all of the benefits of doing so with Tailwind.
On that basis, it can be seen as a reasonable compromise to benefit from the rapid development and consistent methodology opportunity that Tailwind provides.
This is obviously a per developer, per site choice and we have chosen to use it in our new development projects.
The one thing I personally would like to see solved, to improve the usability of Tailwind mode is to have a slightly different way of presenting the Tailwind classes at the top of the inspector panel, as they can potentially take up a lot of space, the more styles you change. I could have sworn @Marius already posted something about this but upon searching can’t find it, so I may raise a feature request about it.
Its already integrated and BTW the comments of the sorts of “each to their own” don’t help anyone really its like trying to tell you to STFU without telling you to shut up and nah it doesn’t work in my world. But thank you : )
Yeah, a Feature Requests would be great to check if other users see a need for it too.
Although this is on the list already, as Louis mentioned in the live when addressing the topic.
A discussion on how classes could be organized in the UI, and how that transfers to the front-end, since it’s quite important for readability as well, would be beneficial.
Another crucial point, as you mentioned, is how to avoid large class lists pushing down the options/design panel.
Aw! thank you for making my questions so valuable again and answering them accordingly.
So it makes sense to add a discussion about how can we make the html size more optimized and if it really makes it better to use the shells.
I would advocate for the team to suggest related workflows in accordance with components being a better solution or why is the use of shells better than components. Because some of us don’t see the point or just don’t understand the intended paths that @Louis is promoting. He said in the recent live that with proper education…
Besides, not everyone is a condescending programming elitist and from the @Louis mouth, the purpose is to “democratize” development so it makes more sense to demystify the process and take every concern as a valid or “valuable”
@JulianM i believe ‘each to their own’ is most applicable here. Some people prefer ACSS which is an excellent tool. But others prefer Tailwind or even Bootstrap. It is a matter of personal preference.
I don’t see the conflict. If you prefer to use something else like ACSS instead of Tailwind you can easily do so within Cwicly.
Kevin writes a constructive blog where he is at liberty to voice his opinions and people will agree or disagree with him. I am of the opinion that maybe it could have been worded differently to avoid misconceptions. But that is only my opinion.
As for @StrangeTech answering for me, I consider myself very fortunate that he did so. And he is welcome to it anytime he wishes. @StrangeTech, @Marius and several others I have great respect for always taking the time out of their day to help others, including myself in this forum.
In this regard using an alternative to tailwind like acss makes sense to keep the semantic approach and the benefits of usability, maintainability and rapid development right?
I would like to know more about this type of workflow exactly. How components add to this and how it works in terms of html output?
I understand its a matter of preference but I am looking for better options to improve the workflow and the results, I pay attention to the options while learning which one could be better.
As @Louis mentioned in the live, there are pos and cons to both approaches. For ACSS, they use BEMs which can potentially create inflexibility and may or may not suit certain teams or developers and for Tailwind, the duplication of classes in the html may not work for others.
It is definitely wise to keep updated on the different approaches and find the one that works best for your case.
We are also exploring ACSS as an option in parallel to Tailwind, now that it is available.
I have created a new post that discusses this:
HTML output is not changed with Shells, the Shell is an editing only concept that allows for semantic development - the Tailwind classes are still added to the HTML and the Shell itself has no reference in the frontend.
In my testing, the way I’ve been using shells is a shorthand way of combining little snippets of CSS that can speed up workflow, instead of having to do some repetitive things. Shells work well with Components, of course, and can be bundled into other Shells, too.
As a quick, and simple example. There’s often a need to set Flex properties for a container when you’re working. You can have a number of preset Shells that does this in a single click.
Here, I’ve bundled a few properties I was using over and over into a Shell (called “quick-flex-col”). You might ask “why not create a component?”, but this isn’t block specific. I could apply this to a DIV, a Container, a Button, pretty much whatever block or circumstance that might benefit from these particular properties. And, on the front-end, the only thing that gets registered are the utility classes I’ve bundled together.
It’s an amazing workflow tool. I see it as providing the re-usability of global classes, without being as opinionated.
What I’d love to see is the ability to duplicate and edit Shells, to have variations of my utility class bundles.
