I found the presentation really interesting.If I had to give a slightly larger TLDR the two main points I got from it were
1) In a virtual DOM system your view code is a black box, while in an observable-based system you need a way to specify all the data bindings. This means that virtual DOM systems can use usual Javascript abstractions (functions, varuiables, etc) where observable systems often need custom DSLs (for templating, data-binding, etc). Additionally, data binding can be tricky to get right when it gets more complicated, for example, if you have a sorted list of items it needs a way to know that should be rerendered when the inner properties change.
2) Performance: in a observable-based system, the memory and CPU costs are related to the size of the model while in a virtual DOM system the costs are related to the size of the view. This can be a performance gain for the virtual DOM if you have a big model but use windowing to display only part of it. Also, the O(n) cost on the size of the view is usually not a problem since views tend to be small enough that that fits inside one repaint frame.
In that context, data binding means that you observe the model and set up a data flow so that you only need to update the specific parts of the view when the model changes. JSX doesn't do that as all it does is render the view. You need to detect and trigger repaints separately and when that happens it will blindly redraw everything instead of just updating the relevant DOM nodes.
Also, JSX is a relatively lightweight wrapper that uses native JS constructs for looping and subroutines. This is in contrast to things like Angular where the templating system has its own way of scoping variables, abstracting out subtemplates, looping over arrays, doing conditionals, etc. Angular must use these special DSLs and abstraction mechanisms because there is no way to do full data binding with just plain old Javascript code.
1) In a virtual DOM system your view code is a black box, while in an observable-based system you need a way to specify all the data bindings. This means that virtual DOM systems can use usual Javascript abstractions (functions, varuiables, etc) where observable systems often need custom DSLs (for templating, data-binding, etc). Additionally, data binding can be tricky to get right when it gets more complicated, for example, if you have a sorted list of items it needs a way to know that should be rerendered when the inner properties change.
2) Performance: in a observable-based system, the memory and CPU costs are related to the size of the model while in a virtual DOM system the costs are related to the size of the view. This can be a performance gain for the virtual DOM if you have a big model but use windowing to display only part of it. Also, the O(n) cost on the size of the view is usually not a problem since views tend to be small enough that that fits inside one repaint frame.