Yeah, very funny. However I would argue that with where IDEs are going and with AI like Copilot, I don't actually type all these extra characters he is complaining about; I'd argue that its actually quicker to write my CSS this way with the aid of tools like Copilot than the tailwind classes. I think again this depends on the type of project you are working in, how often you're changing the styles etc.
what is even going on? Panda vs TW? Isn't Panda more like Styled Components, emotion, radium, ? Also this totally removes why TW is used... TW is used for one reason, Not having to write CSS syntax but Classes directly. Panda seems to be 90% syntax based.
Most of the css I've written, was set it and forget it. But if and when I need to conditionally switch out classes. I'd use a scoped .module.css file and use those classes or update a CSS variable. Tailwind plays nicely with this
I have rarely needed to switch out classes based on state. CSS is immensely powerful for defining styling for multiple combinations of state, especially additively. I almost always resort to put my state in either ARIA, or if they don't fit, I use data attributes. Then apply the styles I need using attribute selectors. This also works well with tailwind's `group` class for conditionally styling children based on parent state, without them having to pass that state everywhere just for styling purposes. This way also gives you the ability to align the UX with accessibility very easily. For example, if you have a nav with nav items and want to represent the current selected item/page, you can add the state on aria-current, and then style them with [aria-current=true] selector.
Thank you for presenting with your views on panda. I love the flexibility it provides and it really shines when you build/use design systems. + Somehow i like my styles in jsx 😂
I HATE Tailwind because I have to put everything on the same line. It's much more readable and maintainable to use the object syntax. "But I have to press enter" boo hoo. You won't break your fingers mate.
It makes decision-making harder and parsing code harder. I like not having too much flexibility. I like being restricted, it usually makes me faster to program.
That’s what people likes about Go, no class level visibility modifier, no sealed class, no default implementation in interfaces, no inheritance, no a lot of things, which makes development in Go straight forward
To expand on what you speak about at 15:56, you can get dynamic class names to work with tailwindcss with the use of safeList in the tailwind config file. You can define patterns for class names that you want to ensure are included by the tailwind compiler, allowing you to dynamically create the className string as you did return `bg-red-${num}`. Disclaimer: This will add some overhead as classes that are potentially never used will still be there, not here to argue for or against it. You probably want to use it sparingly, if at all. To do it, you can add something like the following to the tailwind.config.js file: safeList: [ pattern: /^(bg-(?red|slate|zinc|stone)-(?:400|500|600)) ]
I agree with this. I have used it to generate all my utility classes, and I have a small config file that generates color classes for the theme, and that’s it. The power it gives you with for loops and mixins and whatnot make it incredibly easy to automate all the repetitive things. Still, tailwind is nice because it’s so popular that everyone will know the class names, but if you can’t use tailwind at work like me and you only have css or sass then sass it is. I essentially ended up making my own little version of tailwind.
Second this. Sass is basically the typescript for css. All its features will eventually make it into the core spec. All css frameworks are marked for depreciation for me from the get-go. We're basically on the cusp of another bootstrap age, where everything looks the same....once again some more. Cause lets face it websites already do, save for the color scheme and some graphics used.
@@Sindoku yeah I think that's the right approach. Where I work we are slowly switching to Tailwind for projects, but have used SASS for last few years and (S)CSS Modules just so that we get scoped classes so that we have to think less about naming things. We stuck close to vanilla CSS and that worked great for us. css in js libraries appeared and died and are now frowned upon, but that didn't impact us and projects we have worked on because we didn't use any of those. There are couple of downsides to doing this utility approach with sass for example if you have to generate all utility classes for each breakpoint you end up with an enormous CSS file in the end, but overall it's a good experience. I like the fact that valid CSS is valid in SASS. It doesn't reinvent CSS syntax, but rather adds some superpowers to it. This is why I like Tailwind. It's all CSS classes in the end and I do like the fact that Tailwind generates only classes that you use so CSS file size doesn't increase like crazy.
Panda offers ways to config !== you need to use all the config. So, you can start easy and keep it easy until when you do need those config stuff. It's like React and Next.js have quite some built-in features, but that does not mean you have to use all of them in your project when you don't need to.
Never got to deal with Tailwind although I'm super down for it and would love to try at work (I honestly have a hunch it would benefit our team a lot) However, I usually make some CSS/SCSS magic involving somewhat (not very much) complex selectors. Can Tailwind do that? Messing up with states, siblings, children, :has, :not, :is, pseudo-elements, custom properties etc. Is there an awesome reference the community usually points to of Tailwind best practices and patterns (especially for somewhat already large products that are scaling fast)? I understand there is a mental shift to go through in order to use it well, however I would love shortcuts into just "getting it" when I eventually hit a wall.
There aren't complex selectors in tailwind, no. The idea is that if you are using tailwind there is no need for complex selectors because there is no label that :has an input inside of it, instead there is just a label with extra classes. But even if you need complex selectors, tailwind is just an addon, you can always just write a custom class and custom selectors and just run them beside tailwind, you can also just add tailwind to existing projects and only use it starting from then and refactor old code as you go along
It's weird that you like StyleX but not this when it comes to writing the object, since they are basically the same hehe Anyways, tailwind approach is better
Good point, they're the same. But only because of the merging style issue of Tailwind, I think Panda is a winner here, like having different behaviour based on the order of the class is awful, and possibly hard to debug.
That's because he hate Chakra UI team. Because for some reason the creator of TW hates deeply Chakra without a reason, saying things like the Chakra team copy some text of the TW docs. WDF, are TW not a Open Source proyect?
Do you have a video talking about performance improvements for tailwind classes? You mention a few items such as consistent class order. I would love to learn more.
I don't think consistent class order has any impact on performance. It's more for predictability and readability. But 'performance' encapsulates many topics so maybe you're thinking of something different than me.
A 500 char line of Tailwind classnames is so so so much less readable than a Panda CSS object. But the powerful features of Panda are in the more complex applications and design system bundling etc
@@fungilationMy point here is that Theo went into this very biased and completely missed the point of Panda and went on a tangent about various non-core features
@syedmohammadsannan964 Not at all. An example would be writing focus and hover states which often takes an absolute shit ton of Tailwind classes. When I worked with Panda I created a custom "hocus" condition for hover and focus style combined. Custom styling conditions coupled with layer styles made the Panda styling way simpler than in Tailwind
The only reason why im not completely against this is only because it does output the styling to tailwindcss-like classes. I could see this being useful (eventhough its more typing) for people who haven't used tailwindcss before (since this markup seems a little more verbose).
No, those strings are to create new Components. You're not assign it to Components, your creating Components with styles. But that's a advanced use case that usually nobody should use. But they want to give you the ability to do it.
I cannot agree more with the "typing more characters" of the CSS-in-JS object syntax with nested keys, rather than a string of class, particularly when it comes to prototyping/iterating on designs in the browser, and speed/creativity is key. Matter of fact this is the subject of my upcoming talk for Epic Web Conf in April - "Unleashing Designers with Tailwind". Agree with you, the article by Baptiste was pretty great!
Before really getting into Tailwind I thought I would like the "Attributify" pattern, but I've slowly - despite not using it - started liking the concept less and less.
When you're applying the recipe, there's a way of adding it directly to the className without using the styled approach. I just can't remember off the top of my head as I'm on my phone.
I was the worst at CSS before Tailwind. I used to get so frustrated that I didn't wanna build any websites after writing a few lines of CSS. Then, I found Tailwind CSS and never looked back. Now, I absolutely love building UI and components using it. Tailwind made me so good at building UI that I can now easily pull off truly pixel-perfect UI. Matter of fact, I'm the one who is responsible for building truly pixel-perfect UI in the team.
The problem that happens at 19:19 should be fixed by implementing a "variant" pattern. You have: "primary", "secondary". If variant === "primary", then apply py-1. if variant === "secondary", then apply py-4. Only allow concatenating when you have no overlapping classes.
It's common to allow passing className from parent components. It allows for those components to be reused without having to define and update the component API with a ton of props just for styling purposes.
i will forever disagree with theos opinion on whats easier to write/edit. The "atrributify" style is miles easier to parse and modify and not reliant on some external plugin that rewrites your taillwind classes to follow a particular order.
It makes everything harder to start and learn. The only difficult part from tailwind is getting it to “work” with your project and learning the styles but once you know the pattern is pretty much there. And tailwind merge is easier to read and make it work
I’ve used Chakra extensively in a previous job, so it’s nice to see what they are up to since it seems work on Chakra has been on hold for some time. I think Chakra and by extension Panda (which basically the primitives in chakra) are frustrating at first until you get comfortable with the work flow. Once you know it fluently, you have unlimited capabilities. There isn’t anything it can’t do. I don’t know why you have a problem with Chakra being a component library when you basically copy pasted Tailwind UI components for Upload Thing. While Chakra may be “componenty”, it still allows maximum flexibility on a level that no other library allows. You can control every aspect of how it looks and feels. It might not be the easiest process in the world, but doing everything it does will likely never be so easy, unless AI gets extremely smart all of a sudden.
If I want to have flexibility, I may choose shadcn-ui. If I need a component library that works out of the box, I will choose mantine. I've used chakra in several projects, and it's fine, but I don't seem to have a reason to use it anymore.
I've actually come across a few cases where I couldn't control certain parts of a chakra component via the API they provided. Other than that, it as a nice experience overall
"Tailwind makes CSS just get out of your way"... I guess that explains why I don't use it, I actually enjoy CSS, especially if I get to construct it from SCSS source files. (:
CSS vars is the problem there. You don't have s way of having safe CSS vars. And also you could ended in huge bundle size. Btw, I'm a fan too, i use SASS modules at work, so i learn all their limits there.
@@oscarljimenez5717 That's just an editor problem. CSS vars can be statically analysed. In fact, I believe it's even built in to VSCode Intellisense if I am not wrong. As for your bundle size point. Yes this is a huge part of why things like Stitches, StyleX and Tailwind exists, and why prior art of "utility css" were conceived. Meta should know, they did a ton of work to minimize the amount of CSS they shipped on Instagram and Facebook, even prior to StyleX. That, and naming things sucks.
@@dealloc that's not a editor problem only, because you could have CSS variables that you received from your Node Modules, PandaCSS fix that. Everything is Typesafe, you can go many repos, proyects and packages.
@@oscarljimenez5717 As long as your CSS is imported _somewhere_, doesn't matter if from HTML (link/style), CSS (@import) or JS modules (import), it is technically possible to statically analyse any variables and different scopes. node modules are stored in your file system, so that's not a problem.
@@dealloc yeah, but that's not simple as you think. You could have some vars that you wanna import and some you don't. Usually TS, ESLint, etc, will ignore node_modules because can be super slow. So i understand your point, but is not so easy.
larg codebases: tailwind classes: 80% of your markup characters are going to be this single character soup. add in responsive rules and its N+1 pandacss: typesafe, design system constraints, build type css. i've used tailwind on a large project. it's unmaintainable. you guys must be making throw away embeded adverts.
What is actually unmaintainable about Tailwind on large projects? You still use components and work with them, it's not like you copy paste all those classes around each time you use an element? You create a component and you use it, what does Tailwind actually make worse about that? And btw, any project is unmaintainable if developers are messy. I unfortunately had the "pleasure" to work in a styled-components codebase that had type safety with Typescript and well defined design tokens and it sucked. It was the worst experience I had writing CSS ever. I would pick Tailwind over that any day of the week. Hell, I would pick working in fully vanilla CSS over that experience any day of the week.
Tailwind is the only technology so far that I just can't imagine being beaten by anything, it's beyond perfect and challenging it feels similar to reinventing the wheel at this point
Tailwind is indeed amazing and I use it for a handful or projects, but it's not suitable for all use cases. We're using Panda CSS for some larger projects where what we need to achieve is more difficult with Tailwind. "reinventing the wheel at this point" - is that not what the Tailwind team have done? They've add classes that apply CSS styles, I seem to recall we could do that around Dec 17th, 1996 when W3C published the first standard for CSS (level 1)!
@@upsxace Well some of it had to do with CSS variables that has been sort of resolved with version 3. The short answer is that we have a a bunch of UI's all built with a base theme; the UI's are "shared" between multiple clients and those clients have their own "branding", therefore we need to override bit s in the base theme to achieve their look and feel; we do NOT want to have all our themes defined in the same place as base, out client theme overrides are in separate repos being published separated and loaded at runtime. The issues we had were more around overriding CSS variables. It's more of a global vs scoped CSS variable issue, with Panda we can achieve what we need/want very easily, with Tailwind it seems to be a faff and gets into a bit mess. It may be that its possible to achieve what we needed, but we've already moved on and now we have type safety for our styles and clean and clear way for our engineers to build the component styles etc. I love Tailwind and I use it in several other smaller projects, but the short of it is that Tailwind has been perfect for smaller tailored applications, but an absolute nightmare for enterprise applications with many many themes etc.
@@upsxace You know what, given it's been a while since I looked at Tailwind and they have CSS var support in v3...I went back to try it again and found that I can actually achieve what I need to achieve now; for theme overrides (css vars) I used typescript types to define some css variables as a nested structure that I generate the css vars from; there is also a plugin you can use to put variables in under "variables" within the theme of the config too; using the typescript types gives us that type safety around the overrides to ensure that variable names are correct and not mistyped etc. Honestly, dare I say it, we may switch to Tailwind CSS again and abandon Panda CSS; not because there is anything wrong with Panda and it's pretty good, but Tailwind would be a better fit for us based on what we need to do, given that I can now do what we need and couldn't before. 😅
"The amount of typing I have to do is so much worse..." Couldn't the same be said of Typescript vs Javascript? My point being the amount of typing that has to be done is no fair way to compare the benefits that some extra typing on your keyboard can bring.
I always want to use tailwind because it always looks so simple but somehow my brain just gives up when it comes to shorthand stuff so I stick to css 😢
I ran into the JIT problem when I was trying to use a dependently typed language to generate static types based on a tailwind config file at compile time. I.E. your component takes an enum type ike ("red" | "green" | "blue") as a parameter to determine its color, but that enum is generated through a dependent function like (generateTailwindTypes: (tailwindConfigPath: string) -> Type). the dependent function worked great, but the styles weren't picked up by the compiler because they were generated on the fly
I just don't see the appeal of Tailwind or derivative projects. CSS Modules resolved all the same pain points with CSS since almost a decade ago. Do we seriously need all these libraries with non-standard syntax and configurations and unreadable git diffs and mandatory IDE plugins just so we don't have to switch tabs and type ".item {}" sometimes?
I think it's about convenience. I used CSS Modules for last 4-5 years I think and started using Tailwind about 6 months ago and would never want to go back to CSS Modules. The fact that I can just write classes and not worry about creating, importing and using extra files is nice. It's especially nice in those cases where you just have to add some margin/padding to a single element or just do some flex stuff to center it maybe. So instead of creating a css module file, creating a class and then importing and using it for that potentially one off thing, I can just write few classes and be done with it. And you can also have all those classes triggered on certain breakpoints if you need. One other benefit is that if someone joins a project and they used Tailwind, they don't have to decypher your custom styles, they can just use Tailwind. Regarding css in js in general, I think that's horrible and think that was a mistake really for the most part lol
That was my thought too 😢 I think it works that way, because say for example you were to remove a class, and re-add it to an element, it shouldn't change how it looks based on where it is in the class list, like based in terms of `Element.classList.remove()` followed by `Element.classList.add()`
I saw the video thumbnail, then decided to look into the Panda docs, and quickly ended with the same conclusions like you. I think it's too complex and full of options to ensure a maintainable codebase. Right now, I have 3 styling solutions that I like for different reasons: - Tailwind (although I don't use it, I see why it's so popular) - StyleX (haven't used it as well, but it seems really great for authoring a shared component library for bigger projects) - Plain old CSS modules (so simple, perfectly solve the biggest pain points of CSS which is missing colocation and class name clashes, keeps all CSS features, and does nothing more)
CSS is more complex than Panda CSS then. Because you have a thousand ways to declare CSS and in different fashions (BEM? OOCSS? Neither?) so if complexity was the argument against Panda CSS, I don't understand your point. CSS modules only solves one problem, which is scoped styles. But the tools you mentioned avoids that too.
@@dealloc if you have scoped CSS, you don't need any naming convention like BEM or OOCSS anymore. That's the one major problem solved. The rest are well-documented CSS standards. So I think plain CSS, especially with CSS Modules, is way simpler and easier to get.
@@VeitLehmann You still need to name every class for every element that needs some styling, whether it's necessary or not. The problem of duplication is still prevalent, since they are scoped and makes it impossible to merge identical classes between scopes. CSS Modules is easy when you're working on single projects, but as you grow to multiple codebases it becomes increasingly harder to scale. I'm not against CSS Modules. But this is based on my personal experience, working on codebases across multiple projects. It grows exponentially, compared to solutions like Tailwind and StyleX, which grows linearly.
Your team will get used to it. When you use tailwind, you get better at reading tailwind. I'm tired of this excuse that working on teams somehow justifies unnecessary verbosity.
CSS-in-JS solutions, build time or run-time, are not alternatives to Tailwind! Look, 70% of my work is In React but the rest of it is in Laravel, Rails, WordPress, plain ol' HTML, Tailwind works perfectly well with those. This will not.
Bet you might like Typewind 🤷♂ It literally compiles down to Tailwind strings but is safely typed with TypeScript that is generated based on your tailwind.config.js file.
I see this in the frontend world. Developers that are more concerned with presentational aspects don't make really like really really strong tools in the technical aspects, things like type safety, nice abstractions, great performance and so on. But javascript makes it easy to build so we get tons of these free tools. Which I agree is nice and not to be taken for granted. I just think we rely too much on Javascript when instead we should be relying more on preprocessing tools and compilers with strong static analysis... Which is another huge pain to do for JS because of how dynamic and loosy goosy it is with types.
Uh... every JS tool we use today are exactly relying on preprocessing since the very early days of JS. Babel, bundlers, TypeScript, CSS Modules, Tailwind, ESLint, lingui... I could go on. What tools are you referring to that people rely on too much that doesn't do any form of preprocessing?
@@dealloc I am trying to outline the issue with JS that are failed to be fixed with most preprocessor. It feels like the loopholes are just being replaced. ReScript is probably the only language that aims to really fix JS.
At the end of the day it's a matter of taste. I can see how one might argue it's more readable and worth it. I can see how one might argue the opposite.
@@adamjones7497 you don't need it, the same way you don't need type safe anything except code for super critical infrastructure maybe. Type safety in CSS is more about peace of mind and ease of work. I don't like these css in js libraries at all, but having type safety when working with design tokens is pretty nice really.
@@rand0mtv660 adding a layer of complexity to solve for a problem that doesn’t necessarily exist doesn’t give me peace of mind. - In terms of CSS specifically why not add audits in CI/CD instead of adding complexity to the implementation?
@@adamjones7497 what audits would you add? Why push that feedback that something is wrong into CI if developers can get it immediately inside their code editor? Don't get me wrong, I dislike css in js solutions in general, but I cannot deny getting that autocomplete inside the editor and type safety is a nice perk while working with them. It's not something you really "need", but it's a nice feature.
Reusable component styles, aka "makeStyles" and "useStyles" is a plague. We have a project like this, with a styles modules that is more confusing than a simple CSS file because some styles are functions receiving properties to create conditional rules; different properties for different styles... all "any", of course. If not using TailwindCSS, my best choice is SASS, loading .module.scss files with clsx for conditional styles STRAIGHT from the component.
Wait you never got to my favourite part of Panda (well and chakraui), jsx component where instead of pattenrs like css() or className, you just pass styles as attributes. e.g. ...
Panda is more of a low lever library. It's amazing, but unless you are building your own component libraries, the best DX comes once you start using one of the ready-made component libraries based on Panda. Like Ark-ui or park-ui
@@andrewk2756 Still not the same. Ark and park-ui auto generates all the possible components for you so you don't need to do any of this. I just run 3 commands on a new project and have a full component library with any possible building blocks and common elements (Button, Input, Select, Tabs, Link, Heading, Flex, Hstack, Vstack, Grid, etc, etc)
@@YuriPetusko Well I was replying to your original comment about attributes and that's exactly on the timestamp. You said it yourself Ark and Park UI do this stuff so it's not really a Panda's thing? I'm curious to check it btw now that you mentioned.
@@andrewk2756 Panda is a low level and framework agnostic. Where it shines the most is the component library built on top of it. Ark is the official one by Panda team, if you try it, make sure to try JSX components, it's much more pleasant to work with them and style them with attributes rather than classes (when it's compiled, panda turns them into atomic classes anyway). Park-ui is extra layer on top of Ark that adds opinionated pre-themed component for any use case like forms, sliders, tabs, containers, buttons etc. they have a cli command in getting started docs that will just generate all of them and put them in your folder for easy importing
Oof. Amateur hour. Finger nails on a chalkboard. After watching this video for 4 minutes, (at which point I had to hit pause and write this) I can emphatically state you should not listen to Theo for advice on CSS/Frontend best practices / libraries. He even admits he's "plateaud learning CSS". And yet, goes on prognosticating, advocating for this and that? His built example is literally a visual rip off of the Tailwind site, and it's literally 50 lines of CSS? Why even use a framework.. These are red flags! After watching this video for 4 minutes I can emphatically state you should not listen to Theo for advice on CSS/Frontend best practices / libraries. Why? He's not dumb. But he's making this video because... he's an influencer. Gotta pump out that content! He even admits he's "plateaud learning CSS". And yet, goes on prognosticating, advocating for this and that? His built example is literally a visual rip off of the Tailwind site. These are red flags! He makes attempt to weigh our outline the advantages/disadvantages in his bulleted expose. Sure, Tailwind is hypothetically performant. Is your CSS BUNDLE SIZE actually an performance problem for your SPA? If not, then it's not a value add. He offers zero caveats or "maybe this is a good fit for this size project, and maybe this is NOT a good fit for other projects". People, that's baseline when considering tooling! When you don't give that kind of nuance, you're being dogmatic. And frankly, that's a hallmark of bad dev advice. If you can't even summarize the ways and contexts in which Tailwind is a good choice (and there are good situations to use it), why would you want to hear him rough shot over Panda CSS.
I hate tailwind. Editing styles in the markup is a defect, not a feature. It's an excellent way to make HTML unreadable. Add the requirement of a compiler and ide plug-ins to be productive - this is something for people who don't feel comfortable in CSS.
@@yojou3695 only if your css is a mess. I've been writing frontend websites and applications for 18 years, web apps since before backbone js. The closest thing to building an application was concatenating your js files. I've built many many frontends, using everything from Prototype to jQuery to Dojo to Backbone to Ampersand to Angular to Vue, to React. I've done CSS at least a dozen different ways. I've used scss, less, stylus, and even straight css to create ui kits whichwere used by my colleagues in our products. Then came js component frameworks, so I focused on component libraries - first with each component having a css file, then with styled components, and believe it or not, even using tailwind - a terrible decision we renagged on 6 month later because it make our code look like shit and difficult to read. All of this on projects with customers, not toy projects. I'm not convinced by your, or anyone else's argument on this because my experience says otherwise 1000x over.
I'm very comfortable with css and used to hold a similar view. I was wrong. Tailwind is great. Even the simple fact of not having to stress about BEM is a *massive* win for me
The no arbitrary value eslint rule falls down at a few hundred files. It was the slowest lint plugin by far, too slow for even locally let alone ci which made it unusable.
Every time I see these kinds of videos I end up thinking... These web guys really really like to complicate so much.... Everything is SO complicated when HTML + CSS + JS (with DOM) is already SOOO high level... I've always done CSS from scratch and I have a history of fighting vs other coders who like using frameworks and all sorts of stuff but I nearly always end up finishing first or near-first while doing most HTML+CSS+JS work from scratch. It's true I use libraries and I use writing accelerators but I usually end up winning. What I do loads fast, produces WAY smaller content and changing pages is pretty much near-instanteneous from how fast everything is just layed out. So when I see all of these tools... Is it really helping in the end? Or is it just 70% helping and then 30% fighting against it?
I feel the same way but I’m trying to make myself think ”maybe I’m just stuck in an old mindset”. Kinsa arbitrary we often care about serverside validation and safefty…but when it comes to html templates or css - we don’t care. Even though a css flex mistake could make the site unreadable when new ideas come along to suggest improved validation I feel like saying ”I’ve built sites for 15 years and never needed it” But it feels like old assembly pros saying ”written asm for 15 years and never needed a high level language” 😅 or ”never needed eslint” Most things are initially not strictly NEEDED but sometimes over time provide a small value
tailwind is the most abstract css can get as of now, any other solution now feels like more keywords to type. Also I never liked mixing JS/TS with css.
One thing just puzzles me: why all the problems that are written about or discussed in such movies, all these issues that strange libraries try to solve, have never (at least since 2005) been a problem I had to specifically address? It seems to me that these problems are made up, and the libraries only aim to promote their authors.
EDIT: NEvermind you already mentioned it. I know this is heresy or something, but there's an ESLint plugin for TailwindCSS which points out "invalid" classes. Also since we already get auto-complete for TW classes with a VSCode plugin, I think these 2 features go a long way towards "type-safe" TW. I don't mind this solution in most projects.
Oh look it's exactly styled components right down to having css`` and shitty default mode that makes you have an individual style object for each element on the screen. Except it smartly maps stuff to classes.
No, you only use what you need. They give you all posible solution for different teams and problems. But you should always use the basic instead of learning all. For example, with the CSS prop and CVA you could do 99% of cases.
Thanks for reviewing my article, Theo 🙏
I made a video response because Panda is actually great: ruclips.net/video/55DUCqUS4qM/видео.html
“And pressing comma, and pressing enter, and pressing space…”
So you prefer React to Svelte becaaaaause?
🤑
Thems fightin’ words.
And I’m here for it.🍿
...fair
Exactly. This is the main reason I prefer svelte to React. Wasting my time writing extra functions and return statements with curly braces etc
There's a TypeScript library for CSS. That's insane.
Actually, there's hundreds of TypeScript libraries for CSS. Most of them are insane.
React has built in types for css attributes, it’s nothing new
Yeah! I hate it when my compiler catches typos.
4:53 Panda kicked Theo in the balls Lmfao.
🤣🤣
Yeah, very funny. However I would argue that with where IDEs are going and with AI like Copilot, I don't actually type all these extra characters he is complaining about; I'd argue that its actually quicker to write my CSS this way with the aid of tools like Copilot than the tailwind classes. I think again this depends on the type of project you are working in, how often you're changing the styles etc.
Days without yet another js/css library: 0
what is even going on? Panda vs TW? Isn't Panda more like Styled Components, emotion, radium, ?
Also this totally removes why TW is used... TW is used for one reason, Not having to write CSS syntax but Classes directly. Panda seems to be 90% syntax based.
All I want isTailwind with first party solution to merging: twMerge built in
This would be a great addition to already great solution.
Most of the css I've written, was set it and forget it. But if and when I need to conditionally switch out classes. I'd use a scoped .module.css file and use those classes or update a CSS variable. Tailwind plays nicely with this
I have rarely needed to switch out classes based on state. CSS is immensely powerful for defining styling for multiple combinations of state, especially additively. I almost always resort to put my state in either ARIA, or if they don't fit, I use data attributes. Then apply the styles I need using attribute selectors. This also works well with tailwind's `group` class for conditionally styling children based on parent state, without them having to pass that state everywhere just for styling purposes.
This way also gives you the ability to align the UX with accessibility very easily. For example, if you have a nav with nav items and want to represent the current selected item/page, you can add the state on aria-current, and then style them with [aria-current=true] selector.
Thank you for presenting with your views on panda. I love the flexibility it provides and it really shines when you build/use design systems. + Somehow i like my styles in jsx 😂
I HATE Tailwind because I have to put everything on the same line. It's much more readable and maintainable to use the object syntax. "But I have to press enter" boo hoo. You won't break your fingers mate.
Would love to hear Theo's take on Adam Argyles's Open Props 👀
I can't understand how a tool being too flexible is a bad thing
It makes decision-making harder and parsing code harder. I like not having too much flexibility. I like being restricted, it usually makes me faster to program.
That’s what people likes about Go, no class level visibility modifier, no sealed class, no default implementation in interfaces, no inheritance, no a lot of things, which makes development in Go straight forward
react is too flexible, I would just htmx, no reredering no state management not a lot of things which makes development straight forward
@larbi State management is part of any meaningful application.
THEO! You don't have eslint auto sorting your component props on save??
To expand on what you speak about at 15:56, you can get dynamic class names to work with tailwindcss with the use of safeList in the tailwind config file. You can define patterns for class names that you want to ensure are included by the tailwind compiler, allowing you to dynamically create the className string as you did return `bg-red-${num}`.
Disclaimer: This will add some overhead as classes that are potentially never used will still be there, not here to argue for or against it. You probably want to use it sparingly, if at all.
To do it, you can add something like the following to the tailwind.config.js file:
safeList: [
pattern: /^(bg-(?red|slate|zinc|stone)-(?:400|500|600))
]
I’m sticking with sass. It’s all we ever needed ^^
I agree with this. I have used it to generate all my utility classes, and I have a small config file that generates color classes for the theme, and that’s it. The power it gives you with for loops and mixins and whatnot make it incredibly easy to automate all the repetitive things. Still, tailwind is nice because it’s so popular that everyone will know the class names, but if you can’t use tailwind at work like me and you only have css or sass then sass it is. I essentially ended up making my own little version of tailwind.
Second this. Sass is basically the typescript for css. All its features will eventually make it into the core spec. All css frameworks are marked for depreciation for me from the get-go. We're basically on the cusp of another bootstrap age, where everything looks the same....once again some more. Cause lets face it websites already do, save for the color scheme and some graphics used.
@@Sindoku yeah I think that's the right approach. Where I work we are slowly switching to Tailwind for projects, but have used SASS for last few years and (S)CSS Modules just so that we get scoped classes so that we have to think less about naming things. We stuck close to vanilla CSS and that worked great for us. css in js libraries appeared and died and are now frowned upon, but that didn't impact us and projects we have worked on because we didn't use any of those.
There are couple of downsides to doing this utility approach with sass for example if you have to generate all utility classes for each breakpoint you end up with an enormous CSS file in the end, but overall it's a good experience. I like the fact that valid CSS is valid in SASS. It doesn't reinvent CSS syntax, but rather adds some superpowers to it.
This is why I like Tailwind. It's all CSS classes in the end and I do like the fact that Tailwind generates only classes that you use so CSS file size doesn't increase like crazy.
Panda offers ways to config !== you need to use all the config. So, you can start easy and keep it easy until when you do need those config stuff.
It's like React and Next.js have quite some built-in features, but that does not mean you have to use all of them in your project when you don't need to.
Never got to deal with Tailwind although I'm super down for it and would love to try at work (I honestly have a hunch it would benefit our team a lot)
However, I usually make some CSS/SCSS magic involving somewhat (not very much) complex selectors. Can Tailwind do that? Messing up with states, siblings, children, :has, :not, :is, pseudo-elements, custom properties etc.
Is there an awesome reference the community usually points to of Tailwind best practices and patterns (especially for somewhat already large products that are scaling fast)? I understand there is a mental shift to go through in order to use it well, however I would love shortcuts into just "getting it" when I eventually hit a wall.
There aren't complex selectors in tailwind, no. The idea is that if you are using tailwind there is no need for complex selectors because there is no label that :has an input inside of it, instead there is just a label with extra classes.
But even if you need complex selectors, tailwind is just an addon, you can always just write a custom class and custom selectors and just run them beside tailwind, you can also just add tailwind to existing projects and only use it starting from then and refactor old code as you go along
It's weird that you like StyleX but not this when it comes to writing the object, since they are basically the same hehe
Anyways, tailwind approach is better
Good point, they're the same.
But only because of the merging style issue of Tailwind, I think Panda is a winner here, like having different behaviour based on the order of the class is awful, and possibly hard to debug.
That's because he hate Chakra UI team. Because for some reason the creator of TW hates deeply Chakra without a reason, saying things like the Chakra team copy some text of the TW docs.
WDF, are TW not a Open Source proyect?
Do you have a video talking about performance improvements for tailwind classes? You mention a few items such as consistent class order. I would love to learn more.
I don't think consistent class order has any impact on performance. It's more for predictability and readability. But 'performance' encapsulates many topics so maybe you're thinking of something different than me.
A 500 char line of Tailwind classnames is so so so much less readable than a Panda CSS object.
But the powerful features of Panda are in the more complex applications and design system bundling etc
skill issue
and a multiline formatter for tailwind is a better idea than reinventing tw for worse
@syedmohammadsannan964 ...or a developer writing good hover and focus states
@@fungilationMy point here is that Theo went into this very biased and completely missed the point of Panda and went on a tangent about various non-core features
@syedmohammadsannan964 Not at all. An example would be writing focus and hover states which often takes an absolute shit ton of Tailwind classes.
When I worked with Panda I created a custom "hocus" condition for hover and focus style combined. Custom styling conditions coupled with layer styles made the Panda styling way simpler than in Tailwind
Theo is always biased, annoys me. But I generally like the takes here. Tw won, imitating it in worse ways is no go to me
tldr: Tailwind won, every other styling solution lost.
Join and embrace the new cargo cult of Tailwind!
The only reason why im not completely against this is only because it does output the styling to tailwindcss-like classes. I could see this being useful (eventhough its more typing) for people who haven't used tailwindcss before (since this markup seems a little more verbose).
The article is wrong about CVA, you don't have to use styled to consume the cva.
Wouldnt panda's whole type safety be thrown out of the window the moment you have to type components names on a string?
No, those strings are to create new Components. You're not assign it to Components, your creating Components with styles.
But that's a advanced use case that usually nobody should use. But they want to give you the ability to do it.
@@oscarljimenez5717 ooh okay thats interesting, didnt realize that
I cannot agree more with the "typing more characters" of the CSS-in-JS object syntax with nested keys, rather than a string of class, particularly when it comes to prototyping/iterating on designs in the browser, and speed/creativity is key.
Matter of fact this is the subject of my upcoming talk for Epic Web Conf in April - "Unleashing Designers with Tailwind".
Agree with you, the article by Baptiste was pretty great!
if you hate typing characters, why are you a programmer lmao
Bro doesn't know IDE types that for you when you press Ctrl+space or tab.
@@smthngsmthngsmthngdarkside if you love characters, why aren't you a book author?
I think you missed my point@@smthngsmthngsmthngdarkside
28:05 peak theo face
Before really getting into Tailwind I thought I would like the "Attributify" pattern, but I've slowly - despite not using it - started liking the concept less and less.
When you're applying the recipe, there's a way of adding it directly to the className without using the styled approach. I just can't remember off the top of my head as I'm on my phone.
If you want css to get out of the way, tailwind makes sense.
I was the worst at CSS before Tailwind. I used to get so frustrated that I didn't wanna build any websites after writing a few lines of CSS. Then, I found Tailwind CSS and never looked back. Now, I absolutely love building UI and components using it. Tailwind made me so good at building UI that I can now easily pull off truly pixel-perfect UI. Matter of fact, I'm the one who is responsible for building truly pixel-perfect UI in the team.
The problem that happens at 19:19 should be fixed by implementing a "variant" pattern.
You have: "primary", "secondary".
If variant === "primary", then apply py-1.
if variant === "secondary", then apply py-4.
Only allow concatenating when you have no overlapping classes.
It's common to allow passing className from parent components. It allows for those components to be reused without having to define and update the component API with a ton of props just for styling purposes.
@@deallocJust had a case today that I needed to do that. Definitely retracting my comment.
i will forever disagree with theos opinion on whats easier to write/edit. The "atrributify" style is miles easier to parse and modify and not reliant on some external plugin that rewrites your taillwind classes to follow a particular order.
It makes everything harder to start and learn. The only difficult part from tailwind is getting it to “work” with your project and learning the styles but once you know the pattern is pretty much there. And tailwind merge is easier to read and make it work
I’ve used Chakra extensively in a previous job, so it’s nice to see what they are up to since it seems work on Chakra has been on hold for some time. I think Chakra and by extension Panda (which basically the primitives in chakra) are frustrating at first until you get comfortable with the work flow. Once you know it fluently, you have unlimited capabilities. There isn’t anything it can’t do. I don’t know why you have a problem with Chakra being a component library when you basically copy pasted Tailwind UI components for Upload Thing. While Chakra may be “componenty”, it still allows maximum flexibility on a level that no other library allows. You can control every aspect of how it looks and feels. It might not be the easiest process in the world, but doing everything it does will likely never be so easy, unless AI gets extremely smart all of a sudden.
If I want to have flexibility, I may choose shadcn-ui. If I need a component library that works out of the box, I will choose mantine. I've used chakra in several projects, and it's fine, but I don't seem to have a reason to use it anymore.
I've actually come across a few cases where I couldn't control certain parts of a chakra component via the API they provided. Other than that, it as a nice experience overall
"Tailwind makes CSS just get out of your way"... I guess that explains why I don't use it, I actually enjoy CSS, especially if I get to construct it from SCSS source files. (:
Looks like you forgot to add the link to eslint-plugin-tailwindcss in the description shown at 14:37 😇
Good catch, just added! Love y'all 🙏
What the heck with CSS Modules? it seems like a pretty simple tool that allows you to write css much more faster and natively, it's very cool for me
CSS vars is the problem there. You don't have s way of having safe CSS vars. And also you could ended in huge bundle size.
Btw, I'm a fan too, i use SASS modules at work, so i learn all their limits there.
@@oscarljimenez5717 That's just an editor problem. CSS vars can be statically analysed. In fact, I believe it's even built in to VSCode Intellisense if I am not wrong.
As for your bundle size point. Yes this is a huge part of why things like Stitches, StyleX and Tailwind exists, and why prior art of "utility css" were conceived. Meta should know, they did a ton of work to minimize the amount of CSS they shipped on Instagram and Facebook, even prior to StyleX. That, and naming things sucks.
@@dealloc that's not a editor problem only, because you could have CSS variables that you received from your Node Modules, PandaCSS fix that. Everything is Typesafe, you can go many repos, proyects and packages.
@@oscarljimenez5717 As long as your CSS is imported _somewhere_, doesn't matter if from HTML (link/style), CSS (@import) or JS modules (import), it is technically possible to statically analyse any variables and different scopes.
node modules are stored in your file system, so that's not a problem.
@@dealloc yeah, but that's not simple as you think. You could have some vars that you wanna import and some you don't. Usually TS, ESLint, etc, will ignore node_modules because can be super slow. So i understand your point, but is not so easy.
larg codebases:
tailwind classes: 80% of your markup characters are going to be this single character soup. add in responsive rules and its N+1
pandacss: typesafe, design system constraints, build type css.
i've used tailwind on a large project. it's unmaintainable.
you guys must be making throw away embeded adverts.
yeah, the comments really show the audience of theo. mostly indie devs or people in small projects.
What is actually unmaintainable about Tailwind on large projects? You still use components and work with them, it's not like you copy paste all those classes around each time you use an element? You create a component and you use it, what does Tailwind actually make worse about that?
And btw, any project is unmaintainable if developers are messy. I unfortunately had the "pleasure" to work in a styled-components codebase that had type safety with Typescript and well defined design tokens and it sucked. It was the worst experience I had writing CSS ever. I would pick Tailwind over that any day of the week. Hell, I would pick working in fully vanilla CSS over that experience any day of the week.
I'll stick with tailwind, totally agree with the amount of special keys needed in panda. Doesnt look fun to write
Tailwind is the only technology so far that I just can't imagine being beaten by anything, it's beyond perfect and challenging it feels similar to reinventing the wheel at this point
Tailwind is indeed amazing and I use it for a handful or projects, but it's not suitable for all use cases. We're using Panda CSS for some larger projects where what we need to achieve is more difficult with Tailwind. "reinventing the wheel at this point" - is that not what the Tailwind team have done? They've add classes that apply CSS styles, I seem to recall we could do that around Dec 17th, 1996 when W3C published the first standard for CSS (level 1)!
@@Shad0wL00p What can you NOT do with tailwind????? (or its "difficult")
@@upsxace Well some of it had to do with CSS variables that has been sort of resolved with version 3. The short answer is that we have a a bunch of UI's all built with a base theme; the UI's are "shared" between multiple clients and those clients have their own "branding", therefore we need to override bit s in the base theme to achieve their look and feel; we do NOT want to have all our themes defined in the same place as base, out client theme overrides are in separate repos being published separated and loaded at runtime.
The issues we had were more around overriding CSS variables. It's more of a global vs scoped CSS variable issue, with Panda we can achieve what we need/want very easily, with Tailwind it seems to be a faff and gets into a bit mess.
It may be that its possible to achieve what we needed, but we've already moved on and now we have type safety for our styles and clean and clear way for our engineers to build the component styles etc.
I love Tailwind and I use it in several other smaller projects, but the short of it is that Tailwind has been perfect for smaller tailored applications, but an absolute nightmare for enterprise applications with many many themes etc.
@@upsxace You know what, given it's been a while since I looked at Tailwind and they have CSS var support in v3...I went back to try it again and found that I can actually achieve what I need to achieve now; for theme overrides (css vars) I used typescript types to define some css variables as a nested structure that I generate the css vars from; there is also a plugin you can use to put variables in under "variables" within the theme of the config too; using the typescript types gives us that type safety around the overrides to ensure that variable names are correct and not mistyped etc.
Honestly, dare I say it, we may switch to Tailwind CSS again and abandon Panda CSS; not because there is anything wrong with Panda and it's pretty good, but Tailwind would be a better fit for us based on what we need to do, given that I can now do what we need and couldn't before. 😅
"Tailwind keeping your bundle size tiny" - while making your js bundle larger
every time i see something like this, i asked myself if those guy work on real production product
"The amount of typing I have to do is so much worse..." Couldn't the same be said of Typescript vs Javascript? My point being the amount of typing that has to be done is no fair way to compare the benefits that some extra typing on your keyboard can bring.
I always want to use tailwind because it always looks so simple but somehow my brain just gives up when it comes to shorthand stuff so I stick to css 😢
I ran into the JIT problem when I was trying to use a dependently typed language to generate static types based on a tailwind config file at compile time. I.E. your component takes an enum type ike ("red" | "green" | "blue") as a parameter to determine its color, but that enum is generated through a dependent function like (generateTailwindTypes: (tailwindConfigPath: string) -> Type). the dependent function worked great, but the styles weren't picked up by the compiler because they were generated on the fly
Love to see theo on such an emotional sine curve, being like 'Thats nice.. oh wait..' 😂
Seems more like a square wave.
Tailwind is one of the worst way to create / use styles in your app
Doesn't returning a component instead of a list of classes make using that in the more template-oriented frameworks difficult/problematic?
Great video Theo :)
Love your takes!
The reason I use PandaCSS is I don't want someone can steal my CSS just buy copy html :D PandaCSS is good one, althought TW still has better dev exp
I just don't see the appeal of Tailwind or derivative projects. CSS Modules resolved all the same pain points with CSS since almost a decade ago.
Do we seriously need all these libraries with non-standard syntax and configurations and unreadable git diffs and mandatory IDE plugins just so we don't have to switch tabs and type ".item {}" sometimes?
I think it's about convenience. I used CSS Modules for last 4-5 years I think and started using Tailwind about 6 months ago and would never want to go back to CSS Modules. The fact that I can just write classes and not worry about creating, importing and using extra files is nice.
It's especially nice in those cases where you just have to add some margin/padding to a single element or just do some flex stuff to center it maybe. So instead of creating a css module file, creating a class and then importing and using it for that potentially one off thing, I can just write few classes and be done with it. And you can also have all those classes triggered on certain breakpoints if you need.
One other benefit is that if someone joins a project and they used Tailwind, they don't have to decypher your custom styles, they can just use Tailwind.
Regarding css in js in general, I think that's horrible and think that was a mistake really for the most part lol
If you hate "lg" styles being top level then just don't do that. There's other ways to apply responsive styling
I don't know, i think that was a mistake from the blog author. If i remember right, the correct and only valid way in PandaCSS is doing "_lg"
@@oscarljimenez5717 I think a better example would have been using something like: `padding: { base: 4, md: 6, lg: 12 }`
16:00 need to add safelist on tailwind config
What's wrong whit CSS modules? Why reach to these libraries like Tailwind, Panda or StyleX if you have CSS modules?
Very cool. Personally I use Panda3DS though.
What is the microphone do you use❓
Which browser do you use? This side tab management looks great.
arc
If you think css sucks because it doesn’t respect the order of the classes, you don’t understand css 😬
Explain more
@@LEDsellers CSS Specificity, I think.
If you like the cascading part of style sheets, you are insane
Literally noone likes cascades what are u talking about 😐
That was my thought too 😢
I think it works that way, because say for example you were to remove a class, and re-add it to an element, it shouldn't change how it looks based on where it is in the class list, like based in terms of `Element.classList.remove()` followed by `Element.classList.add()`
uh safelist for tailwind? Like don't have a file with everything you need.
I saw the video thumbnail, then decided to look into the Panda docs, and quickly ended with the same conclusions like you. I think it's too complex and full of options to ensure a maintainable codebase. Right now, I have 3 styling solutions that I like for different reasons:
- Tailwind (although I don't use it, I see why it's so popular)
- StyleX (haven't used it as well, but it seems really great for authoring a shared component library for bigger projects)
- Plain old CSS modules (so simple, perfectly solve the biggest pain points of CSS which is missing colocation and class name clashes, keeps all CSS features, and does nothing more)
CSS is more complex than Panda CSS then. Because you have a thousand ways to declare CSS and in different fashions (BEM? OOCSS? Neither?) so if complexity was the argument against Panda CSS, I don't understand your point. CSS modules only solves one problem, which is scoped styles. But the tools you mentioned avoids that too.
@@dealloc if you have scoped CSS, you don't need any naming convention like BEM or OOCSS anymore. That's the one major problem solved. The rest are well-documented CSS standards. So I think plain CSS, especially with CSS Modules, is way simpler and easier to get.
@@VeitLehmann You still need to name every class for every element that needs some styling, whether it's necessary or not.
The problem of duplication is still prevalent, since they are scoped and makes it impossible to merge identical classes between scopes.
CSS Modules is easy when you're working on single projects, but as you grow to multiple codebases it becomes increasingly harder to scale.
I'm not against CSS Modules. But this is based on my personal experience, working on codebases across multiple projects. It grows exponentially, compared to solutions like Tailwind and StyleX, which grows linearly.
Pressing more key is not bad if the code is more readable. You may understand it, but you're in a team.
Your team will get used to it. When you use tailwind, you get better at reading tailwind. I'm tired of this excuse that working on teams somehow justifies unnecessary verbosity.
@@TheBswanbased. Thank god
CSS-in-JS solutions, build time or run-time, are not alternatives to Tailwind! Look, 70% of my work is In React but the rest of it is in Laravel, Rails, WordPress, plain ol' HTML, Tailwind works perfectly well with those. This will not.
lmaooo - i never knew uploadthing was using a tailwindcss UI template
Bet you might like Typewind 🤷♂ It literally compiles down to Tailwind strings but is safely typed with TypeScript that is generated based on your tailwind.config.js file.
Personally it feels like both of these exist exclusively to deal with the jsx problem of styles. Outside a jsx env tailwind and this seem pointless.
I see this in the frontend world. Developers that are more concerned with presentational aspects don't make really like really really strong tools in the technical aspects, things like type safety, nice abstractions, great performance and so on. But javascript makes it easy to build so we get tons of these free tools. Which I agree is nice and not to be taken for granted. I just think we rely too much on Javascript when instead we should be relying more on preprocessing tools and compilers with strong static analysis... Which is another huge pain to do for JS because of how dynamic and loosy goosy it is with types.
Uh... every JS tool we use today are exactly relying on preprocessing since the very early days of JS. Babel, bundlers, TypeScript, CSS Modules, Tailwind, ESLint, lingui... I could go on. What tools are you referring to that people rely on too much that doesn't do any form of preprocessing?
@@dealloc I am trying to outline the issue with JS that are failed to be fixed with most preprocessor. It feels like the loopholes are just being replaced. ReScript is probably the only language that aims to really fix JS.
Hello I am a Primeagen chat member. So without further a-do
PANDA DEEZ NUTZ!!!!!
Thank you.
At the end of the day it's a matter of taste. I can see how one might argue it's more readable and worth it. I can see how one might argue the opposite.
Type safe CSS? Seriously? lol. I want 2005 back.
tell us you dont work in big teams or designs systems without telling us you're a noob
@@smthngsmthngsmthngdarkside lol. Can you elaborate on why one might need type safe CSS? Do it with a straight face.
@@adamjones7497 you don't need it, the same way you don't need type safe anything except code for super critical infrastructure maybe. Type safety in CSS is more about peace of mind and ease of work.
I don't like these css in js libraries at all, but having type safety when working with design tokens is pretty nice really.
@@rand0mtv660 adding a layer of complexity to solve for a problem that doesn’t necessarily exist doesn’t give me peace of mind. - In terms of CSS specifically why not add audits in CI/CD instead of adding complexity to the implementation?
@@adamjones7497 what audits would you add? Why push that feedback that something is wrong into CI if developers can get it immediately inside their code editor?
Don't get me wrong, I dislike css in js solutions in general, but I cannot deny getting that autocomplete inside the editor and type safety is a nice perk while working with them. It's not something you really "need", but it's a nice feature.
It's like chakra ui
we love you Theo, keep up the great work. Learned alot from your videos.
I reckon most are choosting tailwind because it's fun.
Not sure any amount of features that don't make styling more fun will compete.
23:52 ~class~ time variance authority
Reusable component styles, aka "makeStyles" and "useStyles" is a plague. We have a project like this, with a styles modules that is more confusing than a simple CSS file because some styles are functions receiving properties to create conditional rules; different properties for different styles... all "any", of course. If not using TailwindCSS, my best choice is SASS, loading .module.scss files with clsx for conditional styles STRAIGHT from the component.
Tailwind might be the best thing to happen to FE development the past half decade
Not everyone uses VS-blip, BTW!!
Wait you never got to my favourite part of Panda (well and chakraui), jsx component where instead of pattenrs like css() or className, you just pass styles as attributes. e.g. ...
Panda is more of a low lever library. It's amazing, but unless you are building your own component libraries, the best DX comes once you start using one of the ready-made component libraries based on Panda. Like Ark-ui or park-ui
4:54
@@andrewk2756 Still not the same. Ark and park-ui auto generates all the possible components for you so you don't need to do any of this. I just run 3 commands on a new project and have a full component library with any possible building blocks and common elements (Button, Input, Select, Tabs, Link, Heading, Flex, Hstack, Vstack, Grid, etc, etc)
@@YuriPetusko Well I was replying to your original comment about attributes and that's exactly on the timestamp. You said it yourself Ark and Park UI do this stuff so it's not really a Panda's thing? I'm curious to check it btw now that you mentioned.
@@andrewk2756 Panda is a low level and framework agnostic. Where it shines the most is the component library built on top of it. Ark is the official one by Panda team, if you try it, make sure to try JSX components, it's much more pleasant to work with them and style them with attributes rather than classes (when it's compiled, panda turns them into atomic classes anyway). Park-ui is extra layer on top of Ark that adds opinionated pre-themed component for any use case like forms, sliders, tabs, containers, buttons etc. they have a cli command in getting started docs that will just generate all of them and put them in your folder for easy importing
Yea, I'll stick to my Tailwind thanks lol
Sometimes you have to press harder...
one of the features i wanna see in tailwindcss sudo class group, something like this:
lg:{bg-red-500 text-md}
Oof. Amateur hour. Finger nails on a chalkboard.
After watching this video for 4 minutes, (at which point I had to hit pause and write this) I can emphatically state you should not listen to Theo for advice on CSS/Frontend best practices / libraries. He even admits he's "plateaud learning CSS". And yet, goes on prognosticating, advocating for this and that? His built example is literally a visual rip off of the Tailwind site, and it's literally 50 lines of CSS? Why even use a framework.. These are red flags! After watching this video for 4 minutes I can emphatically state you should not listen to Theo for advice on CSS/Frontend best practices / libraries. Why? He's not dumb. But he's making this video because... he's an influencer. Gotta pump out that content!
He even admits he's "plateaud learning CSS". And yet, goes on prognosticating, advocating for this and that? His built example is literally a visual rip off of the Tailwind site. These are red flags! He makes attempt to weigh our outline the advantages/disadvantages in his bulleted expose. Sure, Tailwind is hypothetically performant. Is your CSS BUNDLE SIZE actually an performance problem for your SPA? If not, then it's not a value add.
He offers zero caveats or "maybe this is a good fit for this size project, and maybe this is NOT a good fit for other projects". People, that's baseline when considering tooling! When you don't give that kind of nuance, you're being dogmatic. And frankly, that's a hallmark of bad dev advice. If you can't even summarize the ways and contexts in which Tailwind is a good choice (and there are good situations to use it), why would you want to hear him rough shot over Panda CSS.
Make a detailed video on react strict dom.
I hate tailwind. Editing styles in the markup is a defect, not a feature. It's an excellent way to make HTML unreadable. Add the requirement of a compiler and ide plug-ins to be productive - this is something for people who don't feel comfortable in CSS.
going to different files for styles is much more unreadable. Colocation with tailwind was a big big win.
@@yojou3695 only if your css is a mess.
I've been writing frontend websites and applications for 18 years, web apps since before backbone js. The closest thing to building an application was concatenating your js files. I've built many many frontends, using everything from Prototype to jQuery to Dojo to Backbone to Ampersand to Angular to Vue, to React. I've done CSS at least a dozen different ways. I've used scss, less, stylus, and even straight css to create ui kits whichwere used by my colleagues in our products. Then came js component frameworks, so I focused on component libraries - first with each component having a css file, then with styled components, and believe it or not, even using tailwind - a terrible decision we renagged on 6 month later because it make our code look like shit and difficult to read.
All of this on projects with customers, not toy projects.
I'm not convinced by your, or anyone else's argument on this because my experience says otherwise 1000x over.
I'm very comfortable with css and used to hold a similar view. I was wrong. Tailwind is great.
Even the simple fact of not having to stress about BEM is a *massive* win for me
Fan of you, but gotta say, you don't know CSS. Go learn about specificity in CSS.
God I miss semantic html. We've strayed so far from the path....
I like it
The no arbitrary value eslint rule falls down at a few hundred files. It was the slowest lint plugin by far, too slow for even locally let alone ci which made it unusable.
Could you expand more on this?
Every time I see these kinds of videos I end up thinking...
These web guys really really like to complicate so much.... Everything is SO complicated when HTML + CSS + JS (with DOM) is already SOOO high level...
I've always done CSS from scratch and I have a history of fighting vs other coders who like using frameworks and all sorts of stuff but I nearly always end up finishing first or near-first while doing most HTML+CSS+JS work from scratch.
It's true I use libraries and I use writing accelerators but I usually end up winning.
What I do loads fast, produces WAY smaller content and changing pages is pretty much near-instanteneous from how fast everything is just layed out.
So when I see all of these tools... Is it really helping in the end? Or is it just 70% helping and then 30% fighting against it?
I feel the same way but I’m trying to make myself think ”maybe I’m just stuck in an old mindset”.
Kinsa arbitrary we often care about serverside validation and safefty…but when it comes to html templates or css - we don’t care. Even though a css flex mistake could make the site unreadable
when new ideas come along to suggest improved validation I feel like saying ”I’ve built sites for 15 years and never needed it”
But it feels like old assembly pros saying ”written asm for 15 years and never needed a high level language” 😅 or ”never needed eslint”
Most things are initially not strictly NEEDED but sometimes over time provide a small value
not worth the switch, I still prefer tailwind
tailwind is the most abstract css can get as of now, any other solution now feels like more keywords to type. Also I never liked mixing JS/TS with css.
Htmx mentioned
I liked pandacss in theory (typed css) and went down that path, but I found it to be too verbose and reverted back to tailwind.
The thumbnail isn’t extreme enough.
if it's to make the development experience this horrible, might as well use vanilla CSS
I can't go back to CSS in JS, I just moved to tailwind a year ago, please no
Sass and tailwind is so bad compared to css and inline
One thing just puzzles me: why all the problems that are written about or discussed in such movies, all these issues that strange libraries try to solve, have never (at least since 2005) been a problem I had to specifically address? It seems to me that these problems are made up, and the libraries only aim to promote their authors.
4:53 was opposite of ruclips.net/video/G7lZBKFFnls/видео.html
EDIT: NEvermind you already mentioned it.
I know this is heresy or something, but there's an ESLint plugin for TailwindCSS which points out "invalid" classes. Also since we already get auto-complete for TW classes with a VSCode plugin, I think these 2 features go a long way towards "type-safe" TW. I don't mind this solution in most projects.
Oh look it's exactly styled components right down to having css`` and shitty default mode that makes you have an individual style object for each element on the screen. Except it smartly maps stuff to classes.
another HUGE problem is the number of concepts to learn in order to use panda effectively. It’s like learning another Language or framework
No, you only use what you need. They give you all posible solution for different teams and problems. But you should always use the basic instead of learning all.
For example, with the CSS prop and CVA you could do 99% of cases.
if you have this problem, why are you a programmer lmao?