I have the same point of view. Take the best of both worlds. :) I love the cdk, and material and bootstrap too. Most of the times I can't decide the style (Bootstrap/Material) of our new project, but under the hood I use both. I have a project, where I hacked the MatTab to look like a bootstrap tab but still have all the functions MatTab has :) I like the mobile first world view, and it makes me sad, that the material team did not take this path too. :/
Just saw this speech and I am speechless... Google spent millions on their Material Design and this guy want's to mash it with Bootstrap just to make things look beautiful? Beauty is just a tiny part of UI design....
Hi Amadou, we just have this discussion in our project. So your speech is very helpful. But what I don't fully understood is the maintainability at the end. How do I get rid of my CSS classes when removing HTML? Is there a blog or something that explains it?
When using utility-css approaches, we are often assuming that the utility classes we have are used in many places in our markup, so removing some markup wouldn't leave us with utility classes that are no longer used. We are assuming our app uses a consistent design system, independent of the exact components and content that design system is being applied to. This post by Adam Wathan does a great job explaining that there are two sides of a spectrum - HTML dependent CSS and CSS dependent HTML. Utility CSS is HTML dependent on CSS. adamwathan.me/css-utility-classes-and-separation-of-concerns/ It might be the case that when you remove a component, you are left with utility classes that aren't being used in your app and this can be analogous to JavaScript from libraries that can't be tree shaken despite not being used in your app. There are solutions to this problem (namely PurgeCSS www.purgecss.com/ which is often used with TailwindCSS), but it's not as big of a problem as you might think if your app is the type that we are assuming it is when adopting utility css.