1) I don't see a problem with this. If you have stale state, but no one sees it, who cares? Same thing regarding cleaning it up, if no one notices when, who car

1) I don't see a problem with this. If you have stale state, but no one sees it, who cares? Same thing regarding cleaning it up, if no one notices when, who cares? The great thing about storing all the data in a top-level datastructure is that you could dump that entire thing into JSON, send it along in bug reports, and then you can see the same state the application was in when a bug happened. This is gold! 2) In my experience, with typescript/javascript you instead get to deal with the fact that in the same period of time the API for webpack has changed, the api for react-router has changed twice, etc. Slow is not necessarily bad, especially considering the reason things are slow is because of the focus on doing things right. Also, just because you can't escape a tiny amount of javascript, having the rest of the application in Elm isn't worth it? How strange. 3) I admit that it sometimes is a bit annoying that you can't get things like the current time --right now--, and instead have to thread that through the update chain. But overall I find this to be a good thing. It's great when learning new code bases to easily identify where side-effects can happen just by looking at the type signature. > Also, there is always "just one way to do this or that... As a power user, this is the best thing about Elm. The fact that javascript isn't like this, is why I never want to maintain another javascript project that I didn't personally create, ever again. > You can tell Elm is still a beta product; Elm is a alpha product, so this is really a great compliment.