
Am I wrong in hating React JS? - eibrahim
https://medium.com/front-end-hacking/am-i-wrong-in-hating-react-js-811ef963aa2d#.b39zthwvb
======
ggregoire
To reply to your complaints:

> I hate html in javascript. I hate JSX.

At least it's just HTML and JavaScript.

In my opinion it's better than learning a new messy templating DSL, i.e.

    
    
        <ul ng-if="::vm.items.length">
            <li ng-class="::{ 'active': item.active }" ng-repeat="item in ::vm.items | orderBy: 'id' as ordered track by item.id" ng-click="item.active = !item.active">
                {{::item.name}}
            </li>
        </ul>
    
        <select ng-options="item.subItem as item.label for item in ::vm.items2 track by item.id" ng-model="selected"></select>
        <div ng-include="selected.template.url" />
    

> I hate the lack of CLI. I hate the ridiculous amount of shit I have to do to
> simply get a project started.

You can use the official Create React App CLI [1].

> I hate the sheer amount of boilerplate code and the verbosity.

How do you recreate the following component in
Ember/Angular/Backbone/jQuery/FoobarJs with less boilerplate and verbosity?

    
    
        Header.js:
    
        import React from 'react';
        import Icon from './Icon';
    
        export default ({ icon, title, subTitle }) => (
          <header>
            <h1><Icon name={icon} /> {title}</h1>
            <p>{subTitle}</p>
          </header>
        );
    

> I hate the lack of conventions — every project I look at looks different,
> every blog post looks different.

React is just a library to build views, so there is not a single way to build
your app in the React world. You can use Redux, MobX, Flux or whatever you
want to manage your data. You can even do it in 100% raw vanilla JS. I think
it's great.

\---

[1] [https://github.com/facebookincubator/create-react-
app](https://github.com/facebookincubator/create-react-app)

~~~
acconrad
You definitely have to learn a DSL - in JSX you have to use _className_
instead of _class_ for the HTML tag property. There are a few other examples
of this, but the point is the argument doesn't hold water against Angular's
templating language.

~~~
t3soro
className has always been the convention for accessing the class attribute in
Javascript.

[https://developer.mozilla.org/en-
US/docs/Web/API/Element/cla...](https://developer.mozilla.org/en-
US/docs/Web/API/Element/className)

~~~
cri5ti
And that's of course because pre ES5 you couldn't use keywords (class) as
property names.

------
carsongross
_Is React a fad?_

Yes.

 _Is it here to stay?_

Yes.

 _Should I get into it?_

Depends on what you need. If you are building a web application with
complicated UX needs (protip: you probably aren't) and/or the team insists on
React, you probably need React. If you want an easy time getting a job in the
Bay Area right now, you probably need React. If you want to avoid having your
comments downvoted on HN, you probably need React.

So, it depends.

~~~
ng12
> protip: you probably aren't

Citation needed. HN has this really strange assumption that everyone who talks
about web technology is working on Wordpress sites or implements TodoMVC for a
living.

~~~
lloyd-christmas
It's a 3.5 year old framework. Unless your career is "technical cofounder"
with 6 month intervals, you probably don't get to pick your stack. People that
have up and chosen React for their professional platform _and have their
company succeed_ aren't going to be all that common[0]. Within those that
have, people who have used it for long enough (and large enough) to burn their
hand on the stove are few and far between. Remember when Angular was the
golden child and could do no wrong? It's 6 years old now, and took a while
before the fandom died down and you could actually find the practical
criticism.

I think the assumption that everyone does a 'Todo' is definitely a poor one,
but I feel like 90% of the React articles are by people that have used it for
6 months at most, company blogs included. Glancing at the angular builtwith
stats[1], they had 600/10k within 4 years. 3.5 years into React and it hasn't
broken 100. While these numbers don't directly translate into "complex UI",
they are still indicative of long term usage, going back to my hand-on-stove
comment.

[0]
[https://trends.builtwith.com/javascript/React](https://trends.builtwith.com/javascript/React)

[1] [https://trends.builtwith.com/javascript/Angular-
JS](https://trends.builtwith.com/javascript/Angular-JS)

------
cbhl
You are probably just experiencing change aversion, also known as "getting
older". It's normal to have these feelings.

There were people who programmed in assembly and hated compilers and C. There
were people who programmed in C and hated Perl. There were people who
programmed in Perl and hated PHP. There were people who programmed in PHP and
hated Ruby. There were people who programmed in Ruby and hated that JavaScript
suddenly was a "real" programming language.

You'll probably be able to find work in your language/framework of choice for
a long time, although as time progresses it will be less "hip startup" and
more "enterprise" (look at C#/ASP.NET) and "banks" (look at COBOL).

~~~
scaryspooky
> also known as "getting older"

I disagree with that. It's not about age, it's about experience. React is
essentially reimplementing ideas from the past on a new platform. I think it's
more skepticism that React is 'it' as the next big UI view layer. The
tolerance for bull goes down as you age, and sometimes the next big thing is
just a different way of polishing the same ideas from 20 or 30 years ago.

------
acconrad
You're not wrong in hating React, but it is a fad as much as no one wants to
believe it. The reason I believe is because no matter how strong the
framework, eventually it will be adopted (to some extent) into the native
language (which is a good thing). Think about these frameworks:

\- jQuery

\- Coffeescript

\- Backbone

at the time, if I had asked you if those were a fad, you'd think I was crazy.
And yet, because of native language enhancements, none of those frameworks are
really needed anymore. And I'm sure in 5 years React, Angular, Vue,
Ember...you name it, will also likely be a thing of the past.

The important thing that I've learned in my (so far very short) career is that
it's always best to know the language first, and the framework second.
Frameworks come and go, but the language is permanent. By knowing the language
really well, it's strengths and weaknesses, it enables you to determine when a
framework is helpful... _and more importantly, when a framework is a
hindrance_.

As an anecdotal example, I had a client that was using a React boilerplate on
NPM to do a Foursquare API request. React is like, 50k lines uncompressed? To
do _that_? I was able to replace it with 22 lines of vanilla JS. If you don't
know the base language, it's often easier to simply think in the framework and
create a bloated environment for very basic things rather than just use what
the language gives you. It's faster, it's cleaner, it's more widely supported
in browsers, has a larger community, and is more defensible to use the base
language than a framework, until the framework does more work to help you than
harm you.

So my advice would be, if you're thinking about using React or Angular, think
about why you need it. Are you doing heavy lifting on the front-end, like
interactive graphics or a dashboard? Sure, those are probably pretty good
choices. If not, and you're simply trying to make the front-end more RESTful,
with some easier reasoning about your applications, you could probably get
away with a lighter framework like Mithril, Elm, or another lightweight
framework.

~~~
RubyPinch
> at the time, if I had asked you if those were a fad

I still wouldn't call jquery a fad, just obsolete

~~~
nmgsd
Are you perhaps thinking of JQuery UI? The core JQuery lib is still used. And
for basic front end dev it really does offer most of the utility you'll look
for in other libs.

1\. Get and manipulate dom elements. 2\. Register simple event handlers 3\.
Ajax calls that are simple (frankly all other ajax-ish APIs I've ever seen
pretty much copy the design and approach of the JQuery one).

Also a pretty big ecosystem of simple highly focused add-ons. You (still) can
get a long way with just JQuery

~~~
nevon
You can, but it pretty much is obsolete at this point.

1\. `document.querySelector()` and then just modify the DOM however you want.

2\. `node.addEventListener()`

3\. `fetch()`

There are still things that jQuery provides that aren't as simple to do with
the built in functionality, but in most cases, you can get by just fine
without pulling in all of jQuery. And in those cases where you can't, there
are more focused libraries available for those specific use-cases.

------
mariusc23
I wasn't a huge fan of JSX until I saw the template errors in Angular 2. Not
trying to bash on the rest of Angular 2, but it really made me appreciate how
JSX points out the exact syntax error at compile time. Pretty much all
template based frameworks have the same problem.

It took a while for React to "click" for me, but that was mostly because of
transitioning from MVC to Redux. I highly recommend learning pure React first.
Build a project with that first, even if it seems like you're writing a lot of
code.

------
zghst
_I recall a few years back I hated Ember JS and kept trying to get into it and
hating it then for some reason the 3rd time I did, it stuck and I LOVED IT._

Seems like you're already obstinant and opposed to tech from it's perceived
novelty and new age, rather than trying to understand the problems its trying
to solve.

------
jameskilton
What may help is to change your perspective, and to change your word choice.

It's not hate. It's _definitely_ not hate. You don't like React, and that's
perfectly fine. "Hate" has some very specific, very negative connotations that
make almost impossible to have a regular conversation. One of my mentors uses
the term "stop words". Hate is on that list of words that, when used, stop the
conversation in its tracks.

It's ok to not like things. It's perfectly OK to not like Javascript
frameworks. There's a ton of them, or you can write your own if you feel
that's necessary.

But please, can we stop throwing around the word "hate"? It does nobody any
good and only furthers the problems of ego and exclusivity prevalent in our
industry.

~~~
eibrahim
Thank for the feedback. It might have not been obvious in my article but I am
definitely open to changing my mind about stuff and I gave 2 examples: Ember &
VIM. So just because I hate React now doesn't mean I will not be a fan later.

------
formula1
The reasons why you should like react

\- forces you into an object oriented paradigm with constructors/destructors

\- mutation from external sources and internal sources results in a single
function being run to refresh the output.

\- inline html/xml is your freind. You can see easily how a ui is structured
rather than parsing a 300 line file to see what gets created, destroyed,
appended, prepended anD etc

\- all jsx results in is a "patch". This "patch" is then compiled into
components (which also result in a "patch") or html elements/text/null values.
This makes reasoning about the application simpler since a "controller"
component may not care about updating canvas info. But the "canvas" component
certainly does

~~~
kierenj
I respectfully disagree. You don't need constructors and certainly not
destructors (really not sure what you mean by this in the context of React,
can you elaborate) and these are not really the main OO concepts.
Polymorphism, inheritance are, but you don't refer to these?

There is no inline XML, and I'm not aware of any other popular (or otherwise)
React alternatives where you use long files which create, destroy, append and
prepend DOM elements?

I'm also not sure what you mean by patch, or what the specific benefit you're
highlighting here is - just modularity? You can do that with any framework, it
doesn't seem unique to React - at all?

~~~
formula1
Component will mount/component did mount is effectively construction.
Component will unmount is effectively destruction. Apparently them changing
the names makes you believe thats not what it is

Polymorphism and inheritance can be implemented if you wanted. Mixins were
used for a while.

Xml is react native and all other alternative rendering that use jsx syntax
and a form of react

React alternatives where you create/destroy/append/prepend would be the DOM.

Patching is interesting in that the inline html isnt actually html until the
end of the render loop. I dont remember seeing that anywhere else to be
honest. It seems more similar to transforms like in node streams.

------
xiamx
May be you should try it more than three times. Like you've experienced with
ember and vim, the epiphany comes all of a sudden

~~~
eibrahim
That's my plan. Maybe a month from now, i will post about how much I love
React :)

------
raquo
> I hate html in javascript. I hate JSX.

How about hyperscript? Functionally equivalent to JSX but it's pure JS, with
no XML syntax.

    
    
       header(
         h1(Icon({name: icon}, [title]),
         p(subTitle)
       )
    

I don't think you can make an argument against building the DOM in JS (instead
of using some random DSL to parse HTML template strings) without falling into
the fallacy that JS === logic and HTML === presentation. But, you don't seem
to be making arguments.

------
gremlinsinc
Then don't use it, imho Elm is way better, and the way they write html in elm
is a lot more pleasing and less ugly than jsx. I'd recommend taking a look. It
also compiles to js and has better performance.

~~~
ng12
I love Elm too, but Elm's biggest problem is Elm. It's hard to justify picking
anything other than Javascript if other people are going to be touching the
codebase.

------
zilchers
I'm with you on the embedded HTML in JavaScript files. There's a reason
everyone went nuts for MVC, the seperation of UI code (in my opinion) just
makes your life as a developer easier.

~~~
thibauts
We're past static view components.

Today UI elements are dynamic things and the code that drives the dynamics
should be kept close to the static representation of a given view state.

React actually separates UI code and interaction logic, as it should, by
hosting the static part in the render function and the dynamic part in event
handlers defined on the component. This is in my opinion a great balance of
SoC / cohesion as it allows proper scoping of a UI unit and fosters controlled
reuse.

I don't want to sound rude but we've had enough of this MVC fanatism that
completely disabled many developer's creativity and took a lot of courage and
energy to the React team, among others, to challenge.

Tying view logic (and only view logic) to static UI code is probably the only
way to go on the path to proper UI component sharing and reuse. Whether we
like it or not, whether we put the code in separate files or use any other
artifice we're bound to make these two walk hand in hand. The last bastion
being style. Which the React community tried to address, too.

At the risk of saying something obvious, I think we shouldn't reason on
principles and habits. Progress can't be, and never is, driven by such forces.

------
shahmeern
I think that enjoying working in a framework/library is very much a function
of how familiar one is with the framework/library.

It might be worth giving React that 3rd try.

------
busterarm
I kind of feel this way about React, but I feel even more strongly this way
about Ember.

For one thing, I haven't been to a single React site that isn't an absolute
CPU hog. Facebook is the worst for this.

Besides that though, I feel like it's still some intermediate step before we
have something better.

I'm bullish on Elm though. For now, plain vanilla (but mostly functional) JS
works fine for me and occasionally I'll throw in Backbone/Marionette where
appropriate. Maybe that's too boring for people, but I'm too busy being happy
with a stable stack and making money to care.

------
fractalf
Best thing I've read about react js ever! +1 Every time some person I talk to
mention react, part of me want to vomit.

