[statictype]

If you tear out something like jQuery, you’re going to have to figure out a way to get those accordions to expand and collapse again. If you tear out React, you get a blank page. React is a big commitment.

This is probably the only real concern I see.

jQuery is a library for DOM manipulation. It can co-exist with many other libraries.

React is an entire framework.

These days you need jquery less because browsers are more standards compliant and css animations basically work.

The trick is about using the right tool for the right job.

We have several large react applications - these are user-interaction heavy rich single page apps.

But we also use vanilla html and jquery dom manipulations in many other places.

[kbenson]

> These days you need jquery less because browsers are more standards compliant and css animations basically work.

Originally, jQuery's big selling point wasn't that it handled animations, it was that it gave you a query selector, and one that could be used in any browser. jQuery predates the release of chrome, and came out a few years before document.querySelector was added to Firefox and Chrome was released.

jQuery was monumentally more useful for common actions compared to its contemporaries, such as Dojo, MooTools and Prototype.

[threatofrain]

What does "an entire framework" mean? Because you can just make React the little news and weather widget in the corner of your app / website, as the only React component. Same with Vue.

The people for whom ripping out React or Vue leads to a blank page are those who wanted an app from the ground-up.

If anything, React is losing because it doesn't include enough out of the box. If you wanted to build a news widget, fine. But if you wanted to build an app, you have to start putting pieces together from 3rd parties (or write your own custom pieces). That's not what a framework sounds like to me, that sounds like figure-out-your-own-framework, and I think that's why Vue is winning.

Create React App was a very late response, and I still don't think it's as good as Vue's up-and-going tooling experience.

[statictype]

I guess what I meant was when you build a widget with react - the whole widget has to be react.

With jQuery, you're likely building it with html and using jQuery for user interactions or animations (I know - not always true - constructing the markup with $('<tag>') is also useful). So its easier to rip out jQuery and replace it with - say - document.querySelector - or whatnot.

I personally think React is overkill if you're pulling it in to do a small widget on a larger non-react page

[pbowyer]

> What does "an entire framework" mean? Because you can just make React the little news and weather widget in the corner of your app / website, as the only React component. Same with Vue.

Is there a step-by-step tutorial for this? I was googling for one yesterday, because I have a legacy app and want to start moving small components (like datagrids) out of server-side rendering and into components.

The best I found was https://reactjs.org/docs/add-react-to-an-existing-app.html, which reads like it would make sense to an xperienced React developer, but not someone coming new to it.

[jgalentine007]

I've been spending hours and hours the last few days working with react/vuejs/react native/native script+vue. It's hard picking a stack for staticish sites/pwa/pwa+e/spa/mobile! Throw in moving from .NET/IIS to .NET Core and tinkering with Node.JS/Express and your head is going to be spinning like mine (let alone worrying about authentication, API first, SSR)

Right now I'm moving an old webforms project to .NET Core + MVC / Razor and am going to try building out some components in both react and vue to see how it goes.

As for some links:

Here is slightly old .NET/MVC5 article: https://www.red-gate.com/simple-talk/dotnet/asp-net/a-real-w...

Vuejs for .NET/MVC5: https://medium.com/corebuild-software/vue-js-and-net-mvc-b5c... https://medium.com/@hyounoosung/integrating-vue-js-2-0-to-ne... https://medium.com/@disjfa/using-vue-js-in-existing-websites...

[threatofrain]

Do you find it difficult because it suggests you need to deal with JS modules and building? After you get your tooling setup, you can just include a node in your DOM that React will target and mutate.

[pbowyer]

I find it difficult because of understanding how to get it to fit with an existing directory layout. And maybe existing scripts in the build. But yes, setting up the tooling is overwhelming.

create-react-app says in the README: "If you need to integrate React code with a server-side template framework like Rails or Django, or if you’re not building a single-page app, consider using nwb, or Neutrino which are more flexible."

So I go and look at nwb and Neutrino, and there's nothing there going "Need to use us in a legacy project with its own directory structure? Here's how".

I feel I'm missing a piece of the jigsaw...

[threatofrain]

I might prescribe that you go to reactiflux (not associated) or other popular chat communities to get some more live help for getting your tooling up. I suspect that if tooling were resolved, so much discussion of churn would disappear overnight.

[joe_momma]

That's because you aren't using Reason-React

[threatofrain]

Could you explain more about Reason? I've been curious about it for awhile.

[joe_momma]

It's typechecked with redux and router built in already but still early so not all bindings are there yet for libs easily found for react/typescript. Maybe not for all projects that need that strict of type checking.

[int0x80]

>>If you tear out something like jQuery, you’re going to have to figure out a way to get those accordions to expand and collapse again. If you tear out React, you get a blank page. React is a big commitment. >This is probably the only real concern I see.

I'm sorry but this is not a problem. If you commit to React then you commit to it. You are not suppoused to change it every other year.

Imagine a big C++ Qt application. Will you ever think of changing Qt on it, and expect no huge cost? No. That's unreasonable.

So what he wants is not only a cross-browser, cross-platform framework (and much more) but also a framework that is somehow "cross-framework"!!

This is really getting me. People, such flexibility and ubiquity is NOT FREE. People this days complain about the web being to complicated, and that it is a lot of complexity to make something "simple as a webapp". I agree, it is. But that simple multimedia webapp you get today works over a distributed network, in almost every platform, from mobile to desktop to almost everywhere. This kind of ubiquity will be unthinkable in the early 90s/2000s without investing on a huge number of experienced dev teams and a huge especialized codebase(s). Today some javascript framework and markup will give you almost the same product. Yes, I think the web ecosystem can be improved. A lot. And the end result is not always 1:1 comparable at many levels with what you would get back in the day with native apps and a load of work and experience. But still.

People complain but they don't know what they are getting.