
The React Is “just” JavaScript Myth - formikaio
https://daverupert.com/2018/06/the-react-is-just-javascript-myth/
======
ipsum2
> React is so much more than “just JavaScript”. React is an ecosystem. I feel
> like it’s a disservice to anyone trying to learn to diminish all that React
> entails. React shows up on the scene with Babel, Webpack, and JSX (which
> each have their own learning curve) then quickly branches out into
> technologies like Redux, React-Router, Immutable.js, Axios, Jest, Next.js,
> Create-React-App, GraphQL, and whatever weird plugin you need for your app.

> In my experience, there’s no casual mode within React. You need to be all-
> in, keeping up with the ecosystem, or else your knowledge evaporates.

This is not true at all. I use React for work and for pet projects, and I
don't use or know what most of these libraries do. (We do use Redux).

It's easy to get caught up in library mania and chase after the newest
javascript fads, but it is not necessary to build products.

Also, GraphQL is not tied to React or Javascript.

~~~
sus_007
Just out of curiosity, what are your thoughts on Vue? I've heard a lot of good
things about it.

~~~
ipsum2
I dislike the templating language, preferring jsx which is mostly standard js
syntax, e.g.:

Vue: <li v-for="i in items">{{i}}</li>

React: items.map((i) => <li>{i}</li>)

~~~
bartaxyz
Just to make things clear. You can use JSX with Vue as well. It's even a
recognized way to write code in the official documentation
([https://vuejs.org/v2/guide/render-
function.html#JSX](https://vuejs.org/v2/guide/render-function.html#JSX)). JSX
is just a language that can be interpreted into code for React & Vue.

~~~
Can_Not
Not to mention that you can use Jade/pug, also.

------
Androider
It's absolutely fine to adopt React piece by piece, I disagree entirely that
it's an all-or-nothing proposition. I've converted a heavily used in-
production service from 0% to 100% React over the course of more than a year.
And this is an SPA, so over that year there was literally jQuery and React
rendering to the same DOM. It works just fine, it's all just JS.

You don't have to use Redux etc. (but you probably do if you have sufficiently
complex state). Even then, you can do things like have multiple stores in the
same app. It's fine! It's just JS objects being spliced, merged, propagated.
You eventually converge on a single store as the various React parts merge.

You don't need to use react-router, or even a router lib. It's probably better
if you don't, given how many times that shitshow of an API has been completely
rewritten. I took one look at it, could tell that this lib wanted to be fully
in charge, and noped out. It's fine to manage browser URL state yourself, it's
just JS and the browser APIs are OK for that nowadays.

Now we're in the process of adopting Immutable.js. It's fine, it's just
fancier collections, with some conveniences and being able to use
React.PureComponent 99% of the time without worry. So your codebase is 50%
fancy collections and 50% JS natives? That's fine, don't worry about it, just
write new components using Immutable.js if that's the direction you're going.
Don't worry about the top-level Redux container not being an Immutable
instance, just use it for the leaves then.

Server side rendering? I retrofitted that in a weekend by compiling the app as
a lib with Webpack (project started as Gulp way back), included that in
Node.js as an import. Worked just fine, nothing to it. Now we're generating
PDFs using the same frontend code with Puppeteer and SSR, it's awesome.

The app is in a better shape than ever, a real pleasure to work with. Jest
tests for React stuff, Mocha tests for other parts. And that's fine, no need
to get all religious about which one is the "one true" framework.

------
hazza1
The jQuery api was hundreds of different methods, the best of which are now
available natively in JavaScript.

React has a very small api, I hardly ever refer to the documentation (unlike
when I was a jQuery or Angular developer)

I agree that people reach too early for helper libraries but you can go a long
way in pure React.

~~~
mrtksn
Because React doesn't manipulate the DOM directly you're leaving every
convention and tool about DOM manipulation behind, which means that the moment
you want to do something more complex than composing components you either
have to re-invent the wheel or use the brand new wheels that somebody re-
invented.

React is brilliant but makes simple stuff that no one was thinking on anymore
hard and complex again. So if you don't want to think about how to handle an
AJAX request and an animation like it's 2004 you can just slap a library on
top of React(and worry about the page size and loading strategies).

React is a statement, a revolution, it is about disowning the old Web and
building it from scratch.

~~~
hazza1
fetch and CSS handle AJAX and animation absolutely fine with native calls and
work well with React, why would you bring in a library to handle these?

~~~
mrtksn
You bring animation libraries in when your UI animations don't necessarily
match the component lifecycles and you don't want to do something basic. Well,
you don't have to bring in animation libraries but then you'll have to
engineer it by yourself and handle all the quirks.

In React you simulate a DOM(or whatever) instead of working on a DOM that's
handled by the browser(or whatever).

It's just like the difference of a real-world physics and simulated physics.
In the real world, you can throw a rock and the nature will handle everything.
On a simulation, you will have to think about all kind of details to make your
simulation as realistic as possible.

~~~
hazza1
I don't really see how complex animations is something React (or any UI
framework) should be responsible for ?

~~~
mrtksn
Who should be responsible if not the UI framework?

Oh, and by complex, I don't mean character animation or something. It's the
stuff that is supposed to act differently than the React's internal workings.

For example, if you want to do an animation on items that disappear when the
user takes an action it's not going to be easy as with plane JS manipulating
the DOM. Also, you won't be able to use some nice artistic animations that
were created by direct DOM manipulation.

------
ralmidani
Having an ecosystem does not, in my humble opinion, make writing a React
application feel substantively different from writing a pure JS application.

Yes, JSX is not part of the core language (yet), but it's the closest to pure
JS we are going to get considering developers' need for an intuitive,
expressive, and virtually bulletproof templating language.

Before learning React, I built some decent-sized applications with Ember and
Emblem (a whitespace-significant language that compiles to Handlebars) and it
was utterly painful. Not wanting to deal with Handlebars' proprietary, Ruby-
like syntax (not bad per se--Ruby is really cool--but out-of-place in a JS
application) and its artificial limitations on what you can do with the
language (anything resembling display logic has to be extracted into special
helper functions) is probably the single biggest reason I ultimately came to
prefer React over Ember, despite Ember having some conveniences React didn't
and still doesn't (such as a concrete modeling and persistence layer like
Ember Data).

With that aside, I think React is the closest we can get to "just JS" without
abandoning pragmatism.

Transpilers and build systems are a necessity when the language itself is
changing at such a rapid pace and there are so many different environmental
concerns an application needs to satisfy.

~~~
acdha
Out of curiosity, what do you think about lit-html[1]? The main thing I’m
interested in there is that it’s based on native web technologies so you don’t
need the huge non-standard React stack just to be able to load a file. Having
has similar experiences with frameworks in the past I’m increasingly inclined
only to use things which are moving in the direction of web standards to
reduce the amount of churn.

1\. [https://github.com/Polymer/lit-
html/blob/master/README.md](https://github.com/Polymer/lit-
html/blob/master/README.md)

~~~
ralmidani
Looks nice! I've thought about working with tagged template literals before,
but I didn't know Google already had such a project.

On the flip side, I am apprehensive about it being run by Google. Look at what
happened with Angular 1.x, which was also supposed to let you do data-binding
without abandoning valid html completely.

Also, JSX offers some conveniences I'm not sure would be possible with tagged
templates, such as not having to join an array explicitly after you map its
data to markup. Edit: I stand corrected; lit-html supports mapping an array to
markup naturally.

As far as churn, which in general is a valid concern, I don't think React is
going anywhere in the foreseeable future; it, along with Vue, has gained
developer mindshare even jQuery may not have enjoyed back in its glory day.
Absent a totally unexpected breakthrough, or Facebook really dropping the ball
on updates, I think React could easily be viable in 2025 or beyond.

Edit: lit-html is built with TypeScript, oh my! I will definitely be diving
deeper into this project. Especially if I'm not building an SPA.

------
ThePhysicist
Personally I strongly disagree that you need to be "all in" on the React
ecosystem if you don't want your knowledge to evaporate (as the author puts
it):

I've been using React since 2015 when it was still in beta, so I witnessed the
evolution and invention of the whole ecosystem around it firsthand.

And while it's true that the team and community introduced many new tools and
technologies, you could probably still use the original React documentation
from 2015 to build a simple app (as to my knowledge no backwards-incompatible
syntax changes were introduced).

Also, for 99 % of apps you probably don't need the full-blown React stack like
React Router, Redux, server-side rendering, hot reloading, transpiling with
Babel, bundling with Webpack2 etc. I routinely build small React apps for
websites (e.g. for contact forms) using just vanilla React.js (actually
Preact.js as it has a smaller footrprint) without any of the amenities listed
above, and sometimes I even write old-style ES5 code and use JS-based tags
instead of JSX.

So please only introduce additional complexity (in form of tools, libraries
and add-ons) if you really really need it. The more complex your toolchain,
the more effort you will spend just maintaining and upgrading it instead of
doing productive work (frontend devs who tried upgrading Webpack and Babel.js
to the latest version in an existing project with many dependencies probably
know what I'm taking about).

------
ljm
React has certainly inspired a huge shift in how we architect frontend web
apps, and I think I'd rather view it on those terms instead of just how much
you might buy into React's worldview and all of the libraries that subscribe
to it when building your app.

React is one particularly well-regarded implementation of a virtual DOM
library with one way databinding and ever since then we've seen various
flavours of it with innovations of their own: Elm and the architecture that
inspired Redux, ReasonML, reflex-frp, CLJS/Om Vue, Cycle.js, Glimmer, etc...
React, as far as I know it, was the first for the web and while it might have
been well-known in other situations, we were all scrambling around trying to
solve the data-binding problem when building anything large scale in JS.

In that way, React's impact on the frontend ecosystem is profound much in the
way jQuery's impact was back in the darker days, and what that technology has
allowed us to do _without depending on React itself_ is significant, much more
so than its own ecosystem.

------
goofballlogic
Strange article. The add-on libraries described aren't necessary at all.

------
petilon
The benefits of React (such as its templating syntax) can be had with much
simpler libraries, such as this one:
[https://github.com/wisercoder/uibuilder](https://github.com/wisercoder/uibuilder)

The much touted benefit of React, DOM diffing, is useful if you have a very
complex screen and you need to make surgical updates. Most applications have
simple screens that can be completely re-rendered and the user won't know the
difference.

------
davnicwil
> I sometimes browse React projects and look at the import blocks to see if I
> recognize any of the dependencies; I probably average about ~8%.

This is very true, not just because of the libraries you don't know yet but
also because those you do know are continuously evolving. I've been working in
the React ecosystem for about 4 years now. I think constantly keeping an eye
on the changing ecosystem, and constantly changing the way you do things where
it makes sense, just comes with the territory now. You just have to accept it
as a way of working, if you're going to enjoy working with React (and JS
generally).

Whenever I've locked down dependencies and just got my head down and built
stuff for a few months, without fail every time I've looked up I've realised
that there are now multiple things in my stack that are 'outdated' and there
are some _genuinely_ better ways of doing things (some really are just
different and equally good, and it's fine to ignore those) that have evolved
and been evaluated and ultimately embraced by the community in parallel in the
few short months I've had my head down.

To be honest it's what I love about the JS ecosystem in general - it's an
environment of continual improvement and blisteringly fast pace of change.

~~~
wolco
I too love the constant change its exciting.

But you can't live like that forever. Things need to remain constant so you
can work on difficult business logic instead of changing how you do standard
things.

~~~
davnicwil
The point I was making though is that this isn't necessarily true - you can do
both simultaneously. Your stack _can_ be continually improving while you still
focus on feature delivery in parallel. What I was getting at is that you
should embrace and enjoy this if you want to be happy working in the frontend,
specifically React, world.

------
EugeneOZ
As an "Angular-guy" I can ensure you that with Angular we use also builders,
minifiers and even TypeScript compiler. And testing is a separate story with
painful moments. Of course, we have much more tools out of the box - we don't
have to look for a good router, for example.

But there is no paradise of one magic tool in the web development.

------
hliyan
As a long time React user (four years), I agree with this article for reasons
different from what the author intended, perhaps. That's why I've recently
started learning Dart and hoping that it'll catch on. I want to focus on
solving the problem, not battling the ecosystem...

------
Marazan
This confuses React with the react eco system.

I am a happy producrive React user and I don't know two figs about the wider
eco system.

Whatever man, React is just JavaScript and they've learnt what not to do from
Adobe Flex, that is why I am so fast and productive in it

------
ENGNR
If anything I'd love to see a barebones 'obj => native DOM' library built into
browsers

Let React and others compete over the more advanced use cases like context,
lifecycle methods etc

