Seems like they should try more marketing and community outreach toward that end.
Gradual adoption is a feature / selling point not many web development frameworks can claim.
For instance, I work on an app that was originally written in Backbone / Marionette, but I was able to write generic connectors to allow us to drop in React at any point in the tree. Similarly, we can go back to Marionette / Backbone at any point in the tree. It's made gradually migration towards React possible.
Claiming React can't do the same sort of sprucing up as Vue is just a lack of imagination. Show me an old app, and I'll show you how to do 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.
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.
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.
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.
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>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.
I think this exact capability is what led to such strong React adoption. It's almost viral within an application. The main application that I worked on a few years ago was on Backbone / Marionette and we evaluated React by writing several small but complicated nested components, with state controlled by existing mechanisms. After liking both the flux application architecture and the ease of gradual transition, we pulled the trigger on React. It slowly ate our application from the inside out, but never forced our hand.
React isn't "lightweight" (JSX being the primary hurdle), but it is very easy to adopt incrementally!
I find it the other way. Vue has a big learning curve. Learning their special directives and double binding gotchas takes a while.
While jsx is a very thin layer for existing Js. All control flow is good ol js. The tags just translate to createElement/h calls. React (class based React) was easy to pick up.
I also think other folks in this thread are referring to mounting on existing DOM in jQuery-esque use cases.
People will respond saying you "can do this with React, too". But in practice it's not nearly as nice to do as with Vue. You need React and React DOM AND JSX to really make it practical; writing React render functions is not really what you want to do when you are adding some simple functionality to an existing web app (like form validation).
If all you are doing is adding a simple form validation to an existing web app, then you only need few lines of plain JS. You don't have to use vue either.
Meanwhile the web development team are still fighting with the flagship "all-or-nothing" angular app, still stuck on 1.7 because anything else is an entire rewrite.
what you're responding to is marketing, which Vue has done an effective job of. thats fine, but it is unfair of you to conclude "Gradual adoption is a feature / selling point not many web development frameworks can claim."
While it isn't pretty, you can drop Vue in a <script> tag on a page and define components with template strings.
In React, you can technically do this, but you need to either:
A. Use React.createElement() calls
B. Use something like "htm" also included via a <script> tag, with template literal tags to wrap your component renders
You can technically include Babel in a <script> tag to use JSX, but it only works with <script> blocks that have been tagged as "JSX", not within regular ".js" files you can import using "src="
Jason Miller a-la Preact is the person I see most consistently working on and pushing this sort of React/Preact no-build setup. I definitely get the appeal, for this exact usecase -- you have a simple, mostly-static website (or something old and built with jQuery) and you want to incrementally modernize it/add functionality without rewriting the whole thing.
You can go pretty far using Vue with a <script> tag before you start needing build tooling.
I don't know if you intended it this way, but the start of this comment makes it automatically flamebait.
Discussion around release announcements can quickly turn into a flame war. Please use caution.
For instance, Vue provides a method to explicitly declare your template variable delimiter syntax. Last time I looked this was requested of React, but not implemented, someone correct me if I'm wrong on that and it has come along in the last year or two. So.. lets say you wanna put some modern Javascript in some Django templates to make them look spiffy. With Vue you can just declare your delimiter to be `[[` instead of `{{`, (because `{{` conflicts with Django's template variable syntax) with a one-liner setting.
I'm sure you could do this in React with a custom parser function (or maybe there's a third party library?) but it's a lot easier when the framework just gives such things to you out of the box.
If I do this all over the place and some other guy comes along years from now with no documentation on what he's getting into, he doesn't need to know too much to figure out what's going on and work on it. Right away he'll see "delimiter = [[" at the top of the script block in a template and can grep double brackets in the whole project to get an overview of what's being done.
This has allowed me to do things like create Vue-based tools in a locked-down corporate environment where I was not able to install Nodejs on my machine.
You can write those function calls yourself, but it would be a tremendous PITA.
If they don't trust Google, Microsoft, and Apple to keep Javascript in the browser sandbox-jail then they're gonna be re-inventing an awful lot of wheels ;).
node.js code can cripple your system way more. So this does not really seem surprising.
I exaggerate, but only slightly.
Compiling our front end assets takes longer and more CPU than our entire back end with many multiples the amount of source code.
To add to this the Node ecosystem seems somehow to encourage outsourcing extremely simple pieces of functionality (leftpad anyone?) so you end up including a bunch of crap that you don't really need, all because someone didn't feel like using 10 lines to reimplement something simple.
Endless dependency graphs and single-function modules and left-pads weren't a problem back in the days of JQuery and sane libraries. None of this madness is necessary. No, not even for front-end frameworks. It's unnecessary in the vast majority of cases.
My first year of React development was without JSX even though we DID have a build step (I was categorically against it at the time. Things changed, haha).
The babel script is huge but it might be an option to get the ball rolling on a big upgrade.
1. https://medium.com/@to_pe/how-to-add-react-to-a-simple-html-...
So if you want to use it on one page, it's a hard sell to set up all that infrastructure (and document it for the team)
On some sites I've used Vue.js by simply adding a <script> tag with vue.min.js.
On sites already using Gulp or similar, it's pretty simple to incorporate the Vue bundle and use it on one or a few pages.
https://shinglyu.com/web/2018/02/08/minimal-react-js-without...
https://reactjs.org/docs/add-react-to-a-website.html
Having said that, React is normally used with JSX syntax, which requires a compile step.
You _can_ use it with "raw" `React.createElement()` calls, but that's generally unwieldy and almost no one does that.
However, there's a very neat library called https://github.com/developit/htm , which is an almost-JSX-compatible syntax that uses JS template literal strings, and requires no compile step.
https://github.com/arijs/vue-next-example
I already integrated vue-router, and am currently on the process of fully integrating Vue server renderer. I already have a basic usage implemented, where the home page is compiled to a html string, but I still need to make it easy to compile all pages and to implement client-side component hydration.
99% of the time, HTML is easier and faster to write, with the built-in directives providing all the functionality you need. More importantly though, HTML can be generated by every single server-side framework, and this makes it very easy to have server-side code from any language stack that becomes interactive using a Vue client-side layer.
All this FUD spread by the Vue fans is getting ridiculous...
I'm seeing a bunch of commenters getting defensive and saying "well technically" while conveniently ignoring the difference in effort required to do islands in each framework. You can't say dropping JSX is at all comparable to plopping in v-clicks on existing HTML.
You can certainly adopt react "incrementally", in the sense that you can implement an entire new self-contained feature and plop it into an existing app if it already uses REST APIs, but react is decidedly not as trivial to sprinkle into a non-SPA where data comes mixed with HTML rendered on the server.
Saying React can't do it, to paraphrase you, because "technically it's harder than with Vue" is like saying nobody can drive a stick shift because you have to shift gears manually.
Yes, you have to do it manually, no it doesn't make the car undrivable.
That's what I call FUD.
React wasn't even mentioned, don't know why so defensive, who cares
People whose data validation is done via server-side logic probably don't need typescript either.
The car gear analogy is again downplaying magnitude. The examples I gave are not a comparison between auto vs manual, it's more like auto vs getting a different license type to drive a 18 wheeler and having to learn how to turn, back out, park, go under bridges and where you're allowed to drive and not all over again. Yes, it's technically doable, no it's anywhere near similar amounts of effort as just learning stick.
To clarify, again, just because it feels like react vs vue is akin to manual vs auto when you're in a codebase that is amenable to being refactored into react, it doesn't change the fact that there are types of codebases (non-SPAs without HTTP API layers) where migrating to react is a significantly larger investment than vue. That was what the OP was saying.
VueJS has first class support for this use-case while React has "well technically no ones stopping you from figuring it out by yourself" support.