
React is the new jQuery - brennankreiman
http://bradfrost.com/blog/link/replacing-jquery-with-vue-js-no-build-step-necessary/
======
superfrank
> React is the new jQuery

Anyone who uses "the new jQuery" as some sort of insult (as it seems Sara did
in her tweet) probably hasn't been a developer for more than a few years or is
just trying to sound smarter than they are by bashing an easy target.

The reason jQuery got so popular is that it made common tasks so much easier
than anything else at the time. Anyone who was doing web development before
jQuery knows what a godsend it was at the time. JQuery was a fantastic leap
forward for development at the time it was released.

JQuery didn't become bad, the rest of the development world caught up and made
it unnecessary.

~~~
danShumway
I don't think JQuery ever got bad. It just got unnecessary, like you said. But
it took a lot of work to convince people that it was unnecessary.

A charitable explanation of Sara's tweet might be that, like with jQuery, it
is becoming difficult to convince new developers that React may not be
necessary for their next project.

The other comparative downside of JQuery was that components started to rely
on it as a shared library, which meant developers suddenly needed to do
dependency management. That is (usually) a bad idea. React absolutely does
have that problem as well - probably to an even worse degree than jQuery
widgets ever did.

This is kind of the same concern I have with Vue to be honest. I use Vue for
prototyping and will probably use it in some final apps as well. But I'm
probably not ever going to use a component that someone else has written if it
relies on Vue.

IMO Lodash went the right direction with this. A component or library can
depend on Lodash, pull in _just_ the functions that they use for a final
build, and then nobody else in the entire dev toolchain needs to know or care.
No risk of conflicting dependencies, build size stays low, etc...

I kind of wonder if the problems Vue solves for me could be solved better by a
smaller, lodash-style library instead of a framework.

~~~
jimmaswell
Being used to jQuery, I really see no reason not to use it in new projects. I
could learn all the new native equivalents, and even then still ending up
doing more work than if I'd been using jQuery, just to save a little bit of
page load time and filesize, but it would almost certainly not be worth it.

~~~
3131s
It irks me that Javascript didn't just adopt the best parts of JQuery.

~~~
vinceguidry
There are still things you can only do with jQuery, I can't think of a better
Swiss Army knife for small tasks.

------
rich-and-poor
Oh Brad, you do not know what you are talking about right off the bat. Let's
go through your list.

1\. Every document has a root node. <div id='app' /> is your root node now.
You had a root node before, you have a root node now.

2\. Do a search and replace. That's easy.

3\. That's another search and replace.

4\. You don't need to call a constructor, you don't need to use bind, and you
don't need to assign your functions to an variable on your class instance.

React allows you to compose things. Make something once and use it everywhere.
You write much, much less code. You get lifecycle hooks for when things mount,
update, unmount. You get easy templating in JSX. You can also ditch the whole
thing for Inferno if you care about having no lisence or company behind it.

You also get amazing libraries for state management and async via reactivex.

~~~
jypepin
I like Brad's articles, but recently it has seemed like he has struggled to
migrate on React, and some recent articles have just been trying to criticise
React but with bad (or false) arguments, which makes it appear just him trying
to justify himself not being able to wrap his head around.

React is great, mostly for bigger web apps that do need a framework and more
structure, such as an SPA with multiple team members working on it.

Just like jQuery is great to do some quick and simple dom manipulation.

I've tried both opposites; I've been on teams working on large apps in jQuery,
and it's hell. And I've also used React to implement simple little things, and
it's also hell (part of it for reasons Brad mentions in this article).

I don't have much experience with Vuejs but I've been using it instead of
React recently, and it's refreshing indeed. Just like jQuery you can just
import it with a script tag and start doing some dom manipulation and it makes
the code much cleaner than jQuery.

And as others have said, jQuery is not bad - it's awesome. I guess it didn't
age very well with the JS env evolving, but it's great.

~~~
chmln
>React is great, mostly for bigger web apps that do need a framework and more
structure, such as an SPA with multiple team members working on it.

I'd argue this is bad advice. What constitutes a 'bigger' project us
arbitrary, and once you build your whole app on jQuery it's expensive to
migrate to React once you get just a bit 'bigger'.

Now whether or not all websites need to be React-based SPAs is a different
question entirely.

~~~
jypepin
yeah you are right about the cost of migrating, I've been through one and it's
indeed to be avoided.

I badly used "bigger". What I meant was more in the lines of React is great to
build what we could call web apps - something with complex logic, etc. While
jQuery is better for simple DOM manipulation.

Maybe a good line is, as soon as you find yourself manipulating data you might
want to think about using a framework such as React.

------
itsangaris
Ok, so Brad is already making sweeping declarations about React, yet less than
a month ago he specifically posted about his struggle to learn it:
[http://bradfrost.com/blog/post/my-struggle-to-learn-
react/](http://bradfrost.com/blog/post/my-struggle-to-learn-react/) cool...

~~~
_betty_
Almost like some people don't quite get that's its intended to be used for
complex applications rather than just websites.

------
gcommer
> Burn all of your markup down to the ground and replace what you had with
> <div id="app" />

This isn't totally true -- if you really only wanted to implement a single
toggle and leave the rest of the page alone, then you could replace just the
relevant DOM elements with a container and render into that fragment of the
page. (Though really I'd ask why use React if that's the only value you're
getting out of it)

> I guess that’s why I’m still struggling to comprehend why so many
> organizations are so eager to take the sturdy, foundational layer of the
> frontend stack and rewrite it all in a proprietary format. [...] Projects
> like Vue are showing that’s not necessary.

Except, Vue.js does require a proprietary format; all those v-* attributes and
custom components will be need to be migrated if you want to switch away from
Vue. Comparatively, React is better in this regard because there are multiple
implementations of React (preact, inferno, nerv). Also, JSX is technically
optional, and it's really easy to mix markdown, or other formats/templating
engines into a React app to handle the content-heavy bits.

~~~
freedomben
I feel like the word "proprietary" means something different to me than the
author. When I think of proprietary I think of a closed standard that may or
may not be copyrighted/patented. Something like React would not even come
close to my definition.

Wikipedia seems to agree with me [1], but maybe I'm misinterpreting it:

[1]
[https://en.wikipedia.org/wiki/Proprietary_software](https://en.wikipedia.org/wiki/Proprietary_software)

------
wolfspider
I think there is some confusion comparing jquery with frameworks in general
heh- time for a history lesson! So back in the mid-aughts right before jquery
there was prototype. I got hired into a job where I had to maintain sites
written with both in the past and they were very similar to each other. Ajax
was new and so was the class based handling of JS to make it more object
oriented. It could be done but prototype made it convenient. It was possible
to manipulate objects before applying them to the DOM however it was really
verbose...academic I would call it. Then prototype’s cool younger brother
arrives (jquery) and it became so easy to pull this stuff off it was like a
giant party. Learn jquery? Your hired! Ahh the halcyon days ;) Anyhow- if
you’ve lived through things like CGI and DHTML (and java servlets to a lesser
extent) they were like the malaise era of web dev but jquery flipped the
tables there has been NOTHING like it to date. We’ve gone back to academic
with colorful packaging (I’m lookin at you angular!) and react coupled with
redux just isn’t the same- it’s interesting but not a quick study. So..back
then we could pick up a program in 24 hrs book and land a job. Today we can
read 24 books and scratch the surface. Jquery was a movement not a framework
and the statement being made was life is too short to NOT be incredible, we
can all be incredible with jquery so why not? More comparable to the Misfits
showing up to a Johnny Cash show than just another framework...just my two
cents.

~~~
digitalzombie
There were also mootools and dojo.

I was more into those two but jQuery made everything dead simple.

~~~
jaequery
and dont forget scriptaculous :)

~~~
hrayr
I'm having flashbacks to 2006! mootools, dojo, prototype, scriptaculous,
jquery.

~~~
bearjaws
Sometimes all on the same page!

------
stevebmark
A common flaw in software engineers is writing thinkpieces about technology
they don't fully understand yet. Giving it a clickbait, not fully baked title
is a bonus.

Move along. Engineers will continue to use good technology they understand
(like React) while newcomers will continue to try to emotionally justify
technologies they don't want to learn and use.

------
danShumway
I agree with the spirit of what he's saying, although I don't think jQuery is
a very good comparison to use.

React is a decision. I'm speaking in broad generalizations because I don't
know how to put this principle into more specific terms, but good programmers
should avoid making decisions for as long as possible. This is the same reason
why I caution people against using test frameworks. Most of the time when you
start coding an application you won't have enough information to make any
educated decisions about it.

This is a huge advantage that Vue has over React. You can use Vue for just one
component out of your entire app and it's fine. It is fairly easy to separate
it from all of the rest of your application logic and that means by extension
it's fairly easy to rip it out later. Or at least... easy enough.

It's still not perfect. I dislike how hard it is to make its templates fail
gracefully when Javascript is disabled. I dislike that it uses setters in its
data model, which discourages immutable programming. I dislike a few other
things as well.

At some point, someone will make a better framework than Vue, probably by
building something even smaller and even more focused than Vue already is. But
in the meantime, if you are going to use a framework for two-way data
bindings, you should probably be using Vue instead of React. Opinion me, of
course.

------
parvenu74
Let’s not forget that jQuery was a polyfill that allowed JavaScript Devs on
all browsers to code to a common baseline. React is a nice —- and popular —-
library for building UIs but it’s existence isn’t an indictment of the
laziness of standards implementors for browsers (okay, IE mainly) and god-send
to developers like jQuery was.

~~~
growtofill
Yes, React isn’t _exactly_ jQuery, but it gives the same level of productivity
boost comparing to development with just the modern DOM APIs (querySelector,
classList, etc).

~~~
crooked-v
For a large project, React gives you way, way, way more benefits than jQuery
does.

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

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

~~~
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](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.

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

------
danielrhodes
Moved from Vue to React. A couple things drove this: Typescript support for
Vue was kind of weak, and the interception of events and reactive elements
ended up creating more bugs. I do love how Vue is easy to get up and going
fast, but React seems more compatible with a growing team where you want
stronger guarantees.

~~~
jpkeisala
First time I read someone moving from Vue to React. I thought trend was only
from React/Angular to Vue?

~~~
tracker1
Vue works better for small apps, or progressive enhancement (similar to
jQuery)

React works better for teams working on applications that need build tooling
and dependency management anyway.

Angular, frankly I don't see why anyone would pick it over the other two.
Yeah, it's got more in the box, but that bigger box takes 4x as much effort to
lift off the ground.

------
huy-nguyen
I think people got carried away with the JSX side of React (which IMO is
really just the icing on the cake) and forgot that React was probably the
first view library that introduces the notion of the DOM as a pure function of
data. It made functional programming mainstream in front-end development. This
purity makes UI extremely easy to reason about and makes all DOM changes
tractable. I was in a Backbone shop before using React and I remember Backbone
was such a chore to manage in a large application. We switched to React and
never looked back.

~~~
freedomben
> _It made functional programming mainstream in front-end development._

I totally agree, and in fact I would take it a little farther and say it's
making functional programming mainstream on the _backend_ as well. Many people
I've worked with got their taste via React/Redux and then started adopting
things like Elixir/Phoenix for the backend.

Maybe it's an overstatement, but I credit React with driving at least some of
that.

------
nobleach
The problem was never jQuery. jQuery performed a very necessary function when
it was created. It was always the intention of the lib to cease to be needed
over time. The problem was/is the ecosystem created around jQuery. Want to do
a thing? Do it with jQuery. Want to read a cookie? Use jQuery. Want an image
carousel? Build it with jQuery. Want to do anything at all? jQuery.

I do see something similar happening with our more junior devs. Their Google
searches have now turned to "how do I read a cookie with React?"... and sure
enough, there is a react-cookie lib - which may or may not be useful for their
task... but since it says "react", it'll probably show up in a pull request.
React can't be blamed for this though. All the ecosystem being built with the
expectation of "well everyone's using React", _is_ a problem.

Education about separation of concerns is the only solution I can see.

------
phragg
Brad Frost makes most of his money telling people what they should do instead
of actually _doing_ himself.

He's given hundreds of talks all over the world about a component-based
approach to style guides in web, but yet cannot fathom the need for React.

------
Achshar
I find myself defending myself a lot these days here. I use vanilla js. Never
had any trouble, I literally have no bundle, no dependencies, the amount of
code I have to write is basically the same either way, no trouble syncing
state with DOM either. Have done so in two moderate projects (40k, 15k).
Everyone I meet looks at me like I'm crazy. But in the same breadth say the
site feels so smooth and responsive. No shit.

Catch being you he to learn how to write js but that's true for any framework
as well. And frameworks have smaller shelf life anyways.

~~~
rbosinger
I agree you can do that but I feel like frameworks are more about teamwork. I
can't imagine having a team of 10 with varying levels of JS experience/passion
and telling them all to "just write nice simple vanilla JS that we can all
agree is clean and simple" and expect that to happen.

~~~
Achshar
I don't have a ton of experience leading team's using react, angular etc but I
assume you are referring to the fact that there are multiple ways of doing
things in vanilla js world whereas only one way in react world. That can make
things easier for teams but I believe that's a lazy excuse. Choice is never a
bad thing and it's literally the job of a tech lead to establish conventions,
tell devs what flow to follow. If that turns out to be too difficult then it's
not the code or framework's fault. Staying strict about how to do things is a
concept that exists irrespective of framework or no framework.

~~~
rbosinger
Have strict team conventions and being afforded the time to try an enforce
them is great. Agreed. It doesn't always end up working like that in my
experience though. Frameworks often have a community that provides some
convention guidance. Rails, for example, is huge on this. You can tell a
developer "stick to the general Rails way of doing this" and they will often
be able to follow that instruction. Is that lazy? Sure, probably. But I also
consider it to be a feature of a framework.

------
sheeshkebab
React has a lot of inertia behind it, although it doesn’t really make things
easier.

The amount of js code to make even basic things work is high, and with so many
different styles of writing react/js code, large codebases require significant
effort to keep maintainable.

Which is to say, with this much effort put into structuring maintainable react
js code, one could pretty much develop in any js ui framework (including
jquery, backbone or none whatsoever) - since little of this effort is
dependent on react, or made easier by it.

~~~
joesb
Virtual DOM and ability to derived your DOM state from props and state is not
something you can easily done with jQuery or any UI library that doesn't have
that concept.

It's not something you can easily implement yourself either.

That's the main part that makes React code maintainable.

~~~
quxbar
I agree, this is the part that people seem to be ignoring. Yes, you can make a
proof of computational equivalence between jQuery and React, but you cannot
deny the massive increase in human usability that an set of components brings.
There's far more interesting set of things you can do, Redux + the litany of
other related libraries, a vibrant ecosystem unto themselves, prove this. I
started my career out slinging jQuery and after 4 years of React I never want
to go back.

------
djsumdog
I really like the linked Vue/Jquery article in the story as well. I've built
some stuff in Vue and I really like it. It can be incredibly simple.

I'm not a huge fan of React. I'm really not a fan of any site that requires
Javascript to view. If it's a new article and I get a blank page, I
immediately stick it in archive.is. I'm not turning on Javascript for your
site just to view content. Fuck that. Fix your site to not suck shit.

I realize you can easily get into the same thing with Vue .. and I think Vue,
React and others, makes sense if you're actually running a web application.
Your main page, login page and other content pages should be static, no
Javascript required. If you have a new site or a blog or graphics, why the
hell are you requiring React/Vue/Angular or some other framework? Just display
the content.

I haven't really looked into server-side rendering, but I suspect that still
requires Javascript to be enabled on the client? Are there any newer Vue/React
style front-end frameworks that are designed to still degrade gracefully
without Javascript? (I suppose you can't really do this without pairing it
with the backend language on the server).

I really like how Hackernews still supports a Javascript-less system, even for
things like up/down votes (although I still turn JS on for HN to avoid page
refreshes).

~~~
tracker1
React can definitely use Server-side rendering... but it's often used for pre-
render caching, and even doughnut caching to bootstrap the full application on
the client, so you see content sooner. But, it's entirely possible to pre-
render and degrade gracefully.

Is it worth the effort for a fraction of a percent of technical users whining
about the need for JS? probably not.

------
TekMol
When I see this:

    
    
        var formname = $(this).find('.formname');
        formname.empty();
        formname.append(n_input);
    

I think why not just use plain Javascript and do this:

    
    
        document.querySelector('.formname').innerHTML=n_input;
    

Coders that are attached to libraries and frameworks always seem so afraid to
use the tech already available. That they don't even look at how the basic
solution would look like.

~~~
m90
Sorry for being terribly pedantic, but the "vanilla" version just does not do
what the jQuery code does:

\- `this` might not be document

\- find might return multiple elements, not just one

\- if nothing matches, jQuery does not throw unlike the vanilla version

I do understand it's just an example, but if you'd consider all the implicit
cases the jQuery example covers, you'd end up with a lot more than a single
line. I see your point, but using off examples like this don't really sell it
too well.

~~~
tracker1
assuming "this" is an element... `this.querySelector` if you're intending to
match multiples...

    
    
        Array.from(document.querySelectorAll(...)).forEach(x => {...})
    

It's not *that hard... though forEach should be on your dom collection
returned, if Array.from exists, but I started shimming Array.from long before
either were standard.

------
twfarland
This is from the guy who posted recently about struggling to learn React.

------
andrewstuart
I don't buy it.

ReactJS is a power tool and it takes some learning.

If your primary concern is about your initial learning curve then you should
look elsewhere such as VueJS but I'm glad of the power of ReactJS.

Changing class to className is not a big deal, nor are the minor other bits
and pieces mentioned in the post.

------
mpc
We're talking about two totally different programming paradigms here. The end
product might be the same but it's more of a question about how you arrive
there.

With JQuery you're signing up for manual DOM manipulation. It's a challenge to
scale that for what's now considered table-stakes for web apps.

------
swyx
i just find it amusing that everyone gets up in arms what Brad Frost struggles
with in React because he's famous. news flash: hundreds of devs face these
issues every day and figure it out. Brad is famous and has problems with
React; that's fine. He'll figure out a way that works for him. Doesn't mean
his opinion at all reflects the experience of the thousands of devs who are
happy with React. Let's move on and talk about more interesting things.

------
tracker1
Vue is for enhancing web pages.. you _can_ do applications, but they get very
complex beyond small-mid sized apps.

React is made for building web-based applications. You _can_ do small stuff
with it, but it's often overkill.

Just because you can use a butter knife to turn a flathead screw, doesn't mean
it's the right tool for the job. These days I might reach for Vue as a jQuery
stand-in, but more likely, I'd use a smaller jQuery-like library, or just use
straight vanilla JS, or other micro libraries. For anything big enough to
deserve a build process React is absolutely my first choice.

~~~
nek4life
Vue can be used to enhance web pages, but it works equally well if you want to
build a large application. This was one of the design goals. Something that
you can start small and scale up with that works equally well for both. If you
use the Vue CLI you can have a setup with a router and build tools and setup
something very similar to create react app.

------
nol13
<3 jQuery, maybe nostalgia talking but still one of my favorite pieces of
software ever. Made DOM manipulation fun.

~~~
meesterdude
> Made DOM manipulation fun.

same! Jquery is still quite useful and powerful. This is also what rails does
for me; makes web development fun. Or highcharts making charts fun, or
elasticsearch making search fun. To me that's a testament to elegantly solving
a problem. I just don't get those fuzzies with react.

------
pankajdoharey
The JS world is so much more hype driven than say ruby, every few months they
will have a new framework that promises to solve all the problems in ui land
or the backend. They write songs in its praise everyone worships it like this
is the one true framework a panacea for all evils. And then when the hype
cycle winds down a new framework emerges. I am totally bored of looking at
this cycle for the past few yrs. This just leaves a ton of unmaintainable
projects in its tracks because the devs have found a new toy to play with. I
have seen clients struggle to find backbone devs because no body in interested
in Backbone this is a repeated pattern among JS Devs.

JQuery -> Backbone -> [Tons of Backbone wannabe's written in Coffeescript
Batmanjs/Bananajs/what not..] -> Angular -> [Angular lookalikes with tons of
magic] -> Ember -> Meteor -> React -> Vue -> [Wait a few months new framework
in the Pipeline].

Unfortunately very few want to agree to the truth.

~~~
joelhooks
This just isn’t true. React has been going strong for 4 years with no sign of
slowing down.

~~~
pankajdoharey
I dont disagree, React has some solid underpinnings but for now VUE has some
momentum, till the next one comes along. Google gave up on the idea long back.
Google develops Angular but doesnt use it in any of their core products. They
themselves use Google Closure library for gmail or word processor.

~~~
jexah
Isn't the new YouTube website running Angular? Please don't shoot me if I'm
wrong, I don't have any citations, I just presumed (on phone, too lazy to look
up).

~~~
tracker1
Not according to Augery (angular chrome extension), but not sure if all
evidence can be built out of the result.

However, mobile.twitter.com and facebook proper are using react. Along with
Walmart.com and many, many others.

The biggest Angular app I've seen is probably grubhub, and there's some
painful state bugs there... in fact I don't think I've ever seen an angular
app (not using rxjs or redux) that doesn't have weird state management bugs.

~~~
jexah
I tried using Angular 1 when it came out and it seemed like too much work to
learn for such a small benefit. I started learning React at the start of last
year and have found it phenomenal. I am not comparing the two, let alone
arguing in favour of Angular. I just thought with the swap to Material Design
(and async loading data and components) in YouTube, that they were using
Angular. Your opinion about YouTube using Angular (or not) has more citation
and authority than mine, so I will assume in the future that YouTube does not
use Angular (without certainty, of course).

------
yakshaving_jgt
Brad Frost has significant social capital and influence. That's the only
reason this charlatanry is given the time of day.

------
nielsbot
Sort of tangential, but React is way less painful with TypeScript/tsx. I
combine that with an IntelliJ IDE (RubyMine specifically) and honestly, it's a
lot of fun to write web apps this way. (Maybe that's because I come from an
iOS background?)

Anyway, I recommend giving this setup a go.

~~~
huy-nguyen
My first foray into React was done using Typesctipt. The functional nature of
React plays very very with the static typing of TypeScript.

------
joe_momma
Just skip React and Vue and go straight to ReasonML/React, you will end up
there in 3 years anyway

~~~
chrisco255
Had that worked well for you? Is it mature enough to use today?

------
rbosinger
As a member of a busy, small team with a Rails app and a jQuery heavy front-
end... I agree. We use React in a few places and wanted to simply introduce it
slowly and "convert to React where we could". It simply has not worked out for
us. We have typical server side rendered HTML that has been progressively
enhanced with sprinkles of JS (jQuery + various plugins). We do not and cannot
book much developer time for refactoring and can only really improve the code
itself in bits using the "boy scout rule" (leave the area you're working on
better than you found it). For us, it turns out that yanking out chunks of
jQuery and replacing them with React did not work out very well.

~~~
pbowyer
Thanks for sharing, this is exactly what I am considering doing at the moment.

Any thoughts on
[https://news.ycombinator.com/item?id=17213264](https://news.ycombinator.com/item?id=17213264)?

~~~
rbosinger
For us the difficulty is that with React you need to let React control it's
piece of the DOM. We have lots of jQuery UI components. For example, we use
Select2. So let's say a dev tries to redo a jQuery heavy form in React. It's
mostly fine but there's a Select2 component in there and some WYSIWYG jQuery
plugin on a text area. You can't just initialize those with the React
component because React will complain about jQuery touching the DOM it
controls. So now you either have to find React versions of those jQuery
components or properly wrap the jQuery components you have with React which,
IMO, can be a bit funky and ends up feeling kind of wrong. Basically, you can
end up down a rabbit hole. If you're intention is to truly modernize you're JS
and your happy to rip out old jQuery plugins and make changes like that then
it's fine. We just didn't have the dev budget to always be doing that.

------
benatkin
This comes from a well-known and respected thought leader. There are different
types of thoughts, though. This is simply an observation:

> Don’t @ me I’m not trying to start a controversy. I’m only stating an
> observation.

[https://twitter.com/SaraSoueidan/status/1001189524477743105](https://twitter.com/SaraSoueidan/status/1001189524477743105)

React, like jQuery, could have done more to keep people from writing bad code.
With React, they made the same mistake that Angular did, which was to impose
strict rules on all developers. Vue, to its credit, doesn't make this mistake.
It's much less opinionated about state management.

~~~
joesb
They should done more to keep people from writing bad code, they should have
less rule.

What does that even mean?

~~~
benatkin
In this case, doing more means responding to the real-world usage of React,
and making it so that lifting state up isn't the only recommended option. Vue
did this and is grabbing some market share from React.
[https://reactjs.org/docs/lifting-state-
up.html](https://reactjs.org/docs/lifting-state-up.html)

------
Cub3
Since early in my career when hiring I've found developers who only know
'jQuery / Angular / Vue / React' but not the underlying Javascript, I swear "x
is the new y" is said every time a new framework gets 6 months into vogue.

~~~
rhapsodic
_> Since early in my career when hiring I've found developers who only know
'jQuery / Angular / Vue / React' but not the underlying Javascript_

It's frightening, the degree to which many professional web app developers do
not know the fundamentals of Javascript. Our technical interview starts out
with ridiculously simple questions and gets progressively more difficult and
esoteric. And a dismayingly high number of candidates don't get past the first
couple of questions. And these are people with years of experience and at
least some of the hot JS frameworks on their resume.

------
mikl
> React is a big commitment. I guess that’s why I’m still struggling to
> comprehend why so many organizations are so eager to take the sturdy,
> foundational layer of the frontend stack and rewrite it all in a proprietary
> format.

There’s nothing proprietary about React. It’s all open source. MIT licensed.
If you don’t like Facebook’s implementation, there’s like a dozen re-
implementations. Hell, a modestly competent software developer could write his
own implementation of React in a few days of work.

All else being equal, I’d say a React code base will be less of a maintenance
hassle in the future, than the spaghetti mess you usually get when trying to
write complex applications with jQuery (been there, done that).

------
fapjacks
I like to shit on jQuery like anybody else, but it _did_ have its place in the
world. It was totally abused by people, but that doesn't make jQuery _bad_ per
se, any more than PHP or JavaScript is bad. Yes, I avoided using those things
as much as I could, and I much prefer other tools, but they are tools
nonetheless. Bad programmers and nontechnical people posing as programmers can
abuse well-loved and efficient tools, too. Have you ever seen code written by
a noob embedded "engineer" who decided to write their weekend side project in
Golang? It's as much a fucking disaster as any of the bad PHP or jQuery stuff
out there.

------
invaliduser
JQuery is a great tool, it got a lot of buzz and people started to abusively
use it out of its nominal scope. This does not say anything about jquery, only
about people. React is having a lot of buzz, and the same abuses happen in
places where it is nowhere needed. Same cause, same symptoms.

You can replace jquery/react with any technology or concept, OO programming,
functional programming, MVC, blockchain, machine learning, and every
technology or concept having its momentum is or will be misused in some way at
some point.

This happened, is happening, and will always happen.

------
i_am_stupid
I am learning to code and a newbe.

I think jQuery != react.

I do not understand, why experienced people like to compare jQuery with react
when both the lib have different goal ? And show that jQuery is bad.

React can be used with jQuery for DOM manipulation. Described in react doc
([https://reactjs.org/docs/integrating-with-other-
libraries.ht...](https://reactjs.org/docs/integrating-with-other-
libraries.html#integrating-with-jquery-chosen-plugin)).

Shall I learn jQuery at all ? Please, guide me.

~~~
Axnyff
The comparison Sara made was that React can be overused just as jQuery was.

The problems with jQuery is that it's mostly a set of functions to simplify
Ajax and DOM manipulation so it's not really helpful for the structure of an
application.

React (and other frameworks surch as Angular, Ember and Vue), on the other
hand, helps you to build reusable component which helps a lot to scale.

Also jQuery's golden age was when browser compatibility was a big issue,
nowaday, most browsers behave properly.

There's no harm in learning jQuery, its interface is way more intuitive than
native DOM apis. It could be a good idea to try and build a simple app with
jQuery and see what are the pain points and then compare with a modern
framework.

~~~
tracker1
My only advice to people today would be to use one of the much smaller jquery-
like libraries for DOM interaction/events and fetch (shimming ie11) instead of
other wrappers.

------
dmitri1981
I wanted to try and address the points Brad makes and as well as clear up some
of the misunderstandings in his post. Take a look
[https://medium.com/@dmitrigrabov/react-is-not-the-new-
jquery...](https://medium.com/@dmitrigrabov/react-is-not-the-new-
jquery-e42a19f165f4)

------
jaequery
vue seem to be an evolution of react and angular.

it is as if some react developer sat down and said, “how can we make this even
simpler so that even my grandson can do it.”

i appreciate when we have guys like the authors of Vue come forward driving
the community and taking web development to the next level giving us a more
elegant solution.

~~~
tracker1
More like a cousin... I see Vue as a nice component system for smaller
applications, I don't think I'd want to build anything of even moderate
complexity with it.

React is for building applications, especially with teams. Combined with redux
and a handful of other pieces, it's very nice.

Angular, I don't get why anyone would choose it today (I've said it time and
again).

~~~
jaequery
I disagree. I would imo recommend you to switch to Vue if your app have gotten
too big with React. As I said, Vue is more elegant and it improves the speed
of development which also means less errors.

There are many big companies and startups who switched to Vue and loving it so
I would say your point is moot.

~~~
tracker1
Facebook is probably the single most interactive and complex application out
there... it's using React. There's also more to it than just the UI portion...
there's also state management, and the unidirectional workflow, that you don't
get in nearly as consistent a way with Vue as say Redux.

Startups will use whatever is trendy. I'm unaware of any site the size of
Walmart.com or twitter's mobile site, or Facebook that uses Vue.

Just because you disagree does not invalidate my point.

------
nreece
Nitpicks aside, it seems to me that React/Vue are only/mainly useful for two-
way data binding. If it's just one-way binding (i.e. JSON to template), then
jQuery with something like Handlebars will be just fine. Correct me if I've
misunderstood.

~~~
pygy_
React and Vue are immediate mode/declarative UI libs. Your code says "given
the model/state, here's what I'd like the UI to look like right now", and they
manage to mutate the DOM efficiently to achieve what you want.

jQuery and the plain DOM are retained mode APIs. You manipulate stateful
objects to achieve your goals. It is ok for simple interactions, but it
quickly becomes unmanageable for more complex apps.

------
sireat
Coming from a background of doing embedded Javascript work(not web) I found
React surprisingly easy to work with and joy to write code in.

React feels like writing normal Javascript.

Vue is very easy to embed into existing web page but feels like learning a new
DSL instead of regular Javascript.

------
bigbadgoose
> I’m still struggling to comprehend why so many organizations are so eager to
> take the sturdy, foundational layer of the frontend stack and rewrite it all
> in a proprietary format.

it's about workforce and durability of the platform

------
faitswulff
Mods, can we change the title? The current title was clearly chosen to be
inflammatory. Meanwhile, the original title only mentions VueJS, not React:
"Replacing jQuery With Vue.js: No Build Step Necessary"

------
handbanana
I don’t really agree for various reasons. That said, I’m not a huge fan of
react, but am stuck working with a few code bases that use it.

I prefer vue, but I dislike that it’s essentially a one man show.

~~~
enraged_camel
Vue isn’t a one man show. It has a sizable team behind it.

~~~
jexah
> essentially

And when compared to React, he's absolutely right.

------
simion314
Does React or other cool frameworks have alternatives to jQuery UI components
or you need to build your own calendars,dropdowns, accordions.

~~~
ggregoire
React has everything (calendars, dropdowns, accordions and so on).

~~~
simion314
Can you link to the official repository? last time I checked you had to find
something on github that mostly were incomplete and the best components were
jQuery wrappers

------
kaixi
That's an incredible compliment.

------
oh-kumudo
jQuery in terms of popularity? I'd take it as a compliment.

------
basejumping
This guy is such a phony.

------
xab9
The microwave oven is the new swiss army knife.

