Now I can compare Erlang to Java and it is really baffling how the heck Java took over the world. To do erlang I just need an editor with some plugins, ssh connection to linux with OTP installed and of course rebar3. To do Java I need 4GB of RAM to simply run an IDE with gazillion of plugins, maven to cater for thousands of dependencies for the simplest app and I need to know Spring, Hibernate, AOP, MVC and quite a chunk of other 26^3 3-letter abbreviations. No thanks.
> Build encapsulated components that manage their own state, then compose them to make complex UIs.
Components managing their own state is a textbook definition of OOP. They even use inheritance in their example on the main page:
> class HelloMessage extends React.Component
For the React that I write, class components are used only when there's some trivial local state that I don't want to put into Redux (e.g. button hovering that can't be done in CSS), or when I need to use component lifecycle methods.
And yes, class components do inherit from React.Component, but they specifically discourage creating your own component base classes.
I don't do web development but I've read react API docs and user guides.
Objects calling other objects is optional for OOP, I never saw a definition that requires them to do. OOP is about code and data organization.
Objects and methods are everywhere in react. Some are very complex.
Just because it uses a few lambdas doesn't mean it's not OOP.
For reference, here's now a non-OOP GUI library may look like: http://behindthepixels.io/IMGUI/ As you see not only it's hard to use, it doesn't scale.
Like it or not, OOP is the only way to deal with complex state invented so far. Even in functional languages: https://medium.com/@gaperton/let-me-start-from-the-less-obvi... And modern rich GUIs have very complex state.
Smalltalk, which is the prototypical OO language, does the exact opposite of everything you said (all computations happen by message passing and all members are public).
No it doesn’t.
> all computations happen by message passing
I did not say message passing is required to be not present, I said it’s optional.
> and all members are public
I did not say anything about encapsulation. I said OO is about organization of code and data. If you have classes with properties and methods, it’s OOP.
Have a look at functional reactive programming.
Re "The model is a data structure and the view is a series of functions on it." This is exactly how I see my OO-based GUI programs. The object I define is firstly a data structure. Then I want some operations/views on it? define methods on it.
Now I see OO as something I have to deal with, like a tiger in my living room. Thankfully, so many new languages have come out recently; Go, Rust, and Elixir being the ones that I use regularly, that have called out OO for what it is and have gone in more compelling directions.
Hopefully one day they will teach OO alongside other schools of thought, as a relatively small faction of programming paradigms.