
ReactJS is a tax Facebook levies on startup web development - isercstmamu
https://typed.pw/a/1322
======
vegancap
I've been using React for just about everything front-end wise for the past
year. I don't think it's particularly hindered me, really. Sure, it was a
learning curve, as was Redux, but now I understand those concepts better, my
process is, I clone a 'react starter pack' from git, which has all of the
build set-up I need, webpack, sass, ES6 etc, etc. And that's really it, I find
it quicker to develop in React and Redux because the component approach, along
with the immutability of Redux, allows me to overcome bugs pretty quickly. I
find I run into less bugs, too, due to the predictability of doing everything
the 'react/redux' way. I also find writing unit tests so easy in React, using
'dumb' components. So the result is, I've got some of the most bug-free, well
tested front-end codebases I've ever worked on.

I guess everyone's experiences are different, and I understand that it's a
difficult series of libraries to learn and understand fully, and that can be
time consuming. But long-term I think it's a time saver.

~~~
drdaeman
I'm quite surprised seeing quite many comments telling how they use React "for
everything".

Isn't React just a small[1] library that essentially does only one single
thing? (And does it well) Takes a component definition, a state object, and
then renders (and maintains) the component as a DOM structure?

Unless I was looking into some other React that everyone's talking about, or
I've had my eyes looking somewhere else and missed something giant - I'm sure
it is. Then, how come everyone's doing everything with what's just an
evolution of the templating libraries? I mean, even a simplest CRUD front-end
webapp isn't only about the UI.

Not trolling, I really don't get it.

____

[1] Well, technically it's not really small, because it does not of stuff
under the hood to implement those virtual DOM and make things efficient. But
it's end-user (=web developer who isn't hacking on React internals)
functionality isn't wide-scoped. It's a library after all, not Angular or
another we-do-it-all framework.

~~~
vegancap
I think the great think about React, and stop me if I've missed your point, is
that they're actually just libraries, not framework's, you can just pull in
the parts you need and work off of those.

Say you're just doing a single page application, with some basic logic. You
can just use React on its own to create components, as you don't need an
entire state life-cycle. We do this a lot to 'enhance' our statically
generated sites.

Or completely on the other end of the spectrum, you can use Redux, isomorphic
rendering with Nodejs for example, react-router, and you can create a
complete, dynamic site, with state, storage, authentication, whatever you
need.

Then you have everything in between.

So you really can use React "for everything" in my view, and that's partly why
I love it so much.

I don't think React is just an "evolution of template libraries", I think
React is a concept, I know React didn't invent this concept of 'components',
far from it, but I think it brought about the most clear-cut, concise way of
creating web components, largely thanks to React's use of JSX, I think. When
you team that up with Webpack (which you totally should btw), you can house
all of that components dependencies in the same directory, and call them
within the component, a truly modular approach.

(I promise you I don't secretly work for Facebook, I just love React).

~~~
agnivade
> Say you're just doing a single page application, with some basic logic

Not trying to argue here, but don't you think for a simple static SPA, using
React and creating components is too much overhead ? Why not just create the
good-ol' html pages with css and js ?

I always take into account something I call as a effort-to-gain ratio. i.e.-
If I have to give a certain amount of effort, I need to see proportional gain.
I just don't see a proportional gain with using React in static SPAs.

But I get your point too. At a certain point when you are too familiar with a
certain style of development, its hard to let it go.

------
billmalarky
This is silly. Facebook isn't forcing anyone to use React. People use it
because it works better than the status quo.

>The component philosophy of React does offer some organizational benefits,
especially for working in a team, but it’s nothing that couldn’t be replicated
by some simple coding conventions.

If it's so simple to organize code why do many vanilla js codebases quickly
devolve into spaghetti? It may be simple for the author, but not the average
dev. Hell, it may not even be simple for the author if the author was placed
in charge of a team of average devs! Just because something is easy
technically doesn't mean it is easy politically. You can be "right" about
something but still struggle to get others to play along. React predefines the
rules and it is validated by a major tech company so people are apt to play
along.

~~~
ffggvv
> React predefines the rules and it is validated by a major tech company so
> people are apt to play along.

That's his point. By being giant Facebook can "force" React to others.

------
chc4
Well, that's some serious tinfoilery. No one is forcing startups to use React,
or to stay with it of they are stuck in development due to it. Facebook did
not create and release one of the most popular JavaScript frameworks in order
to intentionally hamstring other companies.

------
corecoder
Leaving out the second-guessing and the search for motives, I can only say
that I have only had positive experiences with React, and that the team I was
part of is still working on their React app without losing any velocity after
two years; I have never seen that happen with other frameworks or without
frameworks at all.

------
feifan
Agree on the direction this post is going, but that's a really cynical way of
looking at it. My perspective is that a combination of factors (and FB's
engineering clout played no small part) in making React trendy enough where
people started using it because it was cool, not because it actually solves
their problem. And I'd imagine in a lot of cases those projects aren't complex
enough to warrant React, and/or developers have dived in without really
understanding how it works and what it does.

------
carsongross
React is absolutely overkill for many, many web applications.

The temptation to over-engineering has been seen again and again, yet the
industry continues to fall for it.

I think a lot of it boils down to the cult of the new/a fear of being left
behind and, perhaps more pernicious, fear of being perceived as 'not smart
enough' to deal with the complexity of these tools.

------
midgetjones
It's an interesting theory but I don't see much to back it up.

In my own experience, developing rich UIs has been - after the initial
learning curve - a way simpler task than using vanilla JS.

------
elliotec
I completely agree with this. Here is the key point of the article, which I
think goes hand in hand with Facebook's mission to create a new web that they
are entirely in control of: "From Facebook’s perspective, React has to serve
two functions: \- priming and funnelling programmers into their enterprise and
\- suppressing development efficiency elsewhere. It’s positioned very well to
achieve both."

This isn't conspiracy or tinfoil-hattery as other comments have mentioned. I
think it's really the case and I doubt Facebook disagrees.

------
tga
I see a lot of handwaving on the side of "just" (fun activity: search for the
word "just" on this page) using vanilla JavaScript. Can anyone point to a sane
method of putting together a real-world large(ish) JavaScript application
without using (or essentially rewriting) any of the established frameworks? I
am talking about a single page app with multiple sections, each with multiple
pages using nested reusable components. Bonus points for solutions for
performance, server-side rendering, nested routing, state management, data
flow.

------
westymatt
I do react professionally. EVERY DAY. And yes I agree with you to a large
extent. I just don't think it's react specifically. Take for instance,
building an address form. In the year 2016 this has never been more difficult.
What used to be two hours of html/css/jquery, has been turned into a nightmare
of our own design. React and other heavy hitters do serve a purpose, but I
think it's fair to say that things are harder now than ever.

We live in a world where many js devs only know js, this wasn't true 10 or
even 5 years ago.

------
therealmarv
Could not agree more. I also think React serves its purpose really well, if
and only if you will have a complex web app with a lot of updates, connections
and a lot of abstraction in components is beneficial for you. So if you want
to test everything and want to put everything in a component: Use React, it's
proven to work in large scale, look at FB.

But React is not the perfect tool for all use cases. Often many parts of your
web app don't need component abstraction. React feels like app development,
not like web development. Especially if most of your problems are more web
designer problems React makes things difficult for you. One point I absolutely
don't like is all the "massive" amount of tooling you need to get React
working in a good way. I want to do web development not to be a webpack hero.

Just to be clear: I like React and it serves its purpose. But if you want to
be more flexible and don't need logic in every part of your project try
something lighter like vue.js (2.0 is coming out soon), which feels like a
good mixture of React and Angular best concepts, which is better and ideal for
"glueing" stuff and your web templates together with some advanced logic. No
need to make components everywhere. It's a lighter transition (from vanilla,
jquery etc.) which gives you enough power to handle every medium complex web
app. And you also have components there if you want ;)

~~~
joepie91_
Frankly - if you're doing web development and not app development (using your
words), you shouldn't be using any client-side templating _at all_. Just
render templates server-side, and if necessary use something like
InstantClick.

See also: [https://eev.ee/blog/2016/03/06/maybe-we-could-tone-down-
the-...](https://eev.ee/blog/2016/03/06/maybe-we-could-tone-down-the-
javascript/)

------
k__
> tricking the framework into doing what we want it to do

I read this from many framework users about many frameworks. Seems like the
average developer just can't change is modus operandi to work with the
framework they use.

> performance is abysmal

Yes, it's not that good, but most of the time it's enough. Many people write
how you should go immutable and be pure and the performance (see pure render
mixin etc.) will come. I simply switched some parts of the app, that need
high-speed, out with D3 for example.

> it’s nothing that couldn’t be replicated by some simple coding conventions

True and there are many many component based frameworks to choose from. React
simply has the better eco system.

> priming and funnelling programmers into their enterprise

Yes and that's probably the main selling point of React for Facebook (i.e. why
they give it away for free). They already hired a bunch of devs that did some
OSS work on React.

> suppressing development efficiency elsewhere

This, on the other hand, is a bit of a stretch. They don't force anyone to use
it and if you did and saw the problems with it (like I did), you could simple
use a different framework. There is no shortage on JS frameworks.

What I like about React, is that it has a big eco-system/community and a small
API.

After using it one year, I saw its flaws (both in React and Redux) and
wouldn't use it for the next project if I have the choice.

------
felideon
Especially when all you're building is a basic CRUD form.

Not knowing the nature of author's project, I think the issue is not so much
about "levied taxes" but back to the wisdom of choosing the right tools for
the problem at hand.

------
throwaway2016a
This article is disappointingly short.

While I agree that React stuff can be done with vanilla HTML and JS for me at
least it has been a dramatic improvement in code quality and productivity. And
this coming from someone who refused to use jQuery for Ajax when it first came
out, I don't jump on bandwagons lightly.

I also haven't seen performance issues assuming you remember to turn off debug
in production. But that is not to say there isn't any.

But everyone has their own experiences.

I will say, I don't know if you can call it a tax when no one is forcing your
startup to use it.

------
shams93
I think the real reason react is taking off is the ease of integration with
es6. It's weakness is the lack of support for web components. The lack of
support may cause react to lag behind dart and angular 2 in the future but
right now it's a nice way to work with es6 and get some pretty good code
organization. Angular 2 is going to be easier to test but people also use
react with typescript for the same level of testability. But ultimately the
popularity has to do with the way react integrated with babel and es6.

------
gdulli
One of the most important skills in web engineering is navigating an ecosystem
of tools that grew more complex to use than the problems they originally aimed
to solve. And ignoring those tools, identifying and adopting only the ones
that are exceptions to the rule.

While I sympathize that React ended up this way effectively, I don't believe
it was the premeditated intent. It happens often enough without malicious
intent that Occam's razor suggests this is only another non-malicious case.

------
realharo
We've already been through an era of manual DOM updates with jQuery and it was
pretty horrible for anything non-trivial.

~~~
corecoder
My first biggish js app was built around jQuery custom events. It started out
elegant and simple, I was very happy. It then quickly became a nightmare, a
very non-benign spaghetti monster.

------
typetypetype
I think there is a tendency to reach for frameworks as a default instead of
evaluating if they are really needed.

------
websitescenes
Components is the main benefit of React. It forces you to think modularly,
which can be very difficult at first.

------
transfire
Web dev fads change so fast today, only young whipper snappers can keep up
because they have both the time to waste and the ignorance not to know its yet
another reinvention of the wheel.

Case in point Enyo.

~~~
transfire
[http://enyojs.com/](http://enyojs.com/)

------
pluma
Yeah, no. At least not any more than the same holds true for Angular, Ember,
etc. And thinking it's some ingenious evil plot is a bit silly.

------
alyeulra
+1. i am paying this tax tinkering with reactjs getting it to do stuff which
is very trivial with normal html/js world

~~~
pluma
Here's an example of using "trivial normal html/js" inside a React component:

[http://www.webpackbin.com/VkDiCyjd-](http://www.webpackbin.com/VkDiCyjd-)

What gives you the idea you have to do everything with React if React makes
something too difficult? React has escape hatches built into it for a reason.

------
oh_wow
Certificate authority is invalid -- would never visit.

~~~
corecoder
It isn't for me.

~~~
0x0
The server isn't sending the intermediate CA certificate, so you'll get errors
unless your browser has cached the LetsEncrypt intermediate (for example from
having browsed a different site that sent the LetsEncrypt intermediate). "This
server's certificate chain is incomplete. Grade capped to B."

Anyways, they score an "F" on SSLLabs because "This server is vulnerable to
the OpenSSL Padding Oracle vulnerability (CVE-2016-2107) and insecure. Grade
set to F."

[https://www.ssllabs.com/ssltest/analyze.html?d=typed.pw&s=10...](https://www.ssllabs.com/ssltest/analyze.html?d=typed.pw&s=107.161.29.121&hideResults=on&latest)

