People have to stop conflating the concept of OOP with that of encapsulation. No one is arguing the value of encapsulated black boxes. Any good paradigm will have that concept! The question is, do you want OO-style black boxes, or functional style black boxes (ML-style modules or Haskell-style type classes)?
Functional style encapsulation is a really good contender for handling UIs, especially given the ease of use of first-class functions, and especially especially reactive programming frameworks.
The inheritance mode is natural to OO for the UI. It flows quite well and helps provide reuse of components by slighly mutating that component into new functionality. Lets take select box --> FilteringSelectBox, I reuse the select box and extend it by adding a method that captures user input runs a match on the internal data store and overrides the display to only display results that are within the partial entered text. With the addition of a method and the overriding of a display method I have created novel functionality. This is harder to reproduce in a purely procedural language.
I have been around for a while and used about all of them and I have never seen the efficiency that OO provides for UI in a non OO language.
For instance in OO I can encapsulate all functionality related to a pop up with that pop-up, so it can have a member variable of content, while also providing a show and hide method. The strong point of OO is that is is easy to encapsulate the data with the functionality (In most cases this is a bad thing but in UI, you are at the end of the rode the functionality and the data start to merge to present it to a human) and scope it so to decide the scope of that dialog, I can create and instance of that dialog and call show on that dialog, it will show that instance of the dialog.
Whereas, if I want that dialog to be a singleton and only share the reference among functionality to guarantee that there is only one true dialog, I can also do that.
Representing a black box like that in functional languages can be done, I am not saying that it cannot. I just have never seen that it is as clean as OO. Now in saying that, languages are subjective. What may be clear to me could seem obtuse to someone else.
For me though Object encapsulation and inheritance model (or mix-in / Interface) makes it far easier to slightly adapt code and make it behave well for The UI. The only other place that I have realized the benefit of OO, was in AI development. In my time as an AI developer, I can not see how we could have realized the systems that we did without OO.
Outside of those realms and a few other problem domains I question the value of OO and it's benefits are marginal at best. Structures handle everything that is needed in a great percentage of places. Though it would be nice to be able to apply Interfaces to structures.
"Functional style encapsulation is a really good contender for handling UIs, especially given the ease of use of first-class functions, and especially especially reactive programming frameworks."
I don't think you can convince me that dumping OO entirely from the UI is going to be a step forward. There is a place for procedural work-flow (I call it a page controller for web) in the UI.
That is why in my original post I was arguing for JavaScript it is actually the perfect language for UI development. It was not created by accident it directly strikes at the heart of the problem.The problem is that the browser implementation until recently have been abominable and used incorrectly it can create a mess. But the basic tenants of the language are sound.
Functional style encapsulation is a really good contender for handling UIs, especially given the ease of use of first-class functions, and especially especially reactive programming frameworks.