I prefer Mithril.js, used from TypeScript, with Tachyons for inline-ish CSS. That is what I use when I have a choice like for personal projects that are single-page applications (e.g. StoryHarp, NarraFirma, Twirlip7 on github). That way almost all code is in one language and can be easily refactored. Mithril is most naturally used via a "HyperScript" API where you define DOM/vdom nodes via function calls -- e.g. m("div.ba.bw2", m("span.blue", "Hello World")). Templating systems (including JSX for React) are unfortunate crutches which ultimately make development harder because they get in the way of refactoring, modularizing, and testing. And typical semantic CSS use (e.g. .warning vs. .red) often ends up in a messy snowball where people eventually are too afraid to remove anything -- whereas if you make your components in JavaScript code, you don't need semantic CSS. It turns out that "best practices" for server-driven Web 1.0 applications (e.g. HTML-ish templates and semantic CSS) often are "worst practices" for JavaScript-first single-page applications.<p>React also is overly complex because it tries to over-optimize redrawing speed through encouraging components to maintain a lot of local state using setState -- even though the increasingly popular Flux model encourages global-ish state for one-way data flow that makes the internal workings of UIs easier to reason about. Mithril is more Flux-ish out of the box in terms of the design patterns it encourages. Mithril's default behavior is based on rerendering the entire current vdom tree any time the user interacts with a DOM element or after a network request completes -- and the Mithril community only encourages optimizing beyond that if there is a specific performance issue. (You need to add your own redraw calls in callbacks for timeouts and a few other cases.)<p>That said, I can understand how the herd mentality shapes the employment landscape for both programmers and their managers. It does in my own work life too -- where I have spent a couple of years working in Angular for my day job despite knowing what a mess of accidental complexity it is compared to something like Mithril. Angular was chosen years ago by other developers before I joined the project -- developers who mostly did not stick around to suffer the maintenance consequences. At least new projects may be in something other than Angular -- typically React (which is at least better than Angular).<p>It's saddening how many times in my career I've ended up having to work with worse technology because of herd effects -- despite knowing better alternatives existed and having personal experience with them. For example, IBM chose to promote Java instead of Smalltalk in the late 1990s (despite having two Smalltalks it owned). Or Netscape ultimately foisted a Java-ish looking JavaScript on the world when Brendan Eich was originally recruited with the promise he could write a Scheme for the browser. Although, as with both Java and JavaScript, after a couple of decades, most of the worst rough edges are worn smoother and many of the worst bugs are fixed, and so the developer experience for both by now is finally not that bad.