4 ms·

> I really feel like people start with their conclusion that they don't like it because it's weird and foreign and then look for excuses to justify why they thi

> I really feel like people start with their conclusion that they don't like it because it's weird and foreign and then look for excuses to justify why they think it's bad. At least from this article, I get the impression the author used tailwind for a bit and kept running into these issues where he had to go in and fix it manually in CSS. After enough of these, you get annoyed.

onion2k 4y ago
After enough of these, you get annoyed. If they're typical things that you'd expect a library to solve, sure. If they're "I want my element to rotate in 3D" then most developers would think they're just working outside of the scope of the library.
- sfvisser 4y ago
  Libraries that have a scope defined implicitly by what accidentally works or doesn’t work can still be very annoying.
  - tonerow 4y ago
    _this_
  - Aeolun 4y ago
    It's not like the `style` object is far away. Nothing about Tailwind prohibits you from using normal classes.
    - admax88qqq 4y ago
      Yes tailwind let's you reach through and apply some CSS directly. Almost like its an abstraction that exposes, or leaks, that which it attemps to abstract. A "leaky abstraction" if you will.
      - horsawlarway 4y ago
        Honestly - I find this opinion misguided. It's like saying a for loop is a leaky abstraction over a while loop. Which... is asinine. One is simply a redacted and simplified expression of the most common implementation of the other case. Tailwind falls into the same bucket - in my opinion. Like most frameworks, it's not there to handle your niche and complex use-cases. It's there to provide bumpers that push you into a pit of success for common use cases. When you need to do something that's not common - use the escape hatches that are built in. That's not leaking - that's giving you the flexibility to fall back to a custom implementation. The goal just isn't "abstraction" from css. It's common-sense, local, and consistent styling for common cases. I can build most lego sets from single square blocks - but it's nice to have a bigger selection available. Does that mean I need to understand those bigger pieces to make sure they fit, don't have weird gaps, and line up? Absolutely. Does that mean I shouldn't use them? No, probably not. But it does mean that sometimes I still need single square blocks.
        wokwokwok 4y ago
        I think the opinion here comes from other compile-to-x languages. Let’s look at typescript, or sass. There is (afaik) no construct in the underlying js or css that cannot be represented using them. You could conceivably never learn javascript, learn typescript and basically be fine. So when people say “leaky abstraction” they seem to be assuming that tailwind, which is a framework will allow you to represent every possible css output. …which it can’t do, obviously, and was never intended to do. All I’m pointing out is that the expectation that it could might not be quite so daft when viewed from the lens of “I expected tailwind to be a framework in the same way sass is” or perhaps “the same way this framework that compiles using sass is”. It’s like if I was using vue, and found that the template language can’t express complex logic without writing js (h() expressions) and not using the template language at all. It’s wrong to say it’s a leaky abstraction; but it’s maybe not completely asinine to say, it a bit rubbish that you have to do that as soon as you hit any non trivial use case… > Like most frameworks, it's not there to handle your niche and complex use-cases. It's there to provide bumpers that push you into a pit of success for common use cases. …but as you say. Quite so. Im just saying I can see the frustration people encounter when they have the naive expectation that those edge cases are rare enough they’ll never hit them, and then immediately run into them.
  - root_axis 4y ago
    Based on this reasoning, C is a leaky abstraction because you can inline asm into a C program.
    - gaganyaan 4y ago
      That's true. To borrow from another famous quote: All abstractions are leaky; some are useful
      - root_axis 4y ago
        Wise words.
- yellow_lead 4y ago
  Yeah I agree and someone could probably write a whole article about making expectations from users on your libraries.
diob 4y ago
They allow plugins to add features. I'm sure if enough use the plugin, it would get added to the core.
- luxcem 4y ago
  Which is exactly what is explained in the article : "with the official recommendation being to just write a custom JavaScript plugin to implement it."

onion2k 4y ago

After enough of these, you get annoyed. If they're typical things that you'd expect a library to solve, sure. If they're "I want my element to rotate in 3D" then most developers would think they're just working outside of the scope of the library.

sfvisser 4y ago
Libraries that have a scope defined implicitly by what accidentally works or doesn’t work can still be very annoying.
- tonerow 4y ago
  _this_
- Aeolun 4y ago
  It's not like the `style` object is far away. Nothing about Tailwind prohibits you from using normal classes.
  - admax88qqq 4y ago
    Yes tailwind let's you reach through and apply some CSS directly. Almost like its an abstraction that exposes, or leaks, that which it attemps to abstract. A "leaky abstraction" if you will.
    - horsawlarway 4y ago
      Honestly - I find this opinion misguided. It's like saying a for loop is a leaky abstraction over a while loop. Which... is asinine. One is simply a redacted and simplified expression of the most common implementation of the other case. Tailwind falls into the same bucket - in my opinion. Like most frameworks, it's not there to handle your niche and complex use-cases. It's there to provide bumpers that push you into a pit of success for common use cases. When you need to do something that's not common - use the escape hatches that are built in. That's not leaking - that's giving you the flexibility to fall back to a custom implementation. The goal just isn't "abstraction" from css. It's common-sense, local, and consistent styling for common cases. I can build most lego sets from single square blocks - but it's nice to have a bigger selection available. Does that mean I need to understand those bigger pieces to make sure they fit, don't have weird gaps, and line up? Absolutely. Does that mean I shouldn't use them? No, probably not. But it does mean that sometimes I still need single square blocks.
      - wokwokwok 4y ago
        I think the opinion here comes from other compile-to-x languages. Let’s look at typescript, or sass. There is (afaik) no construct in the underlying js or css that cannot be represented using them. You could conceivably never learn javascript, learn typescript and basically be fine. So when people say “leaky abstraction” they seem to be assuming that tailwind, which is a framework will allow you to represent every possible css output. …which it can’t do, obviously, and was never intended to do. All I’m pointing out is that the expectation that it could might not be quite so daft when viewed from the lens of “I expected tailwind to be a framework in the same way sass is” or perhaps “the same way this framework that compiles using sass is”. It’s like if I was using vue, and found that the template language can’t express complex logic without writing js (h() expressions) and not using the template language at all. It’s wrong to say it’s a leaky abstraction; but it’s maybe not completely asinine to say, it a bit rubbish that you have to do that as soon as you hit any non trivial use case… > Like most frameworks, it's not there to handle your niche and complex use-cases. It's there to provide bumpers that push you into a pit of success for common use cases. …but as you say. Quite so. Im just saying I can see the frustration people encounter when they have the naive expectation that those edge cases are rare enough they’ll never hit them, and then immediately run into them.
- root_axis 4y ago
  Based on this reasoning, C is a leaky abstraction because you can inline asm into a C program.
  - gaganyaan 4y ago
    That's true. To borrow from another famous quote: All abstractions are leaky; some are useful
    - root_axis 4y ago
      Wise words.
yellow_lead 4y ago
Yeah I agree and someone could probably write a whole article about making expectations from users on your libraries.

diob 4y ago

They allow plugins to add features. I'm sure if enough use the plugin, it would get added to the core.

luxcem 4y ago
Which is exactly what is explained in the article : "with the official recommendation being to just write a custom JavaScript plugin to implement it."