Absolutely AWESOME video! I’ve been wondering about tailwind on Bricks since I bought Winden a couple months ago, but haven’t taken the time to investigate. Glad I have it, thanks.
Thanks Alex, great video. I have been wanting to know more about Bricks and tailwindcss thanks for saving me time and putting them both in one video. Keep up the excellent work.
Hey Alex, Thanks for the video. I always wanted to add Tailwind to WordPress. But, there wasn't a tool to integrate. I got my hands on Winden last week and I am loving it. Great information on your video.
Thanks Aravinda! Really appreciate you taking the time to watch the video. Feel free to reach out if you have any questions re tailwind, winden or nintu. Always here to give back to this awesome community
I'm an ACSS user. I use ACSS for the framework and for the tutorials on best practices when using CSS. He says to use ACSS classes/ variables, but you're not limited to it. He says to use regular CSS or SASS when needed. I like the BEM naming convention for classes. I'd like to ask a few questions, if I may, before I buy your product, please? Is using the BEM naming convention for classes any good, as it wasn't mentioned in your video. Since we are using multiple classes to build a component using tailwind, i.e. FAQ section. If you have the same component on different pages, do I need to add all the tailwind classes again on every page?
Juan is correct although it kinda defeats the purposes of using a utility system if we're then going to create components through CSS. In my opinion I think the best way to do this is to just create your templates via the bricks template system (as sections) and then load them on your page by using the bricks template element. Example of this on Nintu, Every FAQ, CTA, post grid and dark mode button is just one template that I edit from one place and is being loaded as a section where I need it.
@@juancamilochaves2179 apply method should not be used like this. Even the developer behind Tailwind regrets implementing it and wishes he never had. The problem is that with WP page builders, the argument of using Tailwind for scalability and maintainability goes out the window. Whether it's apply or theme()
I don't think either of these statements are true. The author wishes people would work within the methodology and some people use the apply function to treat the framework like generic css instead of using the built in tools to streamline. Out of context it sounds like he hates apply, but in reality it's an awesome function that is very well supported and documented, just with great power comes great responsibility. I've just put together a video on how you can create components, templates and styles globally. The principal is the same with WordPress as it is with any other framework (vue, react), but quite different from what people are used to making it hard for some to adopt. Not everyone is open to change :) If curious, feel free to take a look here: th-cam.com/video/Z2vJMGePxQI/w-d-xo.html
12:18 I was about to purchase the winden plugin, but while doing a little research I came across a lengthy blog post titled "Using Tailwind with WordPress page builders is a bad idea" written by tje ACSS plugin but quoting numerous conflicting instances of winden's dev himself. Now I am back on the fence about winden. Any thoughts about how valid the points from said blog post are?
Yeah a lot of misinformed content written by an author who is looking to justify his own product. I had a lengthy conversation about it with someone this week, will post the conversation below. In short: it's easy to diss a solution when you're looking at things from the wrong angle. I'll put together a proper video addressing it in the coming weeks. In the meantime here's the chat: ______________________________________________ Chatter: yes have seen your video regarding this, but it doesnt really makes sense to me if you are using page builderss. It would make more sense making global classes. ______________________________________________ Alex: can you shoot over a couple of examples / use cases where you think it's a bad idea and ill send back how i tackled it. I think there are pros and cons to each but for me the pros far outweigh everything else. There was also quite a lot i had to learn the hard way when building Nintu, and had to go back and rebuild parts more times than I would have liked. with the lessons learnt im pretty confident in the scalability of everything and managing templates or parts that are reused is done consistently. but yeah, shoot over some use cases for which it doesn't make sense and I'll explain. the article above is isn't great, there's not much understanding of how to properly use tailwind. That "give a guy a hammer and everything looks like a nail" quote comes to mind. The examples aren't great and the way you would handle the problems outlined in the article are not what he presented as solutions. its like looking for the worst way to solve a problem with tailwind. ____________________________________________ Chatter: """Tailwind is a popular "utility-first" CSS framework that bills itself as "an API for your design system." But, as you'll learn in this article, it's a bad idea to use Tailwind - or any utility-first framework - with WordPress page builders. Note #1: I'm not going to use this article argue whether Tailwind is a good or bad framework. That's a separate discussion that would require its own article. Note #2: I'm not going to go in depth on all the issues with Tailwind. I'm only going to argue why it's bad choice for page builders. So, if you think this article is long and detailed, remember that it's only the tip of the iceberg when it comes to potential issues with using Tailwind. Note #3: The facts I'll outline here won't stop a lot of people from insisting that Tailwind is a great fit for WordPress page builders. I'm sure these people mean well, but they're wrong. And they're not only wrong according to me, they're wrong according to the creator of Tailwind. Note #4: Many people will dismiss this article by saying, "Kevin is arguing against Tailwind because it's in the best interest of selling more copies of Automatic.css." That's nonsense, of course, because I always say/teach whatever is in the best interest of my audience (which goes far beyond the ACSS world). In any case, that's why this article uses the words of Tailwind's creator to make my case. It helps keep this article as objective as possible. Cool? Let's get started! What is Tailwind? Tailwind CSS is a utility-first CSS framework for rapidly building custom user interfaces. It is a highly customizable, low-level CSS framework that gives you all of the building blocks you need to build bespoke designs without any annoying opinionated styles you have to fight to override. GeeksforGeeks That's a good marketing description, but there's a lot more to Tailwind than that. In reality, Tailwind is better described exactly as they describe it on the Tailwind site: "An API for your design system." It's a MASSIVE framework with a STEEP learning curve. You can browse the Tailwind documentation to get a pretty quick understanding of how massive and technical this framework is. Also: I'd guess that most people who advocate for using Tailwind with WordPress really only know/understand the base level of Tailwind and aren't really using it anywhere close to its full extent. Most important of all, Tailwind wasn't designed for WordPress page builders or with WordPress page builders in mind. This fact introduces a fundamental problem... The fundamental problem: using Tailwind with WordPress page builders isn't scalable or maintainable When you're building sites, it's important to think about the future of the site. While you're likely working from a specific design in the beginning, that doesn't mean your design will never change. And it doesn't mean you'll never make a design mistake that then needs fixing across many blocks. Knowing this, good developers put a lot of time, thought, and attention into building sites that are easy to adjust, iterate, and maintain. When I talk about scalability, that's what I'm referring to. How easy is it to change things? How easy is it to add new things with identical styling? How easy is it to maintain consistency? How easy is it to work with teams? Tailwind *might* be a great option for front end frameworks like Vue, Angular, React, etc. because you can maintain scalability in these environments. But when it comes to WordPress page builders, it's a fail. Want specifics? No problem. An inherent problem with the utility-first philosophy Tailwind is a "utility-first" framework. When a framework is "utility-first" it means that you're supposed to use utility classes for everything. You're not creating custom classes and you're not writing any CSS. That's the goal anyway. Why? Because "coming up with names for custom classes is hard" ... or something (Yes, there's a little more to it, but not much). So people got the idea to use utility classes exclusively. This breaches the very definition of "utility," but whatever, we have bigger fish to fry. Right off the bat you might notice an issue with the utility-first philosophy. If you don't assign custom classes to things, how do you retain global control of element styling? How can you create one "source of truth" for specific re-usable blocks? For example, let's say you create product card with an image, heading, description, price, and a few other elements. It could take two dozen or more Tailwind utility classes to create a single card. Now, you duplicate that card 8 more times to create a product grid. And you use that same grid on 5 other pages of your site. What do you do when the card design needs to change? You sure as Hell don't want to go page by page, block by block, element by element removing utility classes and adding new ones. That'll make you want to jump off a bridge. There's gotta be a way to retain global control, right? // PAUSE. Let's pause for a moment to point out the fact that this is ONLY a problem with utility-first frameworks. If you use CSS the way CSS is intended, there's no problem here. You create custom classes and then you have automatic global control over your elements using those custom classes. Change styling in one place and it changes everywhere you've used that element. Simple! So, by introducing Tailwind and the "utility-first" philosophy, we're introducing a huge problem that we then need to solve.""" _________________________________________________________ Alex: Awesome! So.. To me there are two parts to this: 1: the mindset behind it all: this is something I resonate with but isn't for everyone. you're trading complexity in jumping back and forth between a css sheet and the html for simplicity where its all easily identifiable and in one place. This is something that I am happy to trade for because I usually work on quite large projects and it's difficult to keep track of different systems on different projects and keep it all clean. it also means that i can have multiple styles on a single project without having a massive css file. (in our case, lots of templates with lots of different UI styles). but even on real world projects, you would have a different border on different sized elements in line with modern design standards. 2: real world use case: this doesn't actually happen very often. if you're creating a grid of product updates you would have it in a repeater and just style it once. Most things that actually need repeating live as bricks templates. So if we look at the nintu site as an example: every CTA is the same one inserted as a template, every FAQ is the same template, every category and template page is generated dynamically from a single template etc etc. There are not many "standalone" pages, most are templated and editing is all centralized. With all that said I did run into the issue kevin presented once. with pricing pages. as they're not templated it was a pain to update. But, of 100+ pages that currently exist on nintu it only happened once. So he's not fundamentally wrong, just it would be a bad idea to build in the way is presented in the article. You can also edit all the global values if you wanted to. in our case everything that involves space (margins, paddings, width) is custom and fluid, and we have a custom palette of primary and neutral colors. you can change pretty much any of the styles globally (or add your own that integrate into the framework) but the default ones work quite well in most cases 😉 ________ Let me know if that doesn't quite cover it and which areas are confusing, it will really help me to make a good quality explanation :)
@@itsNintu What irritated me most in said blog post, is that Kevin used Adam's own tweets and arguments to reinforce his claims. Admittedly, as a layman, I couldn't wrap my head around every problem/solution stance that was illustrated in the blog post. What I understood however is that the problematic use cases put in question by Kevin are more in case of big projects, than for small website owners like myself. This is why I think more how-to video tutorials on using Bricks with Winden and Tailwind will clear a lot of the fog, especially for folks like myself coming from Elementor, and just getting started at this "more control" level (AND a black-friday coupon code for Winden's lifetime deal would also help 😁).
Haha I'll let you know if I hear any news re a black friday promotion. And yes you're correct, but not just for small projects, projects of all size. The @apply function with tailwind is intended to allow users to edit other people styles that were created outside of tailwind, not to design an entire website. Which is why adam has some hard feeling about it but also a bit of a low blow to diss an entire framework. It's actually a great tool for us in the wordpress space as it allows us to connect other plugins to our design system and keep it all integrated with tailwind. In a real world scenario, you would build a whole site, small or large with winden/tailwind. And then you add a new plugin that doesn't support custom classes (a form plugin, grid, or something along thones lines). Instead of having to style your new plugin (lets say a form for example), you can just connect the plugins css classes to your tailwind system and bam! All your styles are connected and work together. I think ultimately there's just a bit of salt from ACSS because their plugin doesnt have a JIT engine to support massive amounts of classes or any way to connect their styles to other peoples work. Unfortunately they chose to bad mouth the product that can do it as a way to justify not being good enough...
Hey thanks for taking the time to watch the video! If you're more of a reader I also have a full written article of the video here: help.nintu.io/article/1-how-to-configure-winden-to-work-with-nintu-and-bricks-builder If you're looking to better understand how you can use tailwind to create global components, templates and styles that can be all managed and edited from one place feel free to checkout this video where I cover how to setup things for scale: th-cam.com/video/Z2vJMGePxQI/w-d-xo.html
Thank you for the wonderful video. I am very interested in using Tailwind CSS, but am concerned that it would be styling essentially at the ID level for WordPress. What I mean is, if I create a section (for example) that I want to reuse, I don't want to have to copy and paste utility classes over and lose scalability. To use Tailwind efficiently in WordPress do I need to essentially style at the ID level with utility classes, or can I do everything with BEM and Tailwind CSS variables (the ideal for me)? Thanks!
You never use IDs in styling. Classes only. With WordPress you can use ACF and create blocks or components like that, especially with Sage Roots and use Blade. Otherwise, if you're doing normal WP dev, putting TW variables into classes is the way to go.
Hey Alex, thanks for the video. I got a lot of new insights into the benefits of tailwind and will certainly look into it in more detail so thank you for that 👍. I fall into one of your categories and create a mix of basic utilities and classes. I do not use a framework at the moment but I am considering one and currently leaning towards bricksprops but still early on in my investigative journey to see if it's worthwhile investing in a framework...not the cost but the learning side of it and going all in which I normally do with these things and find myself in the position you mentioned in the video quite poetically about learning 'new shit' haha. But a couple of points you mentioned I believe were potentially a little misleading or at least over-egged. One being that a website would be faster using tailwind compared to another framework or more so someone who doesn't it like myself via custom classes and utilities. I certainly get the backend performance benefits and there is a real time saving benefit from the JIT delivery, but the frontend performance would be minimal, especially with the advancements in CSS delivery optimisation nowadays. The second point that came to mind was the section classes example you gave...stn-none, stn-some, stn-alot etc, but you have this with tailwind too? Stn spacing 1, spacing 2 etc, so again not sure of the benefit there over an unstructured class (albeit structured to me)? I do see real value you mention in the naming convention and standardisation especially in teams, the longevity, and agnostic adoption tailwind has however. I did read on one of your earlier videos (possibly your intro video) about costs and also possible LTD are these still in the consideration stage? I look forward to learning more and watching more of your videos. Keep up the good work and wish you good luck with nintu 👍
Thanks Michael! Great feedback and a bit to unpack. I'll come back with a proper reply later this week. Just a little under the pump this week with the launch :) Really appreciate you taking the time to watch the video
Hey Matea thanks for stopping by! Yes 100% I will be increasing the collection of templates. On the roadmap i have login pages, 404s, headers, style guides, full UI kits and full website imports. Slowly moving closer to something like shuffle.dev/components where you can filter by UI library and components. Re woocommerce: I'm not sure. I will 100% be doing ecommerce components but woo is quite dated and slow in comparison to some of the newer providers (like surecart). Part of what I want Nintu to represent is consistent quality and speed (most other template providers seem to pride themselves on quantity instead). Continuing along that narrative, I'm not convinced woo will be the best ecommerce provider over the next couple of years. So in short, probably not woo unless they change the way the plugin fundamentally works, but will have ecommerce designs for plugins that run on newer tech and are aligned to the same speed values.
Agreed! Thanks for the feedback Dan. Quite new to the whole youtube content creation game and it didn't immediately cross my mind but will definitely go back and update !
Hey Jak, it was awesome to see you on the stream today!! I've got the complete setup guide here: help.nintu.io/article/1-how-to-configure-winden-to-work-with-nintu-and-bricks-builder You'll also need winden to enable tailwind on wordpress which you can grab from here: go.nintu.io/winden Let me know if you have any questions ;)
I don't really think tailwind was made for pagebuilders like bricks. You really loose a lot of global control by using utility classes for everything. Say, you want to change all the border radiuses of your cards across the whole page at once. You would be out of luck right? You would be mich better of creating a custom css class ".cards" with a custom prop of --card-border-radius which you have global control of. I think Automatic.css offers a much better approach than tailwind (or Winden ) regarding pagebuilders. Especially paired with plaster-plugin. Tailwind only makes sense if you have any kind of templating engine that takes care of deduplicating your styles like in all the major js frameworks imho.
You can do the same thing with winden actually... Just create a global class with @apply and add a border radius utility class like: .cards { @apply rounded-3xl }
You can do global changes via tailwind (we use this for brand colors and fluid type) you could extend it to pretty much anything but I think the better way as you suggested is to use the template system. Brick's template engine is pretty robust and combining it with CPT and taxonomies allows you to template just about anything. But yeah back to the border radius example, you could extend the default "rounded" classes in tailwind, edit what they already have or add your own. In a similar way to how all my templates use a custom color palette that's defined by a user. You only change the colors in one place and they're applied globally. The setup guide goes into it a little deeper: help.nintu.io/article/1-how-to-configure-winden-to-work-with-nintu-and-bricks-builder
Absolutely AWESOME video! I’ve been wondering about tailwind on Bricks since I bought Winden a couple months ago, but haven’t taken the time to investigate. Glad I have it, thanks.
Thanks so much Adam! Mean a lot
Thanks, Alex. This was a very well-presented and information-packed video. I appreciate you taking the time to put it together for us!
My pleasure Lawrence! Thank you for taking the time to watch and leave a comment
Thanks Alex, great video. I have been wanting to know more about Bricks and tailwindcss thanks for saving me time and putting them both in one video. Keep up the excellent work.
Thank you sir! Means a lot!!
Hey Alex, Thanks for the video. I always wanted to add Tailwind to WordPress. But, there wasn't a tool to integrate. I got my hands on Winden last week and I am loving it. Great information on your video.
Thanks Aravinda! Really appreciate you taking the time to watch the video. Feel free to reach out if you have any questions re tailwind, winden or nintu. Always here to give back to this awesome community
Huge help, much appreciated
Thanks Tim!!
I'm an ACSS user. I use ACSS for the framework and for the tutorials on best practices when using CSS. He says to use ACSS classes/ variables, but you're not limited to it. He says to use regular CSS or SASS when needed. I like the BEM naming convention for classes.
I'd like to ask a few questions, if I may, before I buy your product, please?
Is using the BEM naming convention for classes any good, as it wasn't mentioned in your video.
Since we are using multiple classes to build a component using tailwind, i.e. FAQ section. If you have the same component on different pages, do I need to add all the tailwind classes again on every page?
You can use the @apply method to create a BEM like global class to add everywhere :)
Juan is correct although it kinda defeats the purposes of using a utility system if we're then going to create components through CSS.
In my opinion I think the best way to do this is to just create your templates via the bricks template system (as sections) and then load them on your page by using the bricks template element.
Example of this on Nintu, Every FAQ, CTA, post grid and dark mode button is just one template that I edit from one place and is being loaded as a section where I need it.
Thanks for taking the time to reply Juan, I appreciate the help 🙏 ❤️
@@juancamilochaves2179 apply method should not be used like this. Even the developer behind Tailwind regrets implementing it and wishes he never had. The problem is that with WP page builders, the argument of using Tailwind for scalability and maintainability goes out the window. Whether it's apply or theme()
I don't think either of these statements are true. The author wishes people would work within the methodology and some people use the apply function to treat the framework like generic css instead of using the built in tools to streamline. Out of context it sounds like he hates apply, but in reality it's an awesome function that is very well supported and documented, just with great power comes great responsibility.
I've just put together a video on how you can create components, templates and styles globally. The principal is the same with WordPress as it is with any other framework (vue, react), but quite different from what people are used to making it hard for some to adopt. Not everyone is open to change :)
If curious, feel free to take a look here: th-cam.com/video/Z2vJMGePxQI/w-d-xo.html
12:18 I was about to purchase the winden plugin, but while doing a little research I came across a lengthy blog post titled "Using Tailwind with WordPress page builders is a bad idea" written by tje ACSS plugin but quoting numerous conflicting instances of winden's dev himself. Now I am back on the fence about winden. Any thoughts about how valid the points from said blog post are?
Yeah a lot of misinformed content written by an author who is looking to justify his own product.
I had a lengthy conversation about it with someone this week, will post the conversation below. In short: it's easy to diss a solution when you're looking at things from the wrong angle. I'll put together a proper video addressing it in the coming weeks.
In the meantime here's the chat:
______________________________________________
Chatter:
yes have seen your video regarding this, but it doesnt really makes sense to me if you are using page builderss. It would make more sense making global classes.
______________________________________________
Alex:
can you shoot over a couple of examples / use cases where you think it's a bad idea and ill send back how i tackled it. I think there are pros and cons to each but for me the pros far outweigh everything else. There was also quite a lot i had to learn the hard way when building Nintu, and had to go back and rebuild parts more times than I would have liked. with the lessons learnt im pretty confident in the scalability of everything and managing templates or parts that are reused is done consistently.
but yeah, shoot over some use cases for which it doesn't make sense and I'll explain.
the article above is isn't great, there's not much understanding of how to properly use tailwind. That "give a guy a hammer and everything looks like a nail" quote comes to mind. The examples aren't great and the way you would handle the problems outlined in the article are not what he presented as solutions. its like looking for the worst way to solve a problem with tailwind.
____________________________________________
Chatter:
"""Tailwind is a popular "utility-first" CSS framework that bills itself as "an API for your design system." But, as you'll learn in this article, it's a bad idea to use Tailwind - or any utility-first framework - with WordPress page builders.
Note #1: I'm not going to use this article argue whether Tailwind is a good or bad framework. That's a separate discussion that would require its own article.
Note #2: I'm not going to go in depth on all the issues with Tailwind. I'm only going to argue why it's bad choice for page builders. So, if you think this article is long and detailed, remember that it's only the tip of the iceberg when it comes to potential issues with using Tailwind.
Note #3: The facts I'll outline here won't stop a lot of people from insisting that Tailwind is a great fit for WordPress page builders. I'm sure these people mean well, but they're wrong. And they're not only wrong according to me, they're wrong according to the creator of Tailwind.
Note #4: Many people will dismiss this article by saying, "Kevin is arguing against Tailwind because it's in the best interest of selling more copies of Automatic.css." That's nonsense, of course, because I always say/teach whatever is in the best interest of my audience (which goes far beyond the ACSS world). In any case, that's why this article uses the words of Tailwind's creator to make my case. It helps keep this article as objective as possible.
Cool? Let's get started!
What is Tailwind?
Tailwind CSS is a utility-first CSS framework for rapidly building custom user interfaces. It is a highly customizable, low-level CSS framework that gives you all of the building blocks you need to build bespoke designs without any annoying opinionated styles you have to fight to override.
GeeksforGeeks
That's a good marketing description, but there's a lot more to Tailwind than that.
In reality, Tailwind is better described exactly as they describe it on the Tailwind site: "An API for your design system."
It's a MASSIVE framework with a STEEP learning curve. You can browse the Tailwind documentation to get a pretty quick understanding of how massive and technical this framework is.
Also: I'd guess that most people who advocate for using Tailwind with WordPress really only know/understand the base level of Tailwind and aren't really using it anywhere close to its full extent.
Most important of all, Tailwind wasn't designed for WordPress page builders or with WordPress page builders in mind. This fact introduces a fundamental problem...
The fundamental problem: using Tailwind with WordPress page builders isn't scalable or maintainable
When you're building sites, it's important to think about the future of the site. While you're likely working from a specific design in the beginning, that doesn't mean your design will never change. And it doesn't mean you'll never make a design mistake that then needs fixing across many blocks.
Knowing this, good developers put a lot of time, thought, and attention into building sites that are easy to adjust, iterate, and maintain.
When I talk about scalability, that's what I'm referring to. How easy is it to change things? How easy is it to add new things with identical styling? How easy is it to maintain consistency? How easy is it to work with teams?
Tailwind *might* be a great option for front end frameworks like Vue, Angular, React, etc. because you can maintain scalability in these environments. But when it comes to WordPress page builders, it's a fail.
Want specifics? No problem.
An inherent problem with the utility-first philosophy
Tailwind is a "utility-first" framework.
When a framework is "utility-first" it means that you're supposed to use utility classes for everything. You're not creating custom classes and you're not writing any CSS. That's the goal anyway.
Why? Because "coming up with names for custom classes is hard" ... or something (Yes, there's a little more to it, but not much). So people got the idea to use utility classes exclusively.
This breaches the very definition of "utility," but whatever, we have bigger fish to fry.
Right off the bat you might notice an issue with the utility-first philosophy. If you don't assign custom classes to things, how do you retain global control of element styling? How can you create one "source of truth" for specific re-usable blocks?
For example, let's say you create product card with an image, heading, description, price, and a few other elements. It could take two dozen or more Tailwind utility classes to create a single card.
Now, you duplicate that card 8 more times to create a product grid. And you use that same grid on 5 other pages of your site. What do you do when the card design needs to change?
You sure as Hell don't want to go page by page, block by block, element by element removing utility classes and adding new ones. That'll make you want to jump off a bridge.
There's gotta be a way to retain global control, right?
// PAUSE.
Let's pause for a moment to point out the fact that this is ONLY a problem with utility-first frameworks. If you use CSS the way CSS is intended, there's no problem here. You create custom classes and then you have automatic global control over your elements using those custom classes. Change styling in one place and it changes everywhere you've used that element. Simple!
So, by introducing Tailwind and the "utility-first" philosophy, we're introducing a huge problem that we then need to solve."""
_________________________________________________________
Alex:
Awesome!
So.. To me there are two parts to this:
1: the mindset behind it all: this is something I resonate with but isn't for everyone. you're trading complexity in jumping back and forth between a css sheet and the html for simplicity where its all easily identifiable and in one place. This is something that I am happy to trade for because I usually work on quite large projects and it's difficult to keep track of different systems on different projects and keep it all clean. it also means that i can have multiple styles on a single project without having a massive css file. (in our case, lots of templates with lots of different UI styles). but even on real world projects, you would have a different border on different sized elements in line with modern design standards.
2: real world use case: this doesn't actually happen very often. if you're creating a grid of product updates you would have it in a repeater and just style it once. Most things that actually need repeating live as bricks templates.
So if we look at the nintu site as an example: every CTA is the same one inserted as a template, every FAQ is the same template, every category and template page is generated dynamically from a single template etc etc. There are not many "standalone" pages, most are templated and editing is all centralized.
With all that said I did run into the issue kevin presented once. with pricing pages. as they're not templated it was a pain to update. But, of 100+ pages that currently exist on nintu it only happened once.
So he's not fundamentally wrong, just it would be a bad idea to build in the way is presented in the article.
You can also edit all the global values if you wanted to. in our case everything that involves space (margins, paddings, width) is custom and fluid, and we have a custom palette of primary and neutral colors. you can change pretty much any of the styles globally (or add your own that integrate into the framework) but the default ones work quite well in most cases 😉
________
Let me know if that doesn't quite cover it and which areas are confusing, it will really help me to make a good quality explanation :)
@@itsNintu Thank you for the prompt reply. I'll read it right now.
Thanks 😊!!! Feel free to open a live chat session on nintu or here if you have any other questions I'd be more than happy to help ♡
@@itsNintu What irritated me most in said blog post, is that Kevin used Adam's own tweets and arguments to reinforce his claims.
Admittedly, as a layman, I couldn't wrap my head around every problem/solution stance that was illustrated in the blog post. What I understood however is that the problematic use cases put in question by Kevin are more in case of big projects, than for small website owners like myself. This is why I think more how-to video tutorials on using Bricks with Winden and Tailwind will clear a lot of the fog, especially for folks like myself coming from Elementor, and just getting started at this "more control" level (AND a black-friday coupon code for Winden's lifetime deal would also help 😁).
Haha I'll let you know if I hear any news re a black friday promotion.
And yes you're correct, but not just for small projects, projects of all size. The @apply function with tailwind is intended to allow users to edit other people styles that were created outside of tailwind, not to design an entire website. Which is why adam has some hard feeling about it but also a bit of a low blow to diss an entire framework. It's actually a great tool for us in the wordpress space as it allows us to connect other plugins to our design system and keep it all integrated with tailwind.
In a real world scenario, you would build a whole site, small or large with winden/tailwind. And then you add a new plugin that doesn't support custom classes (a form plugin, grid, or something along thones lines). Instead of having to style your new plugin (lets say a form for example), you can just connect the plugins css classes to your tailwind system and bam! All your styles are connected and work together.
I think ultimately there's just a bit of salt from ACSS because their plugin doesnt have a JIT engine to support massive amounts of classes or any way to connect their styles to other peoples work. Unfortunately they chose to bad mouth the product that can do it as a way to justify not being good enough...
Hey thanks for taking the time to watch the video! If you're more of a reader I also have a full written article of the video here: help.nintu.io/article/1-how-to-configure-winden-to-work-with-nintu-and-bricks-builder
If you're looking to better understand how you can use tailwind to create global components, templates and styles that can be all managed and edited from one place feel free to checkout this video where I cover how to setup things for scale: th-cam.com/video/Z2vJMGePxQI/w-d-xo.html
Thank you for the video! What is your personal opinion compared with open props?
Hi Marco! I have not used OP before but looks interesting :) Will look into it this week and let you know ;)
And how have you integrated TW CSS into bricks
I’m new to Wordpress but I am a web developer. I love using Tailwind in my other projects so if I can use it for Wordpress that would be a real win.
Have you tried Oxyprops/Bricksprops, its based on Openprops.
i just got oxyprops, i really love it
Thank you for the wonderful video. I am very interested in using Tailwind CSS, but am concerned that it would be styling essentially at the ID level for WordPress. What I mean is, if I create a section (for example) that I want to reuse, I don't want to have to copy and paste utility classes over and lose scalability. To use Tailwind efficiently in WordPress do I need to essentially style at the ID level with utility classes, or can I do everything with BEM and Tailwind CSS variables (the ideal for me)? Thanks!
You never use IDs in styling. Classes only. With WordPress you can use ACF and create blocks or components like that, especially with Sage Roots and use Blade.
Otherwise, if you're doing normal WP dev, putting TW variables into classes is the way to go.
@@aurelianspodarec2629 Great thanks!
Hey Alex, thanks for the video. I got a lot of new insights into the benefits of tailwind and will certainly look into it in more detail so thank you for that 👍.
I fall into one of your categories and create a mix of basic utilities and classes. I do not use a framework at the moment but I am considering one and currently leaning towards bricksprops but still early on in my investigative journey to see if it's worthwhile investing in a framework...not the cost but the learning side of it and going all in which I normally do with these things and find myself in the position you mentioned in the video quite poetically about learning 'new shit' haha.
But a couple of points you mentioned I believe were potentially a little misleading or at least over-egged. One being that a website would be faster using tailwind compared to another framework or more so someone who doesn't it like myself via custom classes and utilities.
I certainly get the backend performance benefits and there is a real time saving benefit from the JIT delivery, but the frontend performance would be minimal, especially with the advancements in CSS delivery optimisation nowadays. The second point that came to mind was the section classes example you gave...stn-none, stn-some, stn-alot etc, but you have this with tailwind too? Stn spacing 1, spacing 2 etc, so again not sure of the benefit there over an unstructured class (albeit structured to me)?
I do see real value you mention in the naming convention and standardisation especially in teams, the longevity, and agnostic adoption tailwind has however.
I did read on one of your earlier videos (possibly your intro video) about costs and also possible LTD are these still in the consideration stage?
I look forward to learning more and watching more of your videos. Keep up the good work and wish you good luck with nintu 👍
Thanks Michael! Great feedback and a bit to unpack. I'll come back with a proper reply later this week. Just a little under the pump this week with the launch :) Really appreciate you taking the time to watch the video
Are you going to increase the collection of templates? Will you be making a templates for a login page, 404 page, woocommerce, etc.?
Hey Matea thanks for stopping by! Yes 100% I will be increasing the collection of templates. On the roadmap i have login pages, 404s, headers, style guides, full UI kits and full website imports. Slowly moving closer to something like shuffle.dev/components where you can filter by UI library and components.
Re woocommerce: I'm not sure. I will 100% be doing ecommerce components but woo is quite dated and slow in comparison to some of the newer providers (like surecart). Part of what I want Nintu to represent is consistent quality and speed (most other template providers seem to pride themselves on quantity instead). Continuing along that narrative, I'm not convinced woo will be the best ecommerce provider over the next couple of years.
So in short, probably not woo unless they change the way the plugin fundamentally works, but will have ecommerce designs for plugins that run on newer tech and are aligned to the same speed values.
You should insert the links to the tools you describe in the contents area.
Agreed! Thanks for the feedback Dan. Quite new to the whole youtube content creation game and it didn't immediately cross my mind but will definitely go back and update !
how to install?
Hey Jak, it was awesome to see you on the stream today!!
I've got the complete setup guide here: help.nintu.io/article/1-how-to-configure-winden-to-work-with-nintu-and-bricks-builder
You'll also need winden to enable tailwind on wordpress which you can grab from here: go.nintu.io/winden
Let me know if you have any questions ;)
I don't really think tailwind was made for pagebuilders like bricks.
You really loose a lot of global control by using utility classes for everything.
Say, you want to change all the border radiuses of your cards across the whole page at once. You would be out of luck right?
You would be mich better of creating a custom css class ".cards" with a custom prop of --card-border-radius which you have global control of.
I think Automatic.css offers a much better approach than tailwind (or Winden ) regarding pagebuilders. Especially paired with plaster-plugin.
Tailwind only makes sense if you have any kind of templating engine that takes care of deduplicating your styles like in all the major js frameworks imho.
You can do the same thing with winden actually...
Just create a global class with @apply and add a border radius utility class like:
.cards {
@apply rounded-3xl
}
You can do global changes via tailwind (we use this for brand colors and fluid type) you could extend it to pretty much anything but I think the better way as you suggested is to use the template system. Brick's template engine is pretty robust and combining it with CPT and taxonomies allows you to template just about anything.
But yeah back to the border radius example, you could extend the default "rounded" classes in tailwind, edit what they already have or add your own. In a similar way to how all my templates use a custom color palette that's defined by a user. You only change the colors in one place and they're applied globally.
The setup guide goes into it a little deeper: help.nintu.io/article/1-how-to-configure-winden-to-work-with-nintu-and-bricks-builder