Can you please properly educate us on the tailwind integration?

General
1

First of all thank you for improving on the possibilities that cwicly offer, for taking into account the suggestions and needs of many of users including mine.

Thank you for including the new svg block which is a very welcome addition, I’m sure not only for me.

Now the tailwind addition, I understand its a very important step for cwicly on improving workflows and usability but unfortunately its a huge step for me to understand while learning css and web design in general so bear with me so I can explain and provide some insight.

I get that TW actually ease out the process of creating pages by including already build components, just copying and pasting them from many of the libraries available. but even though I’m a beginner and could benefit from that process, I can’t just ignore the process and just avoid the need to know what I am doing every step in order to develop a logical workflow, (there are simply, so many options).

Now it creates issues like the difficulty to read the code output due to the endless lines of classes added to the html, so being the best thing after the sliced bread, what I can see is how easy it is to lose control of my work.

I know there are way more versed people here for whom the TW arrival its just assimilation, whether they have experience with it or have mastered enough terrain in the css field.

But the reality is that many people who come from other page builders and barely know css, TW its a layer added to the learning curve given that cwicly itself is hard to master.

Now, as I heard @Louis talking about making cwicly more accessible his plans after tailwind are to create templates and develop more approachable ways to get sites up and ready faster and also improve the instructional material or something along those lines is related to the roadmap described at the end of 2023.

But then I’m worried that the whole template system is going to be focused on the TW approach for which I am not sure to prefer using in the future for many reasons, knowing that it may be more advantageous in many scenarios.

I speak for myself only but I think the TW introduction benefit a small percentage or the user base, as it makes development more easy but for many it presents so many time draining challenges and learning curves that without the “proper instruction” @Louis said, will end up being more frustrating than not.

So from the latest live, “fact-checking tailwind skeptics”, I can extract a few points that maybe worthy of clarification.

  1. @Louis acknowledge that the introduction of the TW system would require “proper education” are we going to get such, in the form of videos or even tutorials added to the documentation?

I know in the introductory video for TW they say “feel free to search the TW documentation” but it does not seem very helpful since we are talking about the basic integration and if I’m about to go and dig the TW documentation is going to be a long journey while still learning css and how quicly is presenting their tools.

  1. @louis said about shells, that he doesn’t even believe in shells in the first place, even though I appreciate his effort to create a different way to approach global classes and reusable properties outside the ones already built in the cwicly system, I would like to know the ideal that he envisions, with components being the main approach over any other.

I heard something about JS libraries and how the use of classes will come to an end, again I’m so clueless about full stack dev. but isn’t the use of excessive JS for web development less ideal than it is for app development?

So far without TW I use basic classes, variables files and stylesheets that manage my preferences but then with tailwind I need to start at least configuring the TW behavior and I have no clue about it.

So for example how configurations in TW inside cwicly work, and how it overlaps with the system of classes and styles that is already in place.

Now the TW community know some of its faults like the awfully ugly and hard to read output, so they have developed and created many plugins to beautify or hide the horrible parts of the TW code or just make it more digestible. How is this matter being taken in to account for future iterations of TW inside cwicly?

So far I would like to ask @Louis and the team to please develop a more clear instructions, case studies, over the shoulders, or what not on the way they would approach basic web development using the tools we know plus TW from the ground up, like basic file configurations, best practices etc.

I see many people here tying up the dots but I know is not challenging just for me.

I’m not asking for any spoon-feeding here but more of a how you do it approach, to see if it actually fit the needs and workflows of many around here.

Thank you for your attention and for the great work.

2

Hi @JulianM,
omg what a behemoth of a text you have written :rofl:

I’m a little scared to write a comment and I’m not sure if it’s needed any more, as I’ve read some other comments from you that may already provide a couple solutions. But Ill try my best and touch on some points.

Please don’t take my comments pesonally, I’m a cheerful person and often don’t use the right words, so please bear with me & a maybe sorry upfront. :wink:

To make a long story short, I had similar concerns for Tailwind before the 1.4 Life. But I watched some videos on Youtube and could only see advantages, apart from the UGLY html classes list. But there sould be some browser addons that help out with the mega calass rows, as you mentioned that allready :+1:
And with the Life, the rest of my concerns flew away. As it was mentioned many times, you can use it and go on with Cwicly as before or switch to Tailwind. As far as i know/ understood! :thinking:

I don’t know how you used cwicly before, but as far as I can tell, there aren’t that many changes when TW is enabled. instead of px, you use a TW size or number (rem). And I used that for my new test site and had no problems, it was almost more intuitive and even easy… except for the reported errors of course.

I haven’t touched the relative styling, so I can’t say anything about that.

I would say it’s about the whole component story, but don’t take my word for it! As I understand it, a shell would be used for two blocks with the same style, ergo just use a component… But the future will show how this is implemented, as components are not as accessible as a “simple” global class.

Overall I would say to take some deep breaths, the release is not even a week old and the Cwicly team is probably already working behind the scenes to create a battle plan for the problems, help and suggestions that have come up. It just takes a while…

Here a video which I think reflects TW quite well and my main point visitors don’t care which framework you use as long as it is working & you like to use it.

Ill stop writing here since information gets outdated as I write this :joy:

Cheers

3
4

Thanks for the videos I’ve seen them before, the good thing is realizing that sharing videos is at times better form of communication.
For the statement in the last video, about tailwind being the best way to learn css, I would like to know why and how honestly

5

The two videos have many valid points in them.

One thing that seems to be misunderstood about “vanilla css with custom classes”, when people invoke the adage “naming is the hardest part …”, is that semantic class names are not meant to indicate the presentation, they are used to indicate meaning (not what it looks like but what its purpose is).

In this way, the argument that is often used that says “When you use custom classes in your html, you can’t immediately see what they do” misses the entire point. It’s this abstraction that gives them power in the first place!

The original benefit of using semantic classes in separate CSS files and referencing those in the HTML files, is the separation of concerns obviously, but part of that is that any changes in the CSS do not require updates in the HTML.

When you have 1 or 2 html files, updating them when styles change isn’t a big deal, but when you have a larger site (100s or 1000s of pages), then this separation of concerns is the only way to make maintaining and updating the site viable without some form of automation.

Cwicly offers its own ways to address this (regeneration of html/styles, etc) and Tailwind also partially addresses this for some of its classes (the ones without numeric values), for example being able to modify the underlying values in sm, md, lg, xl classes via the config.

Also, for any projects that are edited only within WordPress / Cwicly, many of the arguments against Tailwind don’t apply because we are not manually editing the HTML and it is managed by Cwicly automatically.

Admittedly, when I see the HTML output from Tailwind, whilst I know the benefits, I find it very clunky to look at and would prefer clean semantic classes in the output, however I am willing to put aside my personal preference when needed to explore the potential benefits of the workflow consistency when working in a larger team.

Some of the considerations raised in the discourse are very important ones, such as this one from @T-low:

It will be good to find an optimal approach to customising the Tailwind config that allows maximum reusability of existing Tailwind examples.

1 Like
6

This applies perfectly here

7

There are many videos for or against TaiwindCSS.
At the end of the day, it’s a tool that gives you certain possibilities, and it’s up to us to decide whether we want to use it or not. The same applies to other frameworks.

Cwicly offers us a lot of options and doesn’t force or oblige us to use TW if we don’t want to.

2 Likes
8

I agree with him that it is worthwhile to learn the core technologies upfront when possible, that is how I learned and how I train other people to do it.

On the other hand, having a tool like an IDE or a builder such as Cwicly, can be a hugely valuable resource and timesaver for those in the early stages of learning because by inspecting the code output of WYSIWYG and GUI editors that output clean code, this can be used as part of the learning process.

1 Like
9

Honestly, I failed to notice how packed of information are the youtube lives, I must also say that its a bit demanding of attention listening @Louis and there is not always enough time to watch the entire videos.
After I dig into some of them I expect to be better educated on the features and processes.
Cwicly is indeed an incredible tool in a time that is needed, though it has its learning curve.

Perhaps certain lessons in some of those lives could be synthetized in smaller chunks of information that could be added to the docs site. in video library form.

I get there are some priorities and the team is delivering hell of updates each time.

I apologize if I am demanding in matters that may only concern myself.

2 Likes
10

:smiling_face_with_three_hearts: “Encore,” it’s just how the French mind works, I guess. I had that also once as feedback to him, although I was very conscious of not crossing a line. But meanwhile, I accepted it, and he is such a good programmer and has a great vision. Overall, I’ve got a lot more tolerance nowadays for personal or cultural idiosyncrasies.

They are doing some small lessons, and more will certainly come. If my intuition doesn’t betray me, they are often read by his mom (or he has made an AI version of her voice… one doesn’t really know these days).

For me, I must admit, and I am a bit sad about it, actually. I still am hesitant to go fully onboard. It’s not rational, I know. But I am loving the progress, and I will not be able to stay away forever once the WP site editor finally comes together with the new admin. I play around with it and Tailwind through other contexts. Habits are tough to break, but I shall overcome.

The discussion around Tailwind CSS involves diverse opinions, primarily due to its unique approach compared to traditional CSS practices. On one hand, developers accustomed to conventional CSS and methodologies like BEM have developed systems to tackle organizational challenges within large projects. These systems often emphasize clear naming conventions and structure to manage styles effectively across large codebases.

On the other hand, Tailwind CSS introduces a utility-first approach that encourages direct application of styling classes within HTML, leading to a more componentized and inline styling methodology. This approach can significantly simplify development in team environments and projects utilizing version control systems by reducing the complexity associated with cascading styles and external style sheets. Tailwind’s utility-first paradigm facilitates a “what you see is what you get” model, where the applied classes directly correspond to the styles, making the codebase more readable and easier to manage.

However, this model also introduces a shift from traditional CSS cascading, where styles are often defined globally and inherited through the DOM tree. In contrast, Tailwind’s approach may require more verbose class definitions within components but offers greater predictability and modularity, as each component contains its own styling.

Critics of Tailwind argue that it can lead to bloated HTML and a departure from semantic class names, potentially making the code harder to read. However, proponents highlight the efficiency gains, especially in larger projects where component reuse and consistency are paramount.

In the Cwicly environment, the sophisticated use of virtual constructs, such as shells, provides an organized structure during the development phase. These constructs allow for a well-organized backend where styles and components are neatly defined and encapsulated. However, when translated to the frontend, these structures collapse into streamlined Tailwind CSS output. This results in a flat structure in the page’s source code, devoid of the hierarchical organization present in the backend.

This transformation might be seen as a drawback for those who prefer to see a direct correlation between backend organization and frontend output. Yet, it is not necessarily a disadvantage. As highlighted in various discussions and tutorials, when Tailwind classes are methodically sorted—whether by name, function, or associated shell—this can lead to highly efficient gzip compression. This efficiency is further enhanced by Cwicly’s selective export of only the necessary Tailwind classes for a given page, ensuring that the final output is both lightweight and optimized.

This approach aligns with the principles of modern web development, where performance and efficiency are paramount. The seamless integration of Tailwind within Cwicly, leveraging these virtual constructs, ultimately provides a streamlined, efficient, and highly maintainable codebase, despite the apparent loss of backend organizational structures in the frontend code. This methodology represents a pragmatic balance between organizational clarity during development and optimal performance in the deployed application/page.

1 Like
11

Thanks for your answer, is good to know I’m not that biased.

And thanks for sharing your opinions and knowledge about tailwind, I’m in no way against the introduction of new technologies, but definitely it ads to the learning curve, though still willing to walk the walk.

Here I learned how tailwind can help you build structures like BEM without using BEM and with components, I don’t need to write all that. So yeah, pretty neat.

2 Likes
12

Another great video: TailwindCSS - Best practice patterns