Can anyone please explain what a "declarative API" is, and why that is better than an imperative? He claims this is the best part of the framework, but I'm just left with a big "what?" since I don't understand what the hell that sentence means.
I mean he admits he had to build a bunch of products before he understood the concept, but didn't waste a single slide to explain it in the presentation.
The briefest explanation is that imperative is a list of instructions describing how you want something done. A declarative approach describes what you want done.
The typical example for this is SQL - you don't tell an SQL database how to run a query, you tell it what you want, and it figures it out.
In Reacts case, you describe your application in terms of components that know how to render themselves given different sets of data, or states. When the application state changes, the entire application is re-rendered. The "magic" of React is that the use of a virtual dom to create an efficient diff from the current dom state to the new dom state allows this to be very performant, ensuring a minimum of actual dom changes are made.
The resulting components are much, much easier to reason about. You can see, looking at the code, exactly how the component will behave given different data. In essence, what you see is what you get. This is a far better dev experience than working with components that can be mutated by events; you need to build a mental model of all the various states that the component could find itself in.
I was driven to this approach using Backbone to tame a particularly complex interface, similar in complexity to the ads example shown in the video. But as mentioned, doing this naively (in this case, re-rendering a backbone template instead of mutating it), leads to all kinds of user interface glitches. React smooths over those glitches.
I mean he admits he had to build a bunch of products before he understood the concept, but didn't waste a single slide to explain it in the presentation.