React uses an imperative style, not declarative - when one uses this.items.map(item => <li>{item.name}</li>), this is imperative, not declarative. You are describing the DOM with imperative language - JSX cloaks what is truly an imperative nature. This is made more clear with the non-JSX equivalent. When one uses an if else-if else, while, switch, or other similar control flow statements, one departs from describing, to imparting the details of the implementation. The only part declarative about JSX is the conversion of certain code into valid text/attribute values/etc. into the HTML, which I'd hope is a minimum requirement of a useful templating language.
Angular's templating is clearly declarative since one is not making a statement about how it arrives at its result, but purely describing it and leaving the implementation elsewhere. Something like <ul><li *ng-for="#item of items">{{item.name}}</li></ul> leaves the iteration implementation away from the view completely. Every piece here is descriptive, not something more.
It should be noted that Angular 2's DOM model uses an AST under the hood, just like React - fundamentally they are the same in the virtualization of the DOM. Angular 2's templates are not true HTML either, but is closer to HTML than React is in its syntax. It does limit what you can do, but that is the purpose of templating languages - it limits what you can do to increase readability, increase consistent patterns, and steer users away from dangerous usage. That is an argument aside from declarative vs. imperative templating, and more emotional than useful.
Now, both approaches have obvious flaws - both styles are easily (and often) abused, but both also have simple conventions to keep it clean. Imperative construction (ala React) requires one to carefully organize the control flow to avoid convoluted template construction. Declarative construction (ala Angular 1 + 2) requires one to avoid tossing too much in a singular template. What is easier to work with, that is not for me to say as an absolute, but IMO carefully organizing the control flow in template construction requires more mental overhead to avoid constructing the template in a hard to read fashion, and yet still involves the same ultimate basic strategy of having to create separate components to avoid overly complex templates, which is what one has to do with declarative template languages, but without the mental overhead of accidentally abusing control flow in its construction.
Defining UI as a functional map of the state is the one of the most declarative ways of viewing the problem, IMO. Templates are maps too. The problem with templates, historically, is that they've been used only for the initial state, and abandoned for later changes because rerendering is expensive.
Code written in language that allows imperative constructs != imperative code
I would say that React is far more friendly to a declarative style than Angular 1 at least. Immutable data, redux, and virtual dom all encourage this style, whereas the path of least resistance in Angular 1 is definitely imperative mutation of state. Anyway, if you're doing significant amounts of logic in your JSX/angular templates, you're Doing It Wrong.
Unfortunately, the declarative style of programming might not be exactly what you seem to think it is. Take a look at the Wikipedia page for declarative programming: https://en.wikipedia.org/wiki/Declarative_programming
"Although pure functional languages are non-imperative, they often provide a facility for describing the effect of a function as a series of steps."
"While functional languages typically do appear to specify "how", a compiler for a purely functional programming language is free to extensively rewrite the operational behavior of a function, so long as the same result is returned for the same inputs. This can be used to, for example, make a function compute its result in parallel, or to perform substantial optimizations (such as deforestation) that a compiler may not be able to safely apply to a language with side effects."
Pure functional mappings is one of the textbook examples of declarative programming. It might look like you're specifying steps to get some result in the code, but that's the wrong conceptual model. You're actually specifying the resulting data you want as a set of functional transformations on top of some initial data. Exactly how the program arrives at that resulting data from the initial data (recursion/loops/inlining/whatever else) is up to the language runtime/compiler, and not something that functional programmers needs to worry about, thus why it's declarative and not imperative.
React and Angular's approaches to templating are both declarative. React's approach simply offers more expressive power by allowing the whole set of functional transformations in the JS language rather than some artificially limited subset. React's approach also allows for this declarative approach to extend to the entire application architecture by modeling entire apps as pure functional mappings between state and UI.
UPDATE:
> When one uses an if else-if else, while, switch, or other similar control flow statements, one departs from describing, to imparting the details of the implementation. The only part declarative about JSX is the conversion of certain code into valid text/attribute values/etc. into the HTML, which I'd hope is a minimum requirement of a useful templating language.
This hints to a bit of a misunderstanding of what exactly JSX is. Control flow statements are not valid JSX code precisely because JSX is a purely declarative description of UI. [1]
Angular's templating is clearly declarative since one is not making a statement about how it arrives at its result, but purely describing it and leaving the implementation elsewhere. Something like <ul><li *ng-for="#item of items">{{item.name}}</li></ul> leaves the iteration implementation away from the view completely. Every piece here is descriptive, not something more.
It should be noted that Angular 2's DOM model uses an AST under the hood, just like React - fundamentally they are the same in the virtualization of the DOM. Angular 2's templates are not true HTML either, but is closer to HTML than React is in its syntax. It does limit what you can do, but that is the purpose of templating languages - it limits what you can do to increase readability, increase consistent patterns, and steer users away from dangerous usage. That is an argument aside from declarative vs. imperative templating, and more emotional than useful.
Now, both approaches have obvious flaws - both styles are easily (and often) abused, but both also have simple conventions to keep it clean. Imperative construction (ala React) requires one to carefully organize the control flow to avoid convoluted template construction. Declarative construction (ala Angular 1 + 2) requires one to avoid tossing too much in a singular template. What is easier to work with, that is not for me to say as an absolute, but IMO carefully organizing the control flow in template construction requires more mental overhead to avoid constructing the template in a hard to read fashion, and yet still involves the same ultimate basic strategy of having to create separate components to avoid overly complex templates, which is what one has to do with declarative template languages, but without the mental overhead of accidentally abusing control flow in its construction.