Open AleksandrHovhannisyan opened 3 years ago
I'm making my own framework. Class bloat and div soup needs to stop. What if you need to rebrand? What about a11y? Semantics are the future.
I would also add that, yes, the CSS file may very well be significantly smaller than Bootstrap or other frameworks. However, that is all lost when you simply move the CSS to the HTML file and bloat that file... Developers just move the bytes from the CSS file to the HTML file that developers seemingly forget about.
The article already mentions this.
In pursuit of efficiency, we often find ourselves drowning in a sea of frameworks and features, drifting away from the core essentials. While these tools promise swift achievement of goals, they often come at the cost of flexibility. Let's refrain from layering abstractions upon abstractions, such as using TypeScript atop JavaScript or Tailwind over CSS. Initially, we may fragment logic to expedite tasks, only to later amalgamate them due to complacency.
@apply
is regular CSS but harder to read.
- Tailwind is repetitive. For example, I never want a default button on my site, only styled ones, like all sane people. Do I have to apply classes to every button?
You do realize that there are other selectors in CSS than just classes?
- Taliwind basically forces you to use JS. JS is overused.
You can use TW without any JS (by CDN).
- Even if your CSS is smaller, the HTML will be bigger, and you need to load much more HTML, whilst the CSS can be cached.
You can write your custom classes and put all TW stuff in CSS with @apply
, after PostCSS, you CSS and HTML are quite small.
- Using
@apply
is regular CSS but harder to read.
@apply
is not CSS, it's a marker for PostCSS, which has to be processed by JavaScript.
- You depend on Tailwind for CSS support. It's not extensible.
TW is extensible, read the docs.
In pursuit of efficiency, we often find ourselves drowning in a sea of frameworks and features, drifting away from the core essentials. While these tools promise swift achievement of goals, they often come at the cost of flexibility. Let's refrain from layering abstractions upon abstractions, such as using TypeScript atop JavaScript or Tailwind over CSS. Initially, we may fragment logic to expedite tasks, only to later amalgamate them due to complacency.
I don’t think TypeScript is the problem. It’s the frameworks that use it. TypeScript can be used in place of Vanilla Javascript, to allow large teams to work efficiently with Type safety. And JSDocs doesn’t create an adequate replacement.
Note: Please keep comments civil. Abusive comments will be removed.