7 ms·
I’m a fan of tailwind. But I do wonder if inlining classes into each and every element is as efficient as CSS rules that apply to those same elements. Imagine
by psadri 5y ago
I’m a fan of tailwind.
But I do wonder if inlining classes into each and every element is as efficient as CSS rules that apply to those same elements.
Imagine you have a table with a few hundred cells. You can have something like:
.my_table .cell { ... }
Or repeat those classes in each cell. Is there a performance, memory etc impact?
- imilk 5y agoYou can group Tailwind classes into parent classes using @apply and everything works as you'd expect
- ehutch79 5y agoAdam Wathan even says this is a code smell, and is just for the myriad of corner cases. If all your classes are in an apply, why not just use the CSS? most of the utility classes are one line classes
- city41 5y agoI feel like one of the best benefits of Tailwind is often overlooked. It's essentially a design system in a box. A simple and general one (which makes sense), but a system none the less. All of the classes being related to each other, ie in `p-1` and `m-1`, the 1 means the same value (0.25 rem). But also the fact that the sizing system exists and is pragmatic is very useful. Tailwind sites often feel more consistent and they just "feel" better because Adam and his team took the time to design a well considered sizing system. The same holds true of colors, shadows, font size, etc. And even better, if you work at a place where a custom design system is needed, Tailwind has pretty much everything you need to customize your own but still give the same Tailwind productivity to developers.
- galuggus 5y agoYes. I use tailwind because it's the easiest way to get something responsive working very quickly. I'm not a designer but stuff made with tailwind always looks presentable and clean. With vanilla CSS I'm constantly forgetting media queries and fail to have consistent margins and padding. Tailwind is great!
- omniscient_oce 5y agoThis is the same as most CSS-in-JS solutions though isn't it?You have a theme.js (that comes with a default) that confirms to the theme UI standard that is pretty much what your tailwind.config.js is. Then you can save variants (similar to @apply in Tailwind).
- city41 5y agoI've only used styled-components to any extent for css-in-js, I don't remember it having anything to do with a design system? Can you name some examples, you got me curious. Do these theme.js files have full sizings, spacings, etc defined?
- imilk 5y agoBecause the code can get hard to parse, especially if you are using conditional classes based on state or other values.
- nickUCB 5y agoSure you can do tricks like this, but at a certain point it just wraps back around and suddenly you find yourself just doing regular CSS anyways.
- imilk 5y agoNot really, because I only really use @apply for conditional classes and Tailwinds still provides you with a standardization for your CSS code that you don't have otherwise.
- aidos 5y agoI’ve wondered the same but haven’t done any digging into it yet. We’re in the middle on migrating a lot of code over and I plan to test the impact. It’s all going to depend on what sort of optimisations are done by the browser. They could very well cache style rules by class combination hashes. (They probably don’t, but it’s possible). Whatever happens, in my case it’s going to be better than the laggy material ui and css-in-is tooling we were using before.
- yurishimo 5y agoMemory impact, no. Atomic stylesheets are generally fractions of the size of a traditional monolithic CSS file. I've loaded up a 6MB CSS file for development locally and it's instant. Performance is more complicated, but generally it's never an issue. We've had huge webpages forever, often with many different CSS files and HTML included from all across an application and organization. When the browser has all of the CSS files finally loaded into memory, it's FAST. Here's an old article[0] that looked into some performance metrics. 7000 DOM nodes per page, with crazy nested selectors. The delta between the different tests was around 10% (10-100ms depending on the browser) from the simplest to most complicated, but the absolute rendering time has was still under 200ms for all browsers. Important to note that this test was also conducted when IE9 was still relevant. Computers, and even low end devices, are much faster than what was available in that era. I reran the tests from the article in Chrome just now, and the insanity selector test ran consistently in under 100ms on a 2020 quad core MacBook Pro. Chrome's performance benchmarking tools confirmed that number as well as the simple benchmark included in the test source. We also have to take into account that the types of classes included with atomic CSS frameworks are extremely simple for browsers to parse and apply. Because they aren't deeply nested spaghetti, the browser can more quickly index them for use later in the rendering lifecycle. I would be interested to see what the effects are of atomic CSS on performance using our modern browser environments, but I would guess it's negligible and not relevant compared to any other part of the page rendering and refresh lifecycle. 0: https://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/ https://benfrain.com/css-performance-revisited-selectors-blo...
- neovive 5y agoI've been using Tailwind for the past year and enjoy the workflow when used with front-end component frameworks (e.g. React, Vue, Alpine) and back-end template engine using partials or components. Using components keeps most of your Tailwind classes centralized and easy to update -- it's great to be able to just open a component and tweak some classes to change the UI. Use props to conditionally change the Tailwind classes in your components. Previously, searching through CSS/SCSS took a bit more reasoning and I found myself creating redundant classes over time to handle edge cases.