I can agree with you about steering clear of such a large boilerplate setup-- especially if you don't understand everything baked in. But can you explain why you would choose Mithril of Cycle.js over React?

I've been building production apps with React for about a year but at a glance I can't really see any clear advantages in Mithril or Cycle.js

I can speak to Cycle, at least. The big deal for Cycle is that it is reactive programming using RxJS. RxJS provides a standardized (and cross-language [1]) "standard language" of working with reactive flows. It's very nice to have a reusable "toolbox" like RxJS and knowing that the skills you put into using it transfer to just about any other language you might want to use (and vice versa, I first used RX in C#). While there are RxJS integrations into React, the benefit to Cycle is that in presuming (and building explicitly on top of) RxJS it ends up being a relatively small "glue library" and a set of documented conventions for RX observables ("event streams"), more than a complicated chunk of "framework code".

[1] http://reactivex.io

Interesting. I'm a fan of reactive programming and I've built projects using react+bacon.js and found that they worked well together. I'll have to give cycle a try on a hobby project sometime.

Unfortunately I'm shoe horned into react for my client work. The majority of my projects are handed off to the client to maintain and React is sort of a selling point (because.. you know facebook uses it and all). I'm afraid I can't realistically sell Cycle.js at this point.

Yeah, I definitely understand the salesmanship "follow the other lemmings" aspect of things. If it helps, I've found that I can sell "This project should use RX for all of these good reasons and its a growing industry standard supported by companies like Microsoft and Netflix..." and if I need to mention Cycle at all directly, pointing out Cycle is just the handy "glue" to bind RxJS to a Virtual DOM similar to Facebook's React...