You can do the same thing with React though, you can arbitrarily render a React root anywhere, and an arbitrary number of times on the same page.

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.

> you can arbitrarily render a React root anywhere

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!

Why is Jsx a hurdle? Because you need a transpiler?

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.

Yes, the transpiler (though everybody is already bundling these days). I really like JSX, though it's not everybody's cup of tea.

I also think other folks in this thread are referring to mounting on existing DOM in jQuery-esque use cases.

React is a quite bit more all-in than Vue though. For example, an old app I'm aware of has HTML generated by JSP with its own convoluted maven build process and uses a mix of AngularJS and jQuery to hydrate client-side functionality on top of it. The development workflow is a draconian exercise in acrobatics through remote desktops and VPNs in really old laptops (because "security" and unions).

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 don't know if "from scratch" is really a fair statement. React accepts HTML in the render function, so the only thing you'd need to do is modify the variables to match JSX's variable syntax, which is exactly what you'd have to do with Vue.

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.

I'm not talking syntax. I'm saying that vue can be added on top of a third party DOM that may have server-rendered data embedded in it. You cannot hydrate React on top of dynamic HTML that was generated with JSP/PHP/.NET/etc unless you a) give up JSX (a big departure from idiomatic React) and b) interpolate server variables into your JS (a no-no in pretty much every non-SPA framework)

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.

> 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.

Yeah I don't know about all that. We sunset it now but about a year ago we enhanced an AngularJS (1.x) with Typescript and React. It was pretty easy using r2a [1]. It was pretty much an angularjs 1 app for the most part. Then we had like 5 React tags that we built more complex components that used our GraphQL layer natively. It was pretty easy too because all we had to do was typically pass one or two arguments to them, then the r2a'd tag did the rest - all react code from there. There's also a2r [2] for anyone that needs the opposite

1 https://github.com/coatue-oss/react2angular

2 https://github.com/coatue-oss/angular2react

>you are pretty much forced to describe the view from scratch in JSX.

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.

The JSX point boils down to this: you can't say with a straight face that using react without writing JSX is as idiomatic as pulling vue from a CDN, and you can't say that using JSX is as easy to setup on a legacy codebase.

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.

Not true. In fact, the first page of the react guide shows setting it up with jsx entirely in the browser. You also include babel via cdn and you‘re done.

You've moved the goalposts from "not possible" to "not as idiomatic"

Look, I gave a challenge to implement FAQ page answer toggling on top of legacy PHP HTML. Show me that it's possible to do it in react in a not god awful hacky way without refactoring the backend first, then explain how it's comparable to a vue one using v-ifs, then we can knock off ourselves out debating semantics.

How do you get the data into your Vue code?

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.

In vue, you don't even touch the data, you just sprinkle an attribute on the existing html to augment functionality much like you'd do unobtrusive js w/ jquery.

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.

> In vue, you don't even touch the data, you just sprinkle an attribute on the existing html to augment functionality much like you'd do unobtrusive js w/ jquery.

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.

I think the idea is that the backend already iterates over the data and spits out for example a ul with a li per faq item. You edit the template the backend uses so that the vue annotations are also produced, which in theory is easier than changing the backend code.

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>

New HTML outputted by for loop in backend template

  <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>

You pass data into it as json. Or load it from external source as json

You are shifting goalposts. Obviously every framework is "similar" enough if your baseline is "can I ship something with it". Heck, there are production apps out there written in choo and hyperapp and mithril. They all work just fine.

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.

Yep, this is my favorite thing about Vue.

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).

> 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.

Agree with this sentiment. I was in web dev since pre-jQuery/Backbone, but left during the rise of the js-framework wars. I then returned to this area as I needed to add functionality/"spruce up" a web app within my organization and randomly chose Vue for the task. It went smoothly and didn't require re-writing anything.

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.

i'm afraid this is pretty much plain wrong. react and svelte also support incremental adoption, and i dont know angular but i'd hazard there's a way to do it too if you bothered to ask angular devs.

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."

I think the original commenter might have intended to mean without additional build tooling?

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.

https://twitter.com/_developit/status/1220102334048624643

I can tell you that not only he is right, but I've used Vue for exactly that purpose before and works like a charm.

You can go pretty far using Vue with a <script> tag before you start needing build tooling.

That's not where they were wrong.

Look, I've used both Vue and React for this purpose and Vue is just easier to integrate. React can do it too, but Vue places an emphasis on it and it shows.

Yes, but that's a different and less flame-baity claim than the top-level's "Vue is the only one".

as someone who has used both Vue and React in a _very_ legacy system, I can say unequivocally that Vue was massively easier to integrate into our system than React was.

> Vue is the only one of the most popular 3 frameworks that can

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.

The "easily" in that sentence is an important word...

And a flame war, aka lot of comments compared to votes on HN, result in less time on the front page. So there is not the biggest benefit to oversell.

For one, it's not the only one. And instead of just talking earnestly about a cool feature of Vue in a Vue thread, to say nothing of other frameworks, you've now anchored the convo to framework comparison with your incorrect premise.

I wouldn't say this is the main selling point of Vue. For me Vue is superior exactly in the opposite scenario: when one has to build a complex SPA. State management, routing, and the like is all well integrated in the Vue ecosystem whereas, for example, in the React world it's a pita. I like React's simplicity, but I cannot deal with any of its complementary libraries for state management.

Why can't React do the same?

I'm not sure about React's capability with this, but Vue can very easily run with no build stage. You can load Vue from a CDN and use a couple lines of JS to point it at a DOM element in your app. Then you can write a plain JS Vue object (what goes inside the <script> tags in a .vue file), and all this logic will apply inside the element you pointed it at. You can also write components, although that gets a little clunky without a build stage.

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.

React can be run from a single file from a CDN, and used without a build stage. Only catch is you don't get JSX. While by today's standard some people might consider that unacceptable, it was a fairly common way to use it when it was new (because relatively fewer teams used builds for JS back then, and JSX was far from being widely accepted).

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).

React has been able to use jsx without build forever, here is a modern take: [1]

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-...

I mean, using Babel in the browser is essentially a build step. Your code isn't executed as is and has to be preprocessed. It's huge and slow. Not particularly viable. If your goal is just to play around, sure, but the point the Vue folks are making is that they can do the same in a way that is production friendly (maybe not scalable, but still production viable). This isn't.

I find it amusing that you are allowed to run arbitrary Javascript but can't run NodeJS on your machine. Sometimes corporate security can be a theatre.

Frontend JavaScript is sandboxed and you can't really disable it without crippling 90% of websites.

node.js code can cripple your system way more. So this does not really seem surprising.

I wish we couldn't run NodeJS, then the front end devs wouldn't run this monstrosity that takes ages to start, downloads GBs of dependencies, consumes 12 cores for minutes at a time, etc.

I exaggerate, but only slightly.

I find this attitude towards front-end developers unamuzing. If you have a beef with subset of developers in your workplace that happen to to work on the front-end, you should not take your frustration or generalize their behavior over an entire industry.

I don't know what it is about the Node.js ecosystem which leads to the dysfunction, but there's definitely dysfunction, and it's definitely endemic.

Compiling our front end assets takes longer and more CPU than our entire back end with many multiples the amount of source code.

I think it's that JS has no standard library, so dependency graphs are an endless fan-out instead of fanning back in after a while. That's how you end up with 900 dependencies after importing a single Node module, because every author of every upstream lib chose a different way of doing the same thing.

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.

Javascript has a standard library... intended for the language's actual use case, which is lightweight scripting and DOM manipulation within the browser. It's not a deficit of the language that some startup decided to pretend JS was the new C++ and that an insane and byzantine ecosystem developed around the attempt to force Javascript to be something it was never intended to be, and make it seem more "enterprise."

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.

I mean, you gotta trust someone at some point.

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 ;).

React can, but less ergonomically than most developers are used to.

Could you comment more on how it's done?

Modern React uses JSX which is then transformed at build time into function calls.

You can write those function calls yourself, but it would be a tremendous PITA.

In this case, you could use `htm`: https://github.com/developit/htm#usage

That's cool- but unless you're targeting greenfield browsers only you aren't going to use the syntax in that documentation without a build step or using the babel transpiler directly in the browser which, while cool from a POC standpoint, isn't a good solution. At that point you might as well just add build tools and use JSX or whatever the framework you're trying to use intended or otherwise is well documented.

Yeah totally. Or even use Preact by the same author which is smaller and faster than React.

I suppose it could, but there are annoyances with JSX defaults.

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.

React doesn't have templates, so that's a non-issue. JSX is sugar on JavaScript, but it's not a string. So template delimiters don't matter (that is, if you didn't use a build step, then it would be straight javascript functions calls)

That’s the whole point of the discussion: Vue makes it easier to have Django spit out <tr @click=doThing>My data here</tr> and then Vue notices and adds the event listeners. In React, it is very difficult if React has to start with foreign template output because it wants to own the (V)DOM.

For sure! I was just pointing out that discussing how easy Vue made it to change the delimiter ala Mustache isn't exactly a benefit vs React, since the whole concept doesn't reall exist there at all.

React and Vue can both be used directly with script tags, however the biggest difference is that React uses JSX while Vue uses HTML templates (but also supports JSX).

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.

That's exactly right and this is a much underrated capability and I think it's the point being missed by those saying "well if you do XXX you can include React with a script tag too!"

Please someone correct me if I'm wrong. It seems like you can only implement React using the full "modern JS stack", i.e. Node/Webpack/...

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.

React can be added to a page with just a script tag in the same way as Vue:

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.

React can also be used with just script tags. It uses a compiler to turn JSX into a render function (the same as Vue which accepts JSX or HTML) and these compilers are written in JS and can run in the browser. Also modern browsers are much better at supporting JS modules which makes it easier to include other libraries.

This looks like the perfect place to mention my project template used to create Vue 3 apps without the need for Webpack or any other build tool:

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.

Apparently this is possible:

https://shinglyu.com/web/2018/02/08/minimal-react-js-without...

There is no need to run NodeJS in production with React. In fact, React doesn’t even require a fancy build system (though for anything more than a toy app you’re tempting fate.)

Couldn't be more excited how Vue 3 would become the basis of the next amazing project

You can do this with Angular. Just create a component, insert the compiled script tag, and then you can reference it in the html like: <my-component />

You may want to look at projects like preact-habitat, stimulus, and web components (a la polymer). Vue isn't the only game in town for this functionality.

Stencil, Elm and React can also be be gradually adopted as they can produce individual component, which can be mounted to a part of webpage

As far as I know, what you are talking about was the main reason React was created in the first place.

All this FUD spread by the Vue fans is getting ridiculous...

Not trying to hurt any feelings here, but as far as I can see as an unbiased person who's looked at far too many frameworks for their own good, the FUD is coming from the React fans.

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 do it is a fact. So React devs are not spreading any FUD whatsoever.

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.

I gave some examples downthread where react pretty much falls apart. I'm sure you "technically" could make it work by dropping down to vanilla and cloning nodes or refactoring backend code or whatever, but at that point it's not merely "technically a bit harder", it's a pretty huge stretch.

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.

The problem is that somebody gave a compliment to vue, and immediately a bunch of react people came with their "well actually"

React wasn't even mentioned, don't know why so defensive, who cares

I very much doubt the original comment mentioning "the most popular 3 frameworks" didn't have React in mind as one of those, even if they didn't spell it out, so that complaint IMHO makes little sense.

Actually it had both of them in mind.

People whose data validation is done via server-side logic probably don't need typescript either.

> the main reason React was created in the first place.

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.