Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Play with TailwindCSS in the Browser

play.tailwindcss.com

Post reply on HN
Print view View original

271–280 of 300 posts

Re: Play with TailwindCSS in the Browser

#271

Post by toastal »

jbenner-radham wrote: post #245
toastal wrote: post #195

Earlier quoted context omitted.

It's Sass, not SASS. The native libsass is much faster. The headaches come from people trying to distribute binaries and libraries through NPM.

If we're being pedantic technically it's npm and not NPM ;)

Oof. I did not know this one.

> npm (originally short for Node Package Manager)

Acronyms can make sense to switch case, but initialisms... en-pee-em... I guess it happens. I originally was introduced it as Node Package Manager, but I'm gonna make an effort to correct this now.

Re: Play with TailwindCSS in the Browser

#272

Post by bavila »

dangerface wrote: post #156
onion2k wrote: post #40

Earlier quoted context omitted.

It’s like you have to learn every raw CSS selector, and then also learned how it’s represented in Tailwind, and then scatter that all over your markup. That's exactly what it is. But... you have to do that regardless of what you use for CSS layout. If you're not using Tailwind (or something like it) then you're going to end up creating classes using the raw CSS, and then naming them yourself, and then having to remem…

It seems like the main advantage of tailwind is that you don't have to learn how CSS cascading and specificity works, which is a fair advantage as most frontend developers I talk to don't even realise that specificity is a thing. I don't see the advantage over inline style tho. I see abbreviations as a disadvantage as its just as fast to type background as it is bg but background is clearly more intelligible. How do…

>...which is a fair advantage as most frontend developers I talk to don't even realise that specificity is a thing.

Really? I'm not sure I could take someone seriously if they called themselves a frontend developer and did not understand CSS specificity.

Re: Play with TailwindCSS in the Browser

#273

Post by calvinmorrison »

yurishimo wrote: post #191
calvinmorrison wrote: post #167

Earlier quoted context omitted.

You're just shifting work though. The commit will now contain 10000 non html structure changes to an html, phtml, whatever, instead styles to a CSS sheet. Might as well go back to doing inline styles. There's a reason we don't do that anymore.

This isn't the 90s. We all use file includes now. If you're working on a view file longer than a couple hundred lines, properly formatted, you're not abstracting enough or it's a one off marketing thing.

And there we go...

"We all use 'cascading sheets' now. If you're working on a CSS file longer than a couple hundred lines, properly formatted, you're not abstracting enough or it's a one off marketing thing."

Re: Play with TailwindCSS in the Browser

#274

Post by lenkite »

65 wrote: post #80

I used to be a Tailwind hater. I couldn't fathom why anyone would ever use it. And then I used it. It seriously makes CSS significantly easier to maintain, dramatically reduces your CSS build size, and is really good for teams if you're trying to use consistent CSS throughout your UIs. You also don't need to go back and forth between CSS file and HTML file. If you're on the fence, try it out. I think it's the future…

" dramatically reduces your CSS build size"

Isn't this at the cost of dramatically increasing HTML size ? I have seen tailwind littered HTML increase by 2x-3x the page size with all that extra-ordinary repetition.

PS: I agree it makes CSS coding quite faster due to less typing involved when designing something thanks to succinct atomic CSS classes. I am not sure less typing is better though, especially for maintainability and performance.

Re: Play with TailwindCSS in the Browser

#275

Post by lenkite »

jozzy-james wrote: post #267
junon wrote: post #263

Earlier quoted context omitted.

We did back then too. In fact we had SSR. It often took the form of CGI, like PHP - which, hate the language all you want, it has a very sane and scalable model.

and bi-directional data flow was done in the form on long polling. this sounds very much like a get off my lawn argument rather than anything rooted in reality of the now.

Long polling has turned into SSE. And rocks with HTTP/2. What was once old is new and in vogue again!

Re: Play with TailwindCSS in the Browser

#276

Post by [deleted] »

shroompasta wrote: post #207
majkinetor wrote: post #204

Earlier quoted context omitted.

You seem to miss the bigger point - Tailwind constraint your css use so that you don't imagine stuff in ad-hoc manner. And you can split, and sort classes with editor plugins which makes it almost equally good as your example.

i think you missed his point to be honest. Regardless of where place your tailwindcss or where you split / sort classes, reading iteratively from left to right, especially if the css rules are numerous, is not legible. just looking at the two examples above, and already I can tell how much it would be easier to maintain verbose css.

[deleted]

Re: Play with TailwindCSS in the Browser

#277

Post by lenkite »

yurishimo wrote: post #191
calvinmorrison wrote: post #167

Earlier quoted context omitted.

You're just shifting work though. The commit will now contain 10000 non html structure changes to an html, phtml, whatever, instead styles to a CSS sheet. Might as well go back to doing inline styles. There's a reason we don't do that anymore.

This isn't the 90s. We all use file includes now. If you're working on a view file longer than a couple hundred lines, properly formatted, you're not abstracting enough or it's a one off marketing thing.

"If you're working on a view file longer than a couple hundred lines,"

Sorry, but this might just mean one file-include per tag if you use tailwind-css. The in-line CSS exceeds the HTML content by sometimes an order of magnitude bloating the page HTML to ginormous size.

Re: Play with TailwindCSS in the Browser

#278

Post by [deleted] »

ramesh31 wrote: post #153
erokar wrote: post #105

Earlier quoted context omitted.

I've used Tailwind on many projects at work for about a year now. I do not like it. Tailwind seemingly affords an easy way of writing inline styles, but it 1) clutters the HTML, 2) leads to repetition and makes people break the DRY principle (yes, you should extract to components, but people don't always do that), 3) uses names that can be similar but are not identical to CSS properties and feels like a bad abstracti…

> 1) clutters the HTML, Or, it makes your HTML far more representative of the state of your application, rather than having to open up a CSS file and match to the class name + whatever madness you have going on in your SASS with mixins and conditional style logic. > 2) leads to repetition and makes people break the DRY principle (yes, you should extract to components, but people don't always do that) Blindly followin…

[deleted]

Re: Play with TailwindCSS in the Browser

#279

Post by rawfan »

debrice wrote: post #149
Vinnl wrote: post #146

Earlier quoted context omitted.

If you're using a component-based architecture (e.g. when using React, Vue or Angular), otherwise it can get pretty annoying. But if you do, it's pretty great; you don't really need the abstraction of reusable classes, when you already have reusable components, and getting rid of useless abstractions makes me a happy programmer.

I would add that, even for regular HTML you can write CSS using @apply and still leverage the nice structure tailwind provides while creating your component CSS classes.

You can also just use regular webcomponents and make re-usable components regardless of frontend or backend usage.

Re: Play with TailwindCSS in the Browser

#280

Post by xigoi »

andiareso wrote: post #81
the_other wrote: post #72

Earlier quoted context omitted.

> If you're not using Tailwind (or something like it) then you're going to end up creating classes using the raw CSS, and then naming them yourself, and then having to remember what you called them. This is true. But if we better taught the cascade and promoted the idea of global styles rather than pretending it's a problem then more people would be better at this and the problems would gently recede. We (the high-en…

But this isn't much different than: extends I'd argue you have less markup to write overall if you are modularizing component logic/styling

The difference is that your website will be much larger and won't work without JavaScript.
Post reply on HN