
What I wish I knew about React - ire
https://bitsofco.de/what-i-wish-i-knew-about-react/
======
genezeta
React have _sold_ very well the "it's a library" mantra. I find this, at
least, _bends_ the difference to build a _marketing_ point around it.

The point they make, and the one everyone writing about React simply repeats,
is that "it doesn't give you everything" so you can use it with any other
library/framework without trouble. While this claim may be indeed correct, it
doesn't mean it's a library. React is a _UI framework_. It's not a complete
Application Framework, sure, and you may mix it with other stuff. In fact, you
will generally mix it with other stuff. But I don't think that the difference
library vs framework lies in providing for all of the aspects of the
application or just for some parts of it.

In this particular case, the author seems to have overstepped that somewhat,
saying "With a framework, you’re essentially given all the materials to build
that house, and it’s up to you in what arrangement you put them in."

And in there lies the problem. That is not a framework. That's Home Depot. A
framework does indeed tell you in what arrangement you're supposed to put the
materials. It's in fact this that makes it a framework. It gives you
structure. Or at least, the basis for the structure. You put your materials
into the arrangement the framework suggests.

React is only concerned with UI, sure. But then again it _does_ give you quite
a bit of structure. It does tell you how you're supposed to arrange and build
your UI. You extend _this_ class with these methods, or you create this kind
of function using these functions in this way. You put your rendering _here_ ,
and return it in _this_ way... and then the framework will run it.

What is correct is that React is for _UI_. So, sure, it will not tell you how
you should do your API calls. But not because it's not a framework, but
because API calls are not a UI concern.

~~~
capableweb
I've always found the best distinction between a framework and the library
lies in who-calls-who? A library you call when you're ready to use it. With
React, that's calling `ReactDOM.render()` when you want to render your
application. A framework you just provide code blocks and let the framework
call your code, rather than your code calling the libraries/frameworks code.

So with that in mind, you can use React as both. If you ever call
`ReactDOM.render()` just once and then live in React land, with all the
lifecycle hooks and whatnot, you're essentially treating React as a framework,
as React calls everything after the first initialize.

If you call `ReactDOM.render` in multiple places or have something around that
handles that for you, then you're using React as a library.

~~~
genezeta
Yes. That's the other way of expressing the distinction between frameworks and
libraries.

And I think most people do use React as a framework. (But I could be
underestimating those who use it in the second way, of course).

~~~
yazaddaruvala
I can give a production example of migrating to React.

We needed to do it incrementally from a server side rendered Java application,
with jQuery and _a lot_ of custom spaghetti code.

At first we migrated the server side templates to JSX and started to use React
as a library by calling ReactDOM.renderToString. The first thing our
JavaScript did was render the React templates similar to using Handlebars.
Then the rest of our code kicked in using jQuery bindings and it’s events
logic.

Now that our templates were all JSX. It was simple that start converting leaf
“components” with simple state into ReactDOM.render instead. Often needing
ReactDOM.unmountComponent to “refresh” the state And rerender everything like
the jQuery based code needed.

Finally, we worked our way up the stack of components so that more and more
were “just normal react components without calls to ReactDOM.

The last thing we did was migrate the top level to use ReactDOM.render and we
were fully React based.

FWIW, we thought about Redux but didn’t use it. We used the patterns from
Redux, but felt we didn’t need a library to manage our data. This was also
pre-Hooks.

All in all took 1 dev on a team of 9, that all kept working on the codebase,
about 4 months working on it off and on 50% time focused on the migration.

There were no issues caused along the way, the automated tests didn’t need to
be changed (except for the new features - which were orthogonal to the React
migration), and customers had a (unnoticeable) latency improvement comparing
the metrics at the start and end of the migration.

The incremental use was a huge reason we picked React. Not only to migrate to
React but also because we can do the inverse process when we want to migrate
away.

P.S. We finished this migration Jan 2019. Since then the productivity of the
team has noticeably increased. Even new hire “ramp up” has been reduced with
them producing production code faster, on average, than pre-React. I’m sure
these successes would be true for a migration to any modern UI tool e.g.
Angular or Vue.

------
dvcrn
I am not so up to date with frontend dev but what's with the hate towards
React these days? It still does what it's supposed to do very well and very
fast. Yeah sure if you want JSX you need transpilation but I would want that
anyway if I want any of the ES6 features without losing browser compatibility.

And it's also constantly evolving and getting better. Just recently I started
a React project with class components only to learn that hooks are now a thing
and they remove a lot of boilerplate code. Even with redux, redux supports
hooks as well so you can scrap that entire connect() stuff alltogether. Just
back to simple function components.

~~~
ggregoire
> I am not so up to date with frontend dev but what's with the hate towards
> React these days?

HN is rarely the place to read constructive comments about JavaScript and
frontend development.

Personally I've been developing web apps for 10 years (with technologies such
as Spring, ASP.NET, CakePHP, Symfony, Django, jQuery, Backbone.js, Angular 1)
and I quite enjoy React. I think it makes my job easier and I feel productive
with it.

Also, TypeScript is awesome.

~~~
tenaciousDaniel
I've been considering the jump into TS, but I don't want to end up in a
coffeescript situation (i.e. language is dead, but code lingers on and has to
be converted back to JS at some point, rather painfully). Do you think it's
worth it?

~~~
fpoling
You may also consider Flow. It is literally JavaScript plus type annotations.
The annotations can be even put into comments turning the files into vanilla
JS making this very clear. So there is no danger that if FB abandons it one
ends up with code that needs to be converted.

On the other hand Flow is much less cool than TypeScript these days. Plus
using it for development under Windows have issues, although FB has started
paying attention to them.

~~~
Zarel
TypeScript annotations can also be put into comments. I like TypeScript's
approach (JSDoc) better, actually, because it's how you'd want to annotate
them even if you didn't have a typechecker, anyway.

Although I still hit enough annoyances that I'd go straight to `.ts` files for
my next project.

------
zappo2938
To understand React, it is important to understand the difference between
imperative and declarative coding. [0] React is a way to write declarative
code that use life cycle hooks or effects to do imperative "stuff".

The best explanation oh how useEffect works is by Dan Abramov [1] It is also
worth reading his article on React as a UI Runtime as it is a good explanation
of React conceptually under the hood.

[0]
[https://courses.reacttraining.com/courses/250055/lectures/38...](https://courses.reacttraining.com/courses/250055/lectures/3897343)
(Can sign in for free to watch this one video.)

[1] [https://overreacted.io/a-complete-guide-to-
useeffect/](https://overreacted.io/a-complete-guide-to-useeffect/)

~~~
andrewstuart
This is a critical point to understand.

If you're not doing declarative programming with React then you're swimming
upstream.

Problem is that the concept of declarative programming would be very difficult
to get beginners to grasp. Once you grasp it though, it's absolutely
incredibly powerful and importantly - simple.

And this is where React loses beginners who jump to more intuitive programming
models.

~~~
7777fps
But that's great until it isn't.

You can design all the declarative things you want, but someone will
eventually come up with a requirement that doesn't appear to fit a declarative
structure, such as an event that fires 2 seconds after something else happens.

And so to resolve that you can construct state machines with transition states
to get back to a declarative model, but those state machines can quickly
become a bigger headache to maintain (yes, even with redux) than if you'd just
been able to setTimeout from the component in the first place.

And you start with the best of intentions of re-usable components but find
more things that ought to be owned by the component pushed up to the store and
suddenly there isn't a neatly re-usable component but an empty shell of
something that still needs the other half plumbed in manually every time.

I love the idea that you can abstract everything happening in an application
to state and render reproducibly from that, but the reality is that it's
really hard and time-expensive to do compared to jquery.

But that would be fine if the tooling was there. If React had a CLI like the
AngularCLI it wouldn't be such a problem to add new actions, or new pieces of
state, or new components.

But it doesn't, so each new component ends up adding a little more state into
the state machine which ends up breaking types in far off places.

Now there's probably an assumption about how state is built up or how reducers
are typed or how actions are defined that I'm missing some reason why this
shouldn't be happening. But it is happening, it's the reality for the project
I've been working on and it's a real headache.

~~~
ddek
I can call ‘setTimeout’ from the component?

I honestly don’t see the issue with your example.

I’d use an event handler to work out when something happened. This would set
the timeout, and the handle would be stored as a ref. I’d have a use effect
hook to clean up the timer, so when the component is unmounted the timeout is
cleared.

What’s the issue here?

~~~
7777fps
It's no longer declarative as soon as you've done that though; it's still a
break in the declarative paradigm.

------
prodave
Aren’t hooks more confusing than the class components? In a class, you write
your initialization code in the constructor - no infinite loop if you fetch
something. And anyone who has used classes in Java or other languages would
feel at home.

~~~
awestroke
No, you use componentDidMount etc, spreading out the logic that could go into
a single hook into multiple lifecycle methods, spaghettied with other logic.
Hooks are much cleaner.

~~~
batiste
Would it be possible to have a single method on a class that behaves like
whatever useEffect is doing?

~~~
lindskogen
Not in a single method, no. Watch this talk for more details!
[https://www.youtube.com/watch?v=wXLf18DsV-I](https://www.youtube.com/watch?v=wXLf18DsV-I)

~~~
batiste
Well, I did something a bit similar my own language:
[https://github.com/batiste/blop-
language/commit/90e7704e125f...](https://github.com/batiste/blop-
language/commit/90e7704e125ffb3c1fe6b4de2446680d3819ab7e) Not sure where
classes are an issue with doing anything like this

------
tarkin2
React isn't a library.

You can't drop a bit of it into your project. It distorts how you build the
webapp.

jQueryUI is a library. You can add it in and your code is still vaguely the
same.

React is a framework pretending to be a library so people can't say "Oh, what?
another framework?"

As soon as you use React, you're in the react universe, not the normal webdev
universe.

With a normal webapp, I can just import an external js library. With react, I
must look for projects that translate those library into the react universe
(react-bootstrap etc).

~~~
skrtskrt
You can just add the bootstrap CDN in the head of your index.html and use
bootstrap without installing ‘react-bootstrap’

(I don’t disagree with anything else you said)

~~~
tarkin2
If you want to use the javascript components, rather than just the styles, you
need the react library version. There are various other UI libraries as well
that require you use the react conversion library, which sadly lag behind the
vanilla js versions.

Fair enough if you love react then this is acceptable. But it pushes the
definition of a library, when just using react means that other libraries need
to conform to react to properly work with it.

React does some things nicely. But it's not "It's just a library. Drop it into
your existing project. And you're done."

------
c-smile
Big picture: React (especially with JSX) can be thought as PHP running on
client side.

We can replace mentally any <div> or <span> on the page with <iframe
src="someScriptFunction()"/>. When the application state (fuzzy term but
still) changes we request these content generating functions to re-execute.

The VDOM is just an implementation detail - agreement on what these
someScriptFunction()'s shall return. Conceptually they may return just html
and so we can use:

    
    
        function onDataModelChange(model) {
          element.html = provideHtmlRenderingOf(model); 
        }
    

can be used instead of reconciliation (diffing). Performance of such updates
will be the same, if not better than React's, BTW.

The only problem of element.html = ... approach is that such updates will
loose runtime state. For example, if you have <textarea> replaced that way you
will loose its current editing state - undo/redo stack, caret positioning,
etc.

So VDOM and reconciliation mechanism is a palliative - to do not loose runtime
states on updates. But, again, it is not a panacea. Think about <div
contenteditable/> based editors, their content cannot be reactive in
principle.

That update-only-what-is-needed reasoning frequently used by React people to
promote "speed" hypothesis is a bit misleading - it was introduced for
different reasons really.

------
valera_rozuvan
If you look at it from one side, React doesn't have technical problems or the
way it's built. If you look at it from another side - React opens up a wide
range of possibilities - you can simply drown in them. Adequate things you
have done all your life - suddenly feel not so adequate anymore :) For
example, it would be fine to use plain old CSS, but with React it just feels
wrong. If you look at the number of libraries that try to evolve CSS, there
are many. But there is just no winner in sight. Pretty much the same situation
is happening in state handling. The number of possibilities! It's amazing.
Eventually, though, something gains momentum, like Redux did. This has
consequences for React ecosystem, but also everywhere else in JS world. It
slowly migrates to Angular, and other frameworks - as the cool kid on the
block.

Elegant, simple concepts of React - they are outweighed by the environment
they live in. React allows for rapid prototyping, provokes ideas which
sometimes break traditional ways. Anyways, I will leave these thoughts with
saying that personally I don't have issues with it. I adapt React to what I
want - it doesn't adapt my thinking ;)

------
pjmlp
The more I read about React, the happier I am to use VanilaJS alongside SSR
and web components friendly frameworks.

~~~
aylmao
You should try to use it too! If you discover you don't like anything about
it, all the better, you can say you've experienced it and not just read about
it. If you happen to like at least parts of it, you've just expanded your
knowledge and arsenal of tools for UI development.

~~~
doublerabbit
I just can't get myself around to use anything by FANG just due to their
licenses.

Using a framework means your project will never purely be yours.

React license:

> The license granted hereunder will terminate, automatically and without
> notice, if you (or any of your subsidiaries, corporate affiliates or agents)
> initiate directly or indirectly, or take a direct financial interest in, any
> Patent Assertion: (i) against Facebook or any of its subsidiaries or
> corporate affiliates, (ii) against any party if such Patent Assertion arises
> in whole or in part from any software, technology, product or service of
> Facebook or any of its subsidiaries or corporate affiliates, or (iii)
> against any party relating to the Software.

~~~
Lammy
Am I missing something, or did they drop that in 2017?

[https://engineering.fb.com/web/relicensing-react-jest-
flow-a...](https://engineering.fb.com/web/relicensing-react-jest-flow-and-
immutable-js/)

[https://github.com/facebook/react/commit/b765fb25ebc6e53bb8d...](https://github.com/facebook/react/commit/b765fb25ebc6e53bb8de2496d2828d9d01c2774b)

------
jarym
I write a lot of enterprise apps and I’ve seen many many frameworks come and
go over the years.

I personally am not impressed with React and don’t get what all the fuss is
about. We’ve had Angular, jQuery and a whole bunch of stuff over the years and
each one managed to become a ‘a thing’ for a while

~~~
koonsolo
React introduced a whole new way of writing GUI's.

I come from a game development background, and there we had Immediate GUI's
for some time now ([https://eliasdaler.wordpress.com/2016/05/31/imgui-sfml-
tutor...](https://eliasdaler.wordpress.com/2016/05/31/imgui-sfml-tutorial-
part-1/)). React basically translates this concept to the web, and does some
optimizations to not rebuild the entire DOM from scratch, and only rebuild
when state changes and not every frame.

Writing a 'render function' is simpler and easier than building a structure of
widgets and letting them handle events. (I like simple and easy)

Anyway, it seems both react and flutter are also gaining on the mobile apps
developments, and web developers are very happy using React.

Of course frameworks come and go, but React introduced a shift of mind when
programming GUI's.

~~~
jarym
React introduced this concept ‘to you’ perhaps but it wasn’t the first. The
framework I used has been doing this in the very early 2000s.

Don’t get me wrong it has a lot to like about it - but the only revolution is
that Facebook’s might propelled this in the minds of developers all over.

~~~
hombre_fatal
Just curious, which framework are you referring to?

Every time I see someone claim such a thing, it's usually only distantly
related. Like it too has a render() function.

I mean, you can find old FRP phd/whitepapers but I don't think they prohibit
you from ever saying "$X introduced $concept" without a disclaimer that it
wasn't the first. So if you're going to insist, then why not share some prior
art for the discussion?

~~~
koonsolo
I started my career in 2002 (been programming since '93), and back then there
was no client side rendering. So my guess is, he's talking about server side
rendering that spits out html.

Since those things really miss the 'react' part of React, it is still quite
different.

~~~
jarym
I used SmartClient when it was launched in 2002 and that did client-side
rendering back then:
[https://en.wikipedia.org/wiki/SmartClient](https://en.wikipedia.org/wiki/SmartClient)
\- I've recently taken the JS version (not GWT) and ported it to a set of ES6
classes and modules.

I used to work for a portal vendor called Plumtree in 2004 (later acquired by
BEA and then Oracle) and much of their stuff did client-side rendering.

The idea of making web interfaces more declarative and less tied to DOM
manipulation has been evolving since then. Many developers I'd encounter back
in those days moaned that we were not using jQuery or MooTools or whatever.

React is very nice - don't get me wrong - but its popularity has much to do
with the mindset of developers shifting away from seeing JavaScript as a way
of 'adding spruce' to 'web pages'.

~~~
koonsolo
The revolutionary part of React is not client side rendering, it's the
composition (and reaction) of GUI through state changes.

A quick look at SmartClient shows that it still uses the old OO way of widget
composition (widgets having .show() and .hide() methods, etc). This is not at
all how React works. In react you render your GUI based on state, and events
never manipulate widgets, they manipulate state. It's a functional way of
approaching GUI's instead of an Object Oriented way.

The React way of building GUI's is now used outside of the web, for mobile
apps through React Native and Flutter. This is completely different that any
pre-existing GUI frameworks.

~~~
jarym
It does have show and hide methods - but inside the framework it is deeply
compositional. If you have a chance to look at the docs search for ‘autoChild’
which achieves much the same as react and co but using different terminology.

------
AJRF
React is a framework though, not a library. I don't mean to be disparaging but
this is an article about how someone thought react was one thing, found it was
another and then wrote a post of random tidbits about things in react you
could learn from its homepage?

~~~
karatestomp
React's marketing (such as it is) has pushed the "it's just a library" and
"it's just the V in MVC" hard. I think folks can be forgiven for thinking
those notions won't entirely fail to describe the real world experience and
use of React in ~100% of actual projects (and even more so now that ditching
legitimately-actually-quite-portable Redux for hook-centric logic is trendy)
and being a more than a little surprised and perplexed when they do.

------
dvt
(Opinionated post ahead...) React is, imo, garbage, but alas it's here to stay
-- you know, kind of like Spring or Swing. In 10 years we're going to be
wondering how the hell we ever used React 8 hours a day way back then. These
kinds of markup frameworks/libraries were touted as jQuery's successor, but,
from an architectural point of view, jQuery is by far their superior.

"Everything an HTML tag" is an insane mantra to have. As author points out,
what in the world does a <Query> tag even do? It might make sense to us
because we're used to it now, but the semantics of a tag is completely lost in
this "new way" of using them (don't call it _declarative_ because that's _not_
what it technically is; it's _markup_ ). These days I'm creating HOCs on top
of HOCs to support different behavior (from redux stores, to authentication
HOCs, to "don't render this thing on the server" async components). It's,
simply put, a terrible idea. And everyone just bought into it because the guys
at Facebook must be really smart.

The lifecycle hooks are just confusing and unnecessary. They are side-effects
of over-engineering. And to add insult to injury, they change every few
versions (so old code will inevitably break on new React versions).

SSR. I've brought this point up on HN before, but doing server-side rendering
in React is absolutely ridiculous. Every time I need to implement it, I'm
constantly battling async stuff, state management, webpack/babel, hot module
reloading issues, shimming `window` or `document` on the server side, etc. Boy
do I miss the days when I was building stuff in PHP and HTML was simply
rendered when I ran the damn thing.

It's crazy to me that it's normal now to have like 3-4
compilation/transpilation steps when working on a simple JS-based app.

~~~
veeralpatel979
I love reading about people's first principles technqiues of different
technologies on HN! What do you think React will be supplanted by?

~~~
ma2rten
Maybe something like svelte?

~~~
iluvblender
I just started studying svelte today (alongside Vue). I look forward to
sharing my thoughts soon.

~~~
Can_Not
Things I wish I knew about Svelte: error handling is fragile and/or non-
existent.

~~~
iluvblender
I will keep that in mind, Thank you :)

------
peter_d_sherman
Excerpt:

"The way I like to think of it in comparison to Angular is this: Angular is a
framework for architecting and building applications. It, for the most part,
doesn’t change the way you write your HTML or CSS, but it heavily controls the
way you write Javascript.

React, on the other hand, is a library for building user interfaces. It, for
the most part, doesn’t change the way you write Javascript that isn’t directly
related to your UI, but it heavily controls the way you write HTML and CSS (or
the equivalent of it). And this brings me to the next point…"

------
andrewstuart
I love React. In fact I recently gave plain vanilla JavaScript a go and it was
so painful that I was glad to get back to React's way of organising a large
application.

I don't use Redux or server side rendering - they're not needed.

The only thing that I think it should do differently is leave styles to be
handled natively.

~~~
ncallaway
You absolutely can, and I almost always do, styles things with native css
(well, I use sass compiled to css) to style your react application (or
widget!).

To my knowledge, React itself has no opinion on styling. It's more the
ecosystem around React that's gone css-in-js.

But, yes, if you want to do your styling natively that's really not a problem.

------
rubyn00bie
tldr; React is a view renderer. It renders views. Getting data to and from
those views not included. Navigation? Not included. Persistence? Not included.
Styling? Not included. Why? It's just a view renderer, that is to say, it
renders templates.

When the only thing your application shares with its dependencies is its view
renderer, you're going to feel a lot of pain. This is one of the big reasons
why I use Ember.js for complex web-frontends (though holla to phoenix live
views). It's a framework-- it has all them pieces you need included in a sane
way that's consistent.

Just my two cents...

P.S. If you write JavaScript UI code, and you want to like be better at it, go
write native UI code. You'll learn soooo god damn much, write better JS, and
understand a lot more about what the fuck all these pieces (like react) are
actually doing (rendering UI, managing state, networking etc) in a sane
curated (thanks Googs, Microsofties, and Apples) way.

~~~
Scarblac
Except that it's not only a view renderer, it reacts to changes in state, and
it has ways to do stateful thing after a component is rendered or stops being
rendered or at other times.

And in practice some state is specific to some component or group of
components and some state is global or the group of components doesn't
translate to a subtree of HTML's tree structure. Also the kind of thing that
has to happen based on what happens in the app is often deeply async.

And it all becomes a mess.

But it's still not as bad as a mess as without React, I believe at this
moment.

------
DeathArrow
I'd rather use no JS framework at all. But, if forced to use one, I'd pick
Vue, as that seems the less opinionated and simple framework.

~~~
redis_mlc
Writing Vanilla-JS as we speak - don't be jealous! :)

------
gherkinnn
A nice side effect of the article: by reading the inverse of it, I get a
better understanding of Angular which I haven't used since 1.x.

------
temporallobe
I tried React and hated it, especially JSX, but I made some decent money
working on React projects in the past. I much prefer libraries/frameworks
where the view is completely separate and is more “pure” HTML. I ended up
creating my own framework that was much easier to understand and manage, but
is obviously not generic enough to publish. Maybe one day I’ll clean it up and
push it to a Github repo, but then again, does the world need yet another MVC
framework? I think not.

~~~
hombre_fatal
> I ended up creating my own framework that was much easier to understand and
> manage, but is obviously not generic enough to publish.

You lost me there.

Cute for a solo/learning project, but when other people are touching the
project or you're trying to build a business, you have to answer for why your
project was so special that it needed its own ad hoc framework. As opposed to,
say, a framework with real documentation. Or one with an ecosystem so you can
escape this culture of NIH.

When I hear someone building their own JS framework, I see someone who wanted
to procrastinate the hard part (building a business, shipping a product,
appealing to users). Like when game developers decide to build an engine and
never make the game, aka the hard part
([https://www.voxelquest.com/](https://www.voxelquest.com/)).

~~~
temporallobe
Gatekeeping much?

------
programmarchy
Off topic, but the yellow border on the page kept drawing my eyes away from
the text to the edge of the screen.

------
ivanstame
Do you wish you knew VueJS? :D

------
pferdone
tldr; RTFM

------
cryptica
>> React is a library, not a framework

They say it often but it's not true. React forces you into an entire workflow
with JSX, bundling, source mapping, babel transpilation and often restricts
you to using components that are designed specifically for React; accessing
the raw DOM is nasty business.

If it was a library, it would not hijack the DOM and override it with its own;
that fact alone is more than enough to call it a framework. Any tool which
takes over the execution environment is a framework by definition.

A library is something you use, a framework is something you work inside. You
could argue that react could be used to target only specific components but
this would be missing the point that 99.9% of the time, React is not used like
this; as soon as you have a hierarchy of components, it's a framework, not a
library.

~~~
robjan
You don't need to use JSX in order to use React; it's just syntactic sugar.

[https://reactjs.org/docs/react-
api.html#createelement](https://reactjs.org/docs/react-api.html#createelement)

~~~
ergo14
And who uses react without JSX at any scale?

