3 ms·

See also: https://twitter.com/thomasfuchs/status/810885087214637057?lang=en https://twitter.com/thomasfuchs/status/810885087214637057?la... I get it; there is

See also: https://twitter.com/thomasfuchs/status/810885087214637057?lang=en https://twitter.com/thomasfuchs/status/810885087214637057?la... I get it; there is more than one way to do something--especially in code--and what feels correct for one person may leave a bad taste with another. It's just that nobody has been able to explain to me yet how JSX, Tailwind, etc... are overcoming the complexities that such mixing of concerns introduced before those projects came along.

ratww 6y ago
Let me try to explain: in the past, best practices dictated we should separate things by language because it was the best we could do at the time. Also it allowed for "skinning" websites, which was nice. But after a while we noticed that wasn't enough, giving rise to CSS methodologies like OOCSS and BEM that aimed at separating CSS by components. We also started doing the same with Javascript, and even HTML using helpers or smaller "per-component-templates" in backend frameworks. Now, we have components, and that is your "separation of concerns". Modern frameworks like React and Vue allow you to have even smaller components, which means less code. Mixing languages stopped being an issue for most programmers. If you're still not comfortable, you can still do it: in Vue.js it's quite trivial to have separate JS/CSS/HTML files. But most people have moved past that since small components give them the separation of concerns they need. Also, remember the skinning part? With SASS/SCSS/native variables, you can now abstract your CSS and keep them closer to the code without losing the possibility to change the appearance. As to Tailwind, Bootstrap had already paved the way for helper classes. Lots of people used them in a non-components websites and it worked for them. The only issue they had was that helper classes require some copy+paste that would make maintenance difficult. But now that we have good component systems it's not a problem anymore, and Tailwind is pretty good for maintenance. Also, regarding skinning: with a Tailwind-like frameworks you also get some help with this, since it's the same primary-color class all over the system. EDIT: Another great argument I read here at HN is that even with Tailwind there is still a separation between content and presentation. It's just that before my "content" was in my HTML and my "presentation" was in my CSS. Now, my "content" is in my JSON while my "presentation" is my HTML/CSS. Tailwind as an extension of HTML makes a lot of sense in this context.

ratww 6y ago

Let me try to explain: in the past, best practices dictated we should separate things by language because it was the best we could do at the time. Also it allowed for "skinning" websites, which was nice. But after a while we noticed that wasn't enough, giving rise to CSS methodologies like OOCSS and BEM that aimed at separating CSS by components. We also started doing the same with Javascript, and even HTML using helpers or smaller "per-component-templates" in backend frameworks. Now, we have components, and that is your "separation of concerns". Modern frameworks like React and Vue allow you to have even smaller components, which means less code. Mixing languages stopped being an issue for most programmers. If you're still not comfortable, you can still do it: in Vue.js it's quite trivial to have separate JS/CSS/HTML files. But most people have moved past that since small components give them the separation of concerns they need. Also, remember the skinning part? With SASS/SCSS/native variables, you can now abstract your CSS and keep them closer to the code without losing the possibility to change the appearance. As to Tailwind, Bootstrap had already paved the way for helper classes. Lots of people used them in a non-components websites and it worked for them. The only issue they had was that helper classes require some copy+paste that would make maintenance difficult. But now that we have good component systems it's not a problem anymore, and Tailwind is pretty good for maintenance. Also, regarding skinning: with a Tailwind-like frameworks you also get some help with this, since it's the same primary-color class all over the system. EDIT: Another great argument I read here at HN is that even with Tailwind there is still a separation between content and presentation. It's just that before my "content" was in my HTML and my "presentation" was in my CSS. Now, my "content" is in my JSON while my "presentation" is my HTML/CSS. Tailwind as an extension of HTML makes a lot of sense in this context.