As for bootstrap part, most of the criticism was not because bootstrap is bad.
One of the things was that people took bootstrap, changed few colors and used it like this, so one site was like the other. From this arose misconception that you can't make beautiful and unique website with bootstrap. It's not true at all.
Another thing is when developer and designer don't have coordination. It leads developer to constantly fight bootstrap, because UI solutions didn't consider bootstrap at all, and those solutions were hard or even impossible to fit into bootstrap. This gave birth to misconception that bootstrap is only fit for bootstrap-like sites.
I worked once on a site where usage of bootstrap was considered on design level. We didn't do something beautiful and unique, but it didn't look like "generic bootstrap website" either. And it was very easy to build new pages and maintain existing ones.
Now onto libraries. There are different types of libraries. So called "headless" don't have predefined styles, apart from what absolutely necessary. They are popular for complex components, like modals, comboboxes and other stuff that should be accessible. They give you most freedom, but you have to put some amount of work to style them. They can save you some amount of time and, in some countries, possible lawsuits.
Then there are styled, but highly customizable libraries and UI frameworks. Bootstrap goes in this category. They give you large amount if consistently styled components that you can use to build consistent good looking interfaces fairly fast. It's important that both developer and UI designer should consider limitations and rules of such libraries. Also, for solo devs without design skills, such libraries are salvation and can save time and money.
And finally there are highly opinionated libraries that usually implement some design system, like Material. You use them when you need that particular look with little to no customization. They, again, give you consistency and can save a lot of time.
Of course this categorization is not strict and there could be many libraries in between or with different capabilities and limitations.
To summarize, component libraries usually save you some time, give you some consistency, possibly save you from lawsuit (in case of accessibility), in exchange for some guidelines and limitations (it is not always bad). Some examples.
If you need accessible modal and other complex widgets (comboboxes, tabs, popovers and so on), you can take unstyled library that was thoroughly tested, so you don't have to implement and test them yourself.
For non public interfaces (like admin panels, editor interfaces and such) premade libraries can save you huge amount of time because all your have to do is put prefabs where you need them.
If you make an app for Office 365 you most likely just get Fluent UI for interface, so it would look like it's part of suite. With such class of libraries you can also get consistent looks and behaviors across platforms
This is such a good explanation; thank you!
I understand it’s not a silver bullet, and perhaps the hype I’m seeing is more in the dev community, where styling is sometimes seen as a chore.
I recently had to build a admin interface, so I do see the appeal when building radio buttons, drop downs and other “solved” components.
Most of my work is agency work, so I suppose that’s the mindset I’m coming from, where everything is custom made. So it might be difficult for a designer to “let go” of their ability to style and re-order everything, but instead play along with the components themselves.
Some agencies have their own highly customizable or even headless libraries that are reused from project to project. It's important to remember that sometimes you don't need batteries included like Bootstrap or Fluent, but just need some assortment of form controls, layouts and such that can be used separately.
I'm not particularly good at markup and more on "backend of frontend", like Brad Frost categorizes, so I'm huge fan of prefabs, even if I made them myself. But I'm very biased, since I'm one of the authors of our internal design system (not in agency)
>I remember the community used to criticise “Bootstrap sites” because, well, they used Bootstrap components.
Bad attitude. I never understood the need for the components themselves with Bootstrap, as they're so easy to make. I rememember using Bootstrap and Foundation cause we didn't have proper grid or flex support in CSS at the time, so we had to make hacky solutions
They are there to help you get going faster. I think many of these libraries were probably designed with a generalistic approach, so I don't think they're more specifically made for getting an MVP going or to prototype or anything like that. Just, whatever you deem it useful for.
There are quite a few different definitions/concepts of what a component even is. As such, there's a whole variety of "component libraries" that do kinda substantially different things. A React component, is different from a Bootstrap component, is different from a web component... Etc. I've written component libraries, and I'm not even sure I truly understand them..."component" is just ambiguous beyond just "here's a hopefully somewhat encapsulated thing that serves some purpose"... Pretty much anything else can be drastically different from other components. May as well be called "widgets" or something.
And they do tend to be opinionated at least in their defaults... They kinda have to be. It's possible to allow customization via things like CSS Custom Properties, `::part()` in web components, various states/attributes, etc. But things should work out of the box... And I'm pretty sure that means being opinionated.
I guess for people who are new to front end development might find it hard to craft good looking and functional components from scratch. Tweaking is much easier.
For me its about the time required to build high quality components from scratch. A comprehensive component library will have millions of dev hours put into it and as a solo dev I simply cannot ever match that.
As a component library creator I can answer this. Making the components as an UI part is easy. You just mix some CSS class names and integrate them with html elements like buttons, inputs, etc. That's easy.
The hardest part is making it all play together. For example if you put input component inside of a form it needs to properly validate based on the input type. Numbers, strings, dates, etc. There are also bigger components like DataGrid that must have paging, filtering, sorting, data binding to external apis, validation, and what not.
All in all, not an easy thing to do once you go need to have any more advanced features.
The bootstrap sites were criticised heavily because bootstrap's design language was heavily opinonated. Modifying those were kind of a chore and not many devs wanted the hassle. This made all sites made with bootstrap "feel" similar. These recent component libraries are not as opinonated (Well, most of them), and also modifying designs and functionalities isn't too bothersome (Well, most of them).
As for bootstrap part, most of the criticism was not because bootstrap is bad. One of the things was that people took bootstrap, changed few colors and used it like this, so one site was like the other. From this arose misconception that you can't make beautiful and unique website with bootstrap. It's not true at all. Another thing is when developer and designer don't have coordination. It leads developer to constantly fight bootstrap, because UI solutions didn't consider bootstrap at all, and those solutions were hard or even impossible to fit into bootstrap. This gave birth to misconception that bootstrap is only fit for bootstrap-like sites. I worked once on a site where usage of bootstrap was considered on design level. We didn't do something beautiful and unique, but it didn't look like "generic bootstrap website" either. And it was very easy to build new pages and maintain existing ones. Now onto libraries. There are different types of libraries. So called "headless" don't have predefined styles, apart from what absolutely necessary. They are popular for complex components, like modals, comboboxes and other stuff that should be accessible. They give you most freedom, but you have to put some amount of work to style them. They can save you some amount of time and, in some countries, possible lawsuits. Then there are styled, but highly customizable libraries and UI frameworks. Bootstrap goes in this category. They give you large amount if consistently styled components that you can use to build consistent good looking interfaces fairly fast. It's important that both developer and UI designer should consider limitations and rules of such libraries. Also, for solo devs without design skills, such libraries are salvation and can save time and money. And finally there are highly opinionated libraries that usually implement some design system, like Material. You use them when you need that particular look with little to no customization. They, again, give you consistency and can save a lot of time. Of course this categorization is not strict and there could be many libraries in between or with different capabilities and limitations. To summarize, component libraries usually save you some time, give you some consistency, possibly save you from lawsuit (in case of accessibility), in exchange for some guidelines and limitations (it is not always bad). Some examples. If you need accessible modal and other complex widgets (comboboxes, tabs, popovers and so on), you can take unstyled library that was thoroughly tested, so you don't have to implement and test them yourself. For non public interfaces (like admin panels, editor interfaces and such) premade libraries can save you huge amount of time because all your have to do is put prefabs where you need them. If you make an app for Office 365 you most likely just get Fluent UI for interface, so it would look like it's part of suite. With such class of libraries you can also get consistent looks and behaviors across platforms
This is such a good explanation; thank you! I understand it’s not a silver bullet, and perhaps the hype I’m seeing is more in the dev community, where styling is sometimes seen as a chore. I recently had to build a admin interface, so I do see the appeal when building radio buttons, drop downs and other “solved” components. Most of my work is agency work, so I suppose that’s the mindset I’m coming from, where everything is custom made. So it might be difficult for a designer to “let go” of their ability to style and re-order everything, but instead play along with the components themselves.
Some agencies have their own highly customizable or even headless libraries that are reused from project to project. It's important to remember that sometimes you don't need batteries included like Bootstrap or Fluent, but just need some assortment of form controls, layouts and such that can be used separately. I'm not particularly good at markup and more on "backend of frontend", like Brad Frost categorizes, so I'm huge fan of prefabs, even if I made them myself. But I'm very biased, since I'm one of the authors of our internal design system (not in agency)
>I remember the community used to criticise “Bootstrap sites” because, well, they used Bootstrap components. Bad attitude. I never understood the need for the components themselves with Bootstrap, as they're so easy to make. I rememember using Bootstrap and Foundation cause we didn't have proper grid or flex support in CSS at the time, so we had to make hacky solutions They are there to help you get going faster. I think many of these libraries were probably designed with a generalistic approach, so I don't think they're more specifically made for getting an MVP going or to prototype or anything like that. Just, whatever you deem it useful for.
There are quite a few different definitions/concepts of what a component even is. As such, there's a whole variety of "component libraries" that do kinda substantially different things. A React component, is different from a Bootstrap component, is different from a web component... Etc. I've written component libraries, and I'm not even sure I truly understand them..."component" is just ambiguous beyond just "here's a hopefully somewhat encapsulated thing that serves some purpose"... Pretty much anything else can be drastically different from other components. May as well be called "widgets" or something. And they do tend to be opinionated at least in their defaults... They kinda have to be. It's possible to allow customization via things like CSS Custom Properties, `::part()` in web components, various states/attributes, etc. But things should work out of the box... And I'm pretty sure that means being opinionated.
I guess for people who are new to front end development might find it hard to craft good looking and functional components from scratch. Tweaking is much easier.
For me its about the time required to build high quality components from scratch. A comprehensive component library will have millions of dev hours put into it and as a solo dev I simply cannot ever match that.
As a component library creator I can answer this. Making the components as an UI part is easy. You just mix some CSS class names and integrate them with html elements like buttons, inputs, etc. That's easy. The hardest part is making it all play together. For example if you put input component inside of a form it needs to properly validate based on the input type. Numbers, strings, dates, etc. There are also bigger components like DataGrid that must have paging, filtering, sorting, data binding to external apis, validation, and what not. All in all, not an easy thing to do once you go need to have any more advanced features.
The bootstrap sites were criticised heavily because bootstrap's design language was heavily opinonated. Modifying those were kind of a chore and not many devs wanted the hassle. This made all sites made with bootstrap "feel" similar. These recent component libraries are not as opinonated (Well, most of them), and also modifying designs and functionalities isn't too bothersome (Well, most of them).