He points back to static typing, but honestly I think UI code is harder to keep organized than service code (which I presume is what the Haskell backend does).

He points back to static typing, but honestly I think UI code is harder to keep organized than service code (which I presume is what the Haskell backend does). Usually it's the UI that has to swallow the biggest chunk of the mismatch between the programming model and the user model – and as you move to smarter clients like you would with Ember.js, you end up pushing nearly all of that to the client. And you have to start interfacing with substantial complicated pieces of code, like the browser, code that every UI has to not just use, but negotiate with. All this complexity can be a way of coping with this system – not just coping with the system of a dynamically typed language, but all the many conflicting constraints in a browser environment implementing a UI for real people. That said, there are differing opinions on which part you should "simplify" through a framework. Some of them are going to feel more magical than others. And when you come in with preconceptions about what makes a good environment, you're going to think about how the framework and environment lives up to your ideal. Some things you fix, some you leave as they are – and choosing the right battles is incredibly important. But service code and UI code are different sorts of warfare against complexity, I'd be skeptical of intuitions across the two domains. (None of which means Ember.js gets it right either – but if they don't, then I doubt the why is they just need a statically typed language.)