> fairly reasonable I can't say I agree. I had a miserable time going from 3 to 4 because it also dropped Less support. Most of the blame goes to css but I do

> fairly reasonable I can't say I agree. I had a miserable time going from 3 to 4 because it also dropped Less support. Most of the blame goes to css but I do not welcome churn on a library like this. With a strongly typed API, most of the breaking changes cause errors so you can just go through and fix them. With code then you can also cover behaviour regressions with unit tests. With css / bootstrap, you get zero errors, just a broken visual layout. You get a lengthy migration guide https://getbootstrap.com/docs/4.4/migration/ https://getbootstrap.com/docs/4.4/migration/ that you have to manually go through line by line, searching the codebase for each affected feature. The affected features are not single css classes but how multiple different css classes interact in hierarchies with changing requirements on the DOM structure. Fixes don't just mean updating the css but changing the DOM too. So much for css separating appearance from content. Some of the breaking changes are things like changing fundamental default sizes of things like fonts or media-queries which for a given site are not things you can change willy nilly so if you need to preserve the existing appearance you now need to rewrite very basic things and decide how much pain you going to through by fighting Bootstrap's changed defaults. You only know you are actually done by looking at the appearance of every part of the site, on all the relevant devices, in all the relevant conditions so that each media query triggers. Ugh, it's a nightmare.