4 ms·

I didn’t mean to suggest that people should invest time to remove bootstrap. Only that Bootstrap offers far less now than it did in the past, and shouldn’t be c

I didn’t mean to suggest that people should invest time to remove bootstrap. Only that Bootstrap offers far less now than it did in the past, and shouldn’t be considered the default option when starting any new project. Among the downsides is its size, obviously. I also consider the html it encourages among the ugliest things since the invention of PHP. This is from the documentation: <button type="button" class="btn btn-dark"> Classes such as “col-sm” are little better than style=“...”. While accessibility seems to have improved over the last years, my intuition is this happened in spite of the idea of semantically meaningful HTML being abandoned and not because of it. I used to worry about this, but had to abandon that particular fight for the sake of my mental health at about the time someone decided to name one of these frameworks “semantical”. But with CSS Grids and Flexbox, layout has become just as easy and actually more flexible than using Bootstrap. Why would you add code and become pigeonholed into one framework when you could archive the same using vanilla CSS?

rchaud 7y ago
> Why would you add code and become pigeonholed into one framework when you could archive the same using vanilla CSS? It's open source and can be forked and modded to your heart's content. How is that being pigeonholed? Most developers don't work at companies where they roll their own UI components, and have QA and accessibility experts that can determine if their in-house accordions, modals, etc. are ARIA compliant. The business case for switching over has to go beyond "it's vanilla CSS", especially if time can be better spent improving the user experience or product features.
robertoandred 7y ago
What's your main objection to that snippet?
hombre_fatal 7y ago
This debate seems out of place given that it's been belabored since CSS frameworks became a thing. But consider how CSS files easily become append-only junk drawers. And you may have to scour arbitrary files just to see what CSS affects this one button on this one component on this one page. And even if you find the CSS that you think affects the html node, you have to open your browser and use inspect element to see if there's anything that cascades over it. Meanwhile, a simple class doesn't lie. And CSS doesn't even have native mixin reusability like `.form button { @mixin button } `. There are clearly trade-offs here. For example, it's a huge deal when modifying complex UI to see these classes inline and being able to change things in a single file without the indirection of a CSS file. You can get a chip on your shoulder about your arbitrary views on what is right and wrong, but people clearly find these non-semantic classes useful. I've worked at a company that had very purist views on how CSS should be written where there were almost no classes in the html, and it was very hard to make large UI changes without credentializing in multiple CSS files. There is no free win.

rchaud 7y ago

> Why would you add code and become pigeonholed into one framework when you could archive the same using vanilla CSS? It's open source and can be forked and modded to your heart's content. How is that being pigeonholed? Most developers don't work at companies where they roll their own UI components, and have QA and accessibility experts that can determine if their in-house accordions, modals, etc. are ARIA compliant. The business case for switching over has to go beyond "it's vanilla CSS", especially if time can be better spent improving the user experience or product features.

robertoandred 7y ago

What's your main objection to that snippet?

hombre_fatal 7y ago

This debate seems out of place given that it's been belabored since CSS frameworks became a thing. But consider how CSS files easily become append-only junk drawers. And you may have to scour arbitrary files just to see what CSS affects this one button on this one component on this one page. And even if you find the CSS that you think affects the html node, you have to open your browser and use inspect element to see if there's anything that cascades over it. Meanwhile, a simple class doesn't lie. And CSS doesn't even have native mixin reusability like `.form button { @mixin button } `. There are clearly trade-offs here. For example, it's a huge deal when modifying complex UI to see these classes inline and being able to change things in a single file without the indirection of a CSS file. You can get a chip on your shoulder about your arbitrary views on what is right and wrong, but people clearly find these non-semantic classes useful. I've worked at a company that had very purist views on how CSS should be written where there were almost no classes in the html, and it was very hard to make large UI changes without credentializing in multiple CSS files. There is no free win.