Regular non-ui programming is different from ui one. In a regular straightforward program you apply a change and read it back only when it is needed. Even if t

Regular non-ui programming is different from ui one. In a regular straightforward program you apply a change and read it back only when it is needed. Even if that change is cached/computed/transformed/etc, there is only need to observe it when your program execution comes to that part. In a ui program after doing a change you have to somehow update all the relevant elements/controls that are currently visible on a screen, i.e. replicate the whole state of a program into a graphical context at once (regardless if html or not). This process has associated costs and is pretty error-prone if not addressed systemically. All these frameworks spin around some idea of optimization of it. Since it can't be done without tradeoffs, they invent new ways of thinking about a problem, offloading parts of it via methodological contracts to a developer, who pays their half of the price. Different developers have different opinions on how high the price should be and which trade-offs they should take. Is it worth it? Sometimes yes, sometimes not really. In my opinion, ideas behind some frameworks are useful by themselves, but in general all this tends to become more religious rather than technical. E.g. if you weigh what "cost" is or how error-prone the straightforward approach is, you may find that for some cases it doesn't really matter.