6 ms·
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,
by diob 6y ago
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.
- deleted 6y ago[deleted]
- lhorie 6y agoReact 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.
- jhall1468 6y agoI 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.
- lhorie 6y agoI'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.
- RNCTX 6y ago> 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.
- coding123 6y agoYeah 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 https://github.com/coatue-oss/react2angular 2 https://github.com/coatue-oss/angular2react https://github.com/coatue-oss/angular2react
- joshribakoff 6y agoThis is also just plain false you aren’t shipping jsx and react doesn’t depend on anything but there being a stable host DOM node. It’s literally the other way around, vue uses global registration making it the only one of the three frameworks likely to give you any issue at all https://vuejs.org/v2/guide/components-registration.html https://vuejs.org/v2/guide/components-registration.html
- lhorie 6y agoThe 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.
- joshribakoff 6y agoI think I know how to code a faq I use react to create a tool for humans to help autonomous vehicles with react. Jsx has nothing to do with how easy it is to embed react in a host app. If you want to compare build systems, VueJS is also less practical and robust without its optional build system. This was used as a reason angularJS v1 would kill react and it’s a tired argument IMO
- lhorie 6y agoYou 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.
- reader_mode 6y ago>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.
- acidbaseextract 6y ago> 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!
- nojvek 6y agoWhy 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.
- acidbaseextract 6y agoYes, 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.