[dragonwriter]

How does using associative arrays reduce the need for non-trivial getters and setters? I see how it provides an alternative to trivial getter and setter pairs; just as using bare public data fields in a language that supports them does, but non-trivial or non-paired (getter or setter alone) or different visibility ones seem to be a different issue.

[virmundi]

My belief is that in a functional language like JS, you shouldn't couple data with operations on itself. As a result, all you'd ever have is non-trivial getters and setters. You see this with map like constructs in Erlang. You'd have a function that takes a map and does stuff.

[Joeri]

Systems built with large teams need to have their developers negotiate API boundaries. Strict typing and intelligent getters/setters help a great deal to achieve this because the code becomes self-negotiating. A second problem with large teams is that most programmers can't write pure functional code, turning the codebase into a hybrid mess. ES6 matters most for large teams because the inefficiencies of ES5 are felt most on those kinds of scale.

I'm also doubtful how well DOM programming can be mixed with a functional approach, but i'll concede that it is at a minimum possible to do it.

[dragonwriter]

I don't think it's true that most programmers can't write pure functional code; I think it is more the case that that most programming languages don't provide good support -- particularly constructs that make the distinction between pure and impure code clear -- for programmers who wish to write pure functional code or at least to cleanly segregate pure and impure code.