First, Vue has only a few simple rules and paradigms to learn. The templating language feels and works natural but is still very powerful. It is as close to pure javascript as templating can get. All the other logic that supports the rendering (state, computed properties, event handlers (methods) and component properties) are easy to understand and integrate. However, what makes vuejs so special is also that you are still in full control, while serving a very good standard. You don't have to set up code splitting, routing, transpilation, service worker etc. With Vue-Cli you can choose from many presets that suit your requirements, or easily integrate your own plugin. I recently organized a lightning talk about how vue helps in making the right decisions: https://slides.com/martinmuzatko-1/composing-modern-uis#/

As backend developer, it is hard to think about the many little details that make the UI the UI. It is a different context and style of development compared to backend development. CSS (classes) can be re-used in a different way than backend classes and functions. But coming from a background where always both was needed: back and front-end work, I cannot really tell what feels easier. I think both sides have their own quirks.

I get what problems BEM is trying to solve, but to be honest, you don't need BEM if you understand CSS specificity, and you design your app properly. Wow, there are so many misunderstandings in your comment, that I would love to educate you on this subject. You should listen to your developers a little more about their reasoning with BEM or anything they would like to introduce to make extending the codebase easier. Adopting a naming convention or any css architecture is better than none! Semantic UI is chaos for scoping reasons. You could use card red and red would mean something different in this scope, if I mix it with another class. It could mean red background there, and on input red it would mean red outline. Is this any better to search the code base? I need to search for the context of the main class here. I need to know the scope and context of the class to know and follow how it is going to work. It is pretty foolish to assume that anyone other than the author can understand the complexity of selectors that build up and overwrite each other. BEM is a convention to bring sanity to this, so developers do not have to overwrite each other and css class tooling is way more concise. I myself have been there. In a recent larger scale project, we thought we were smart using advanced selectors like .card h2:first-child to define that a heading in that card should not have a margin-top . Soon we had to wrap the h2 because it has been part of another sub component, and our rule was broken. So we tried to add more complexity: .card > div > h2:first-child . And if they needed h3? .card { > div { h2,h3,h4 { &:first-child{ margin-top: 0}}} With growing content author demands, we had to extend and extend and add more unnecessary rules. Until we introduced BEM to mark up something as card__heading . The relation is clear, the usage is clear, and mixing with other helper classes is easier. horribly-bloated markup ridiculous amounts of repetition within component Is this any better? ui top left massive attached purple label Instead I would group common styles as label label--primary . This is also what tailwind.css suggests: https://tailwindcss.com/docs/what-is-tailwind/#component-friendly unsearchable CSS source HTML markup is class="foo__bar--baz" CSS markup is .foo { &__bar { &--baz What kind of CSS architecture do you have? Do you put everything in one file? shouldn't you have your css components have their own css files? So if I see something like card card__heading card__heading--highlighted I would look for a card.scss or card.less file. and look for heading there. inability to use class names as content switches from JavaScript Why should this not be possible? Can you please elaborate why this should be not possible with BEM? In Vue, you can easily add a class like card--highlighted . Classes are just one of multiple selectors available. However, they have no such significance above that, and arguing to use them "because they are classes" is showing either a limited understanding of CSS or possibly worse, ingrained / habitual thinking. I would not use IDs because you can't mix different IDs together. so <div id="this that"> is not possible . IDs are meant for use with anchors only. I don't even use ids for javascript hooks anymore, because I want my js to be re-usable. So I either use attributes <div hide-delay="5"> or re-usable classes. <div class="js-hide" data-hide-delay="5"> . Lastly: I am said technical director and firstly I'd like to thank Joe for garnering external opinion, it's a big guy who puts himself at risk of potentially being pointed out to be wrong! It is part of a growing mindset to be not afraid of being wrong. We are here to learn and our journey never stops. It is extremely important that developers invest time in learning how to better architect a project. Which they can't do if they do not ask questions. You act like a developer asking questions is stupid. The opposite is the case. If you never ask questions and never dare to look beyond your horizon, how should you become better at something? Please listen to your developers. They care. They probably have to deal a lot more often with the codebase than you have to. Let them make the decisions for something they have to deal with every day. Best, Martin

We use flexproperties (https://www.npmjs.com/package/flexproperties), which uses attributes to define layouts. e.g. <div layout="row" layout-align="space-between"></div> I used this on many projects so far and it works better with responsive design, than cluttering the classes with modifiers. I used this approach in k15t.com, help.k15t.com and my personal project happy-css.com with great success.

I have never attended any of the courses offered by treehouse or anything like that. Official docs + a few handpicked news platforms (echojs, smashing, webappers, alistapart) to keep on track.