6 ms·

As someone using Svelte for a project, I'm always happy to see something less React-specific. But yeah, I'm kinda over Tailwind. You whipper-snappers think CSS

As someone using Svelte for a project, I'm always happy to see something less React-specific. But yeah, I'm kinda over Tailwind. You whipper-snappers think CSS sucks so much; back in my day* we had font tags and tables! *high school

afavour 2y ago
Yeah I know it’s crotchety old man territory but I find CSS absolutely fine to work with these days, now that we have variables etc. Every time I’ve added PostCSS, Tailwind or whatever I’ve found my build times jump a ton and I don’t get a whole lot of use out of it. Plain CSS and containerisation provided by Svelte (or the forthcoming scope stuff) is more than enough for me.
- emseetech 2y ago
  CSS is a dream these days. I understand why it’s intimidating for devs because it’s not meant for engineers it’s meant for designer so it has a wildly different set of assumptions and expectations. But learning it is 100% worth it. Tailwind is like an ORM. I get the appeal but if you know SQL /CSS it’s just going to get in the way.
  - _akhe 2y ago
    I like the SQL/CSS analogy, with the full-stack spectrum being like: SQL - Backend - Frontend - CSS Most people just want to stay in the middle doing backend/frontend ("full-stack") work because it's just writing functions. Or because it's building the core of a feature, where things like database work and styling is pushed off or abstracted in libraries. But on each end is where all the interesting stuff is really happening, and a full-stack dev who embraces both SQL and CSS is a lot more useful than a full-stack dev who stays in the middle.
  - balls187 2y ago
    In addition to intimidating—there is the rote repetitiveness: how many times do you want to style the same components? Or adding the same custom components. Sometimes I just wanna work on my app and not write css.
  - ffsm8 2y ago
    This is ridiculous. Tailwind css is a utility "framework", which generates configured css classes to set 1-2 css attributes each. The only reason it adds a build step is that it wants to tree-shake all unused classes to keep your bundle size as small as possible and let you configure which classes are available for generation. Even the documentation makes it extremely clear which properties are set by which class (the default ones anyway). As an actual example: how completely braindead do you have to be to not know which properties are set from looking at the official documentation? https://tailwindcss.com/docs/overscroll-behavior https://tailwindcss.com/docs/overscroll-behavior Your comparison to an ORM would work for things like Bulma, bootstrap and pretty much all component libraries, including TailwindUI. It's completely nonsensical for tailwindcss You've either never actually looked into tailwind css and are purely talking out of your ass or are just repeating this opinion from someone that did such. Disliking tailwind css is fine, and there are perfectly fine reasons to not use it. But your argument is just plain dumb.
    - Capricorn2481 2y ago
      You're completely right, and it's annoying to see this downvoted. Having read a lot of frontend discussions on HN, I would wager that half the people talking about how "complex" frontend is don't work in it. Tailwind and regular CSS are hardly distinct, it's just slightly different names. It's very odd to see HN, supposedly a "self-thinker" crowd, continuously spout incorrect things because they heard someone else say it on here. Here are other things I've heard on HN repeatedly that aren't true (often in very upvoted comments). - You can't make a static site with React - React is only for SPAs. - You can't use React without NextJS anymore. - PHP is too slow for web development (maybe it is for your use case, but people seem to think it's bad for all use cases). - PHP doesn't have strict type checking. - NPM is somehow worse than every other packaging system (ignoring PIP, Maven, etc. NPM is surprisingly good at things that the rest of packaging systems don't get right).
      - _akhe 2y ago
        > Tailwind and regular CSS are hardly distinct, it's just slightly different names Tailwind: <div className="shadow-lg" /> CSS: div { box-shadow: 0 10px 15px -3px rgb(0 0 0 / 0.1), 0 4px 6px -4px rgb(0 0 0 / 0.1); } Not to mention the Tailwind classNames are compiled to CSS in a build step, where CSS is not compiled, it's written in its native form. They're clearly very different syntaxes and approaches, even though one compiles to the other. The above example shows how convenient Tailwind can be... well if you happen to want that 10px 15px -3px, 4px 6px -4px shadow, but the moment you break out of their palette or default style setup you end up doing stuff like this: <div className="bg-[#243c5a]" /> Either storing that color value in JavaScript, or creating a Tailwind theme for it in tailwind.config.js: module.exports = { theme: { extend: { colors: { 'regal-blue': '#243c5a' } } } } Something that could have been easily accomplished in native CSS: :root { --regal-blue: #243c5a; } div { background-color: var(--regal-blue); } For most React websites, I use Tailwind by default almost always, and Tailwind UI is a great starting point for building a component library. But it still helps to support CSS for more advance styling use cases - even within Tailwind. Knowing CSS very well will make you better at Tailwind too even for common things like <div className="w-[calc(100% - 1rem)]" /> It's kinda important to know both as separate technologies.
  - nullandvoid 2y ago
    For me it's not intimidating, it's just time consuming. I can create / iterate twice as fast when I'm styling inline with my HTML. It could be with tailwind, or other utility based libraries - tailwind has just done it the best from my experience.

afavour 2y ago

Yeah I know it’s crotchety old man territory but I find CSS absolutely fine to work with these days, now that we have variables etc. Every time I’ve added PostCSS, Tailwind or whatever I’ve found my build times jump a ton and I don’t get a whole lot of use out of it. Plain CSS and containerisation provided by Svelte (or the forthcoming scope stuff) is more than enough for me.

emseetech 2y ago
CSS is a dream these days. I understand why it’s intimidating for devs because it’s not meant for engineers it’s meant for designer so it has a wildly different set of assumptions and expectations. But learning it is 100% worth it. Tailwind is like an ORM. I get the appeal but if you know SQL /CSS it’s just going to get in the way.
- _akhe 2y ago
  I like the SQL/CSS analogy, with the full-stack spectrum being like: SQL - Backend - Frontend - CSS Most people just want to stay in the middle doing backend/frontend ("full-stack") work because it's just writing functions. Or because it's building the core of a feature, where things like database work and styling is pushed off or abstracted in libraries. But on each end is where all the interesting stuff is really happening, and a full-stack dev who embraces both SQL and CSS is a lot more useful than a full-stack dev who stays in the middle.
- balls187 2y ago
  In addition to intimidating—there is the rote repetitiveness: how many times do you want to style the same components? Or adding the same custom components. Sometimes I just wanna work on my app and not write css.
- ffsm8 2y ago
  This is ridiculous. Tailwind css is a utility "framework", which generates configured css classes to set 1-2 css attributes each. The only reason it adds a build step is that it wants to tree-shake all unused classes to keep your bundle size as small as possible and let you configure which classes are available for generation. Even the documentation makes it extremely clear which properties are set by which class (the default ones anyway). As an actual example: how completely braindead do you have to be to not know which properties are set from looking at the official documentation? https://tailwindcss.com/docs/overscroll-behavior https://tailwindcss.com/docs/overscroll-behavior Your comparison to an ORM would work for things like Bulma, bootstrap and pretty much all component libraries, including TailwindUI. It's completely nonsensical for tailwindcss You've either never actually looked into tailwind css and are purely talking out of your ass or are just repeating this opinion from someone that did such. Disliking tailwind css is fine, and there are perfectly fine reasons to not use it. But your argument is just plain dumb.
  - Capricorn2481 2y ago
    You're completely right, and it's annoying to see this downvoted. Having read a lot of frontend discussions on HN, I would wager that half the people talking about how "complex" frontend is don't work in it. Tailwind and regular CSS are hardly distinct, it's just slightly different names. It's very odd to see HN, supposedly a "self-thinker" crowd, continuously spout incorrect things because they heard someone else say it on here. Here are other things I've heard on HN repeatedly that aren't true (often in very upvoted comments). - You can't make a static site with React - React is only for SPAs. - You can't use React without NextJS anymore. - PHP is too slow for web development (maybe it is for your use case, but people seem to think it's bad for all use cases). - PHP doesn't have strict type checking. - NPM is somehow worse than every other packaging system (ignoring PIP, Maven, etc. NPM is surprisingly good at things that the rest of packaging systems don't get right).
    - _akhe 2y ago
      > Tailwind and regular CSS are hardly distinct, it's just slightly different names Tailwind: <div className="shadow-lg" /> CSS: div { box-shadow: 0 10px 15px -3px rgb(0 0 0 / 0.1), 0 4px 6px -4px rgb(0 0 0 / 0.1); } Not to mention the Tailwind classNames are compiled to CSS in a build step, where CSS is not compiled, it's written in its native form. They're clearly very different syntaxes and approaches, even though one compiles to the other. The above example shows how convenient Tailwind can be... well if you happen to want that 10px 15px -3px, 4px 6px -4px shadow, but the moment you break out of their palette or default style setup you end up doing stuff like this: <div className="bg-[#243c5a]" /> Either storing that color value in JavaScript, or creating a Tailwind theme for it in tailwind.config.js: module.exports = { theme: { extend: { colors: { 'regal-blue': '#243c5a' } } } } Something that could have been easily accomplished in native CSS: :root { --regal-blue: #243c5a; } div { background-color: var(--regal-blue); } For most React websites, I use Tailwind by default almost always, and Tailwind UI is a great starting point for building a component library. But it still helps to support CSS for more advance styling use cases - even within Tailwind. Knowing CSS very well will make you better at Tailwind too even for common things like <div className="w-[calc(100% - 1rem)]" /> It's kinda important to know both as separate technologies.
- nullandvoid 2y ago
  For me it's not intimidating, it's just time consuming. I can create / iterate twice as fast when I'm styling inline with my HTML. It could be with tailwind, or other utility based libraries - tailwind has just done it the best from my experience.