I think it's all pretty much the same deal. You might argue Vue's template syntax is closer to HTML than JSX is, but that doesn't really feel like the major issue when slowly refactoring a large application.
For example, take a rails app, then do the equivalent of $('#foo').toggle() based on some condition. In React, AFAIK you can't unless React knows what the markup being toggled is somehow. Vue can do it without knowing anything about the markup inside, and more importantly, the code will look idiomatic.
That's the kicker.
Whether a thing is possible or not is a far cry from whether it's a good idea. And when you consider what someone who opens up the code 5-7 years later without any frame of reference to start from will think (which can just as well include the original author if the original author has moved on to other things), familiar syntax goes a long way.
That's just not true, I've just finished working on a client project creating a migration scaffold between react and angular-js - like someone mentioned above, there are libraries to support communication and embedding both ways.
React doesn't depend solely on there being a stable host DOM node. It also generally assumes data is programmatically structured. Try rendering FAQs as HTML with PHP then sprinkling answer toggling functionality with React and you'll see it's not straightforward at all; it would require refactoring backend code into a REST API or similar. With vue, add v-if and you are done.
Nobody's saying vue doesn't have faults; it has plenty of them. Let's not get all fanboyish when someone points out a legit con in react.
You don't have to refactor much I think. You can inject the data into global scope in your PHP template, before you include React script. I'd do something like `window.__PAGE_DATA__ = "<?php echo json_encode($data) ?>";`.
Then, in your React code you'll be able to access it in a pretty idiomatic way for React. Instead of calling `fetch` or something similar, you'll have to call `JSON.parse(window.__PAGE_DATA__)`. You have to use `try`/`catch` block around it as well to handle errors from JSON parsing - just like you have to have the same block around `await` calls. You can treat the data as immutable to a degree as well - accidental local property updates will not get to the global scope, you'll have to set the property in `window` object.
I've used React in a few projects, embedding it into a Wordpress website using this approach. Seems to work well for me, but YMMV.
The approach you mentioned sort of works but a) it does require refactoring backend code (which by itself may already be a non-starter depending on whether you're dealing w/ a "old guard" backend tech lead, for example) b) it opens up potential security holes if implemented as you describe, c) you might lose SEO visibility and/or fail more catastrophically (i.e. a js exception might blank out the page entirely, vs merely breaking toggling), etc.
A more nitpicky code reviewer might also question the usage of babel off of a CDN if you went with a no-build JSX approach, the usage of window, etc.
By comparison, the vue snippet would be trivial, "production worthy" and it handles all the things above correctly.
I don't have a lot of experience with Vue, but I don't follow. You include Vue.js from CDN in a `script` tag, and then just add the `v-for` and `v-if` annotations to your HTML? How does Vue get the data, to properly iterate over it in `v-for` or check in `v-if`?
I'm really curious because I feel I'm missing some piece of puzzle here.
EDIT:
Previous HTML outputted by for loop in backend template:
<ul>
<li>
<h2>Question 1</h2>
<p>Answer 1</p>
</li>
<li>
<h2>Question 2</h2>
<p>Answer 2</p>
</li>
</ul>
<ul>
<li>
<h2>
<button v-on:click="expanded = 1">
Question 1
</button>
</h2>
<p v-if="expanded === 1">Answer 1</p>
</li>
<li>
<h2>
<button v-on:click="expanded = 2">
Question 2
</button>
</h2>
<p v-if="expanded === 2">Answer 2</p>
</li>
</ul>The argument here is that there is a substantial difference of effort required for a specific subset of project types (migrations from large non-SPA).
And for the record, all the vdom libs I mentioned are on the same boat as react, because it's an inherent trait of vdom based architectures.
I'm the author of one of them, and while I can't speak about others, I can say that I was ok with requiring simultaneous migrations from server rendered templates to REST APIs for scratching my itch, even though I was aware of DOM-first systems (angular 1, knockout, vue and intercooler are examples of those)
Contrary to popular belief, a framework is not required to be perfectly suitable for every scenario under the sun. And that's fine, nobody needs to get all defensive over it.
Vue has similar hydration capabilities as Angular, but with React, you are pretty much forced to describe the view from scratch in JSX. To make things more fun, many islands need to be aware of each other, something that is not super idiomatic in React land.
Just some food for thought.