More like trying to explain to people who have only done imperative programming (and that also in JS of all languages) why a render function was necessary. The creator of React, Jordan Walke, was big into OCaml and one might even say he got some of the ideas of React through working in OCaml, so much so that he tried to bridge both by making ReasonML which is an alternative syntax for OCaml which has JSX and React bindings.
Yeah, there's a lot of people who have either forgotten or never knew that the context React came into was a world full of JQuery and AngularJS two-way bindings. I started my internet touching career having to work on that stuff, and boy, so much of it was a nightmare that just got endless workarounds heaped on top for basic performance issues, let alone other complications.
> More like trying to explain to people who have only done imperative programming (and that also in JS of all languages) why a render function was necessary.
It doesn't seem all that different from doing your rendering in the WM_PAINT handler, which was already how things were done in the ancient Win32 API (although it's possible [0] to draw outside WM_PAINT).
The web root is a document platform. Every major GUI library have a “paint” or “draw” function you have to overload for custom widgets. And there is always mostly two kind of widgets: actual visible components and others that are responsible for layouts.
More like trying to explain to people who have only done imperative programming (and that also in JS of all languages) why a render function was necessary. The creator of React, Jordan Walke, was big into OCaml and one might even say he got some of the ideas of React through working in OCaml, so much so that he tried to bridge both by making ReasonML which is an alternative syntax for OCaml which has JSX and React bindings.