You get plenty of magic traceability :) Check out redux. You get it in vanilla Flux if you use immutable data. I would also suggest using React for a toy project to learn more about it. The "pure"ity of the render function means you can trace the state of the DOM directly to a Javascript object (declarative), which was the point of the article's example. Your "down the road" code is imperative, as in someone changes the DOM independent of the state of your data.
You're not converting between data structures in your example, you're mutating a stateful system. Moreover, I'd rather leverage a library so that I don't have to manually do everything myself.
I couldn't work out what point you're making in this response, sorry.
I was referring to the claim that React is declarative. Not my code.
Things aren't declarative magically. A declarative system is one where you declare a data structure, and you feed it to a separate bit of imperative code that operates on that declaration. In react's code, the 'declaration' is a set of HTML templates and the 'operation' is to create a corresponding DOM.
> you're mutating a stateful system
Both approaches do. React mutates state too.
> Moreover, I'd rather leverage a library
Good for you.
For some things React is a big time saving. But for many things it is a waste of bandwidth, a waste of development time and a waste of programmer education. Just like any library that isn't required. Using libraries is not free.
If you want the kinds of benefits the post highlights, you can get them much cheaper with a few lines of code. If you want to import a full library to save a few lines of code, that's your prerogative, of course.
React shines when you need a templating system and you can benefit from the performance of a virtual DOM. If you want a basic virtual DOM, then you can do it very easily yourself (a few lines of code in the simplest case), but as things get more complex, it becomes a better tradeoff in favour of React. If you want a comprehensive system, React becomes a very useful tool, one I rely on myself. But it is important to understand what you need and why. If you don't need a virtual DOM, then using React seems pretty foolish, to me.
Javascript is full of frameworks, and full of programmers who use them without knowing what they're for.
React encourages declarative usage. You declare some data and how it will be rendered in JSX templates, and React does its thing. As a consumer of a library I shouldn't have to care about what goes on under the hood, as long as I know the API and its proper usage.
> Both approaches do. React mutates state too.
Right, but I don't have to concern myself with the stateful system (the DOM). I can delegate that responsibility to React.
As to your other points, I agree that people should put more thought into their selection of tools.
