While I like the concept of SAM, I don't see many designers really embracing writing their html in js functions. It's awkward and still relies on their ability to read/understand the code to make sure it's fitting in the right areas.

Fair point, I'd like to see how we can rebalance the workflow between the designer(s), front-end and back-end devs. With Framework like React and Angular, the center of gravity of all decisions is at the Front-End ("can't implement your design, sorry" or "don't care what you think that API should be or whatever you want me to reuse, here is the one I want"

I felt that giving them back some control would be enough to convince them to write these functions.

I am cross-posting some of the discussion I had in the ngrx/core room@jdubrayWhen you compare Redux with SAM, the arguments boils down that in Redux, when you write this kind of code:

caseINCREMENT:
return state + 1;

the reducer is coupling the action itself: counter += 1 which adds one to a given valueand state.counter = counter which assigns a value to the counter property.All I am suggesting with SAM is to take the action logic outside the reducer, the reducer keeping its core role to mutate state. The same "reducer" logic could work just as well with different actions (incrementByN).

I am not quite sure anyone would see this kind of factoring in the context of mutating state as a bad idea