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.
- @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.
- @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.