> The "tons of libraries" argument doesn't make tons of sense either. It absolutely does make sense. How many "class builders" have been written in the JS comm

> The "tons of libraries" argument doesn't make tons of sense either. It absolutely does make sense. How many "class builders" have been written in the JS community since ES6 got classes ? That's right. Now you don't have to rely on co/thunk and what not to write readable async logic. Promises are still callbacks wrapped in objects. Now the consumer of a function that returns a promise doesn't have to deal directly with the promise anymore. This feature is something JS should have had a long time ago, no question. > This feels like a step toward added confusion rather than language unity. Things like prototypical inheritance are the biggest source of confusion, along with "this" behavior. > beneath native abstractions The correct terminology here would be syntactic sugar. Look you might not like this, but what is better ? community fragmentation with transpilers and what not, or a single language that answers most of the needs of the community ? libraries that handle complex abstractions or documented syntax that allows getting rid of these poorly documented and poorly maintained libraries? I don't want to use generators to mimic corroutines and depend on co/thunkify to write readable async code. I don't want to use 3rd party language X or Z that will get me the syntax I want, I want everybody to use the same language without obscure patterns.