
Show HN: Under the hood ReactJS - bliashenko
https://bogdan-lyashenko.github.io/Under-the-hood-ReactJS/
======
daliwali
There was a previous discussion on how do you know when someone is addicted to
over-engineering, and looking at this giant UML diagram, I think this might be
the case.

The amount of complexity I'm willing to accept is proportional to the the
difficulty of the problem. In this case it's manipulating web pages, which
shouldn't be too hard. This isn't a knock on React in particular, but it seems
all the major vendors are competing on complexity. React has "fibers", Ember
has a "virtual machine", Angular has their own overblown architecture (I don't
know anything about it, and don't want to).

Now that the DOM API is implemented in a standards-compliant way across most
browsers, it should be the perfect time to use it. I don't like the current
mess that is front-end web development, and more of the status quo isn't going
to get any simpler, quite the opposite.

Shameless plug for my own DOM utility:
[http://simulacra.js.org](http://simulacra.js.org)

~~~
Ralfp
I am sorry but this sounds like Dunning-Kruger effect on your part. You have
created library that you think the problem, but which seems to have limited
adoption in the wild. What experience in the field you have? Have you wondered
how much you don't know about problems and scenarios that view layer has to
handle?

I've been in same situation once with my OS project. I've did something small
that I've been certain does what all those other heavier solutions do. But
when users came I've learned that there's unimaginable number of edge cases
and scenarios that are common enough to require annoying amount of work.

React.js is not "DOM utility". Its battletested view library running one of
busiest social sites in the world. It's highly performant, capable of handling
thousands of components at single time, and handles countless edge cases, like
maintaining input state while user is typing in it and its moved around DOM,
normalizing events between browsers, maintaining scroll between large redraws
or jumping user to components #fragment.

Ember.js and Angular are complete app frameworks that implement view, layers,
services, data, communications testing, tooling and more. Those are solid
options for people writing dashboard applications (think intercom or Podio),
even if they are losing ground in public-facing sites to more elastic stacks
like React or Vue.

~~~
aaron-lebo
But React is bloated. Check it out in comparison to something like Mithril
which does everything it does and more in a much smaller and faster package.

~~~
Ralfp
Last time I've checked Mithril it had no event normalization, JSX, scroll
control and input state preservation. Does it have those now?

I've did Mithril for 6 months year an half ago, before that Ember.js for two
years and Angular.js for year even before that. I've eventually settled with
React.js because it was just view library, with everything else up to you.

~~~
brlewis
JSX and input state preservation were already there a year and a half ago when
you were using Mithril. It does not automatically normalize events, though I'm
not sure how important that is in 2017. I don't know what you mean by scroll
control.

------
beefsack
I've read the first few pages, and am really appreciating the level of detail
this goes into.

Fantastic work and a great resource for people wanting to dive into React's
internals.

------
AriaMinaei
I wish the code we write write everyday carried enough semantic meaning in it
for such visualizations to emerge naturally from it.

Great work by the author nonetheless.

------
jbucaran
This is helpful to me because I want to learn how to explain (complex)
systems.

Incidentally, this complexity is what led me to build my own little vdom
utility
<[https://github.com/hyperapp/hyperapp>](https://github.com/hyperapp/hyperapp>).

I'll be drawing inspiration from this chart to explain it.

------
hardwaresofton
At this point I'm sure I and others sound like a broken record, but if you're
new and just jumping into frontend component-based frameworks, please don't
start with React.

There are simpler ways to get reasonably fast re-usable components on your
project that introduce less accidental complexity.

Carefully consider which thing you actually need:

\- A view library that uses components as the main building block (this
usually means you already have other concerns like data modeling and routing
taken care of)

\- A full SPA framework (which people often get from the react ecosystem, i.e.
React + Reflux/Redux/etc + React-Router)

Based on which one you need, there are other simpler (in the case of view
libraries), and more coherent (in the case of full framework) choices.

~~~
rohannair
React is a view framework, and knowing the internals of React is a completely
unnecessary set of knowledge for the majority of developers using it to build
products with.

~~~
hardwaresofton
As with anything, the longer you use a library, the more you must know at
least some of it's internals to use it efficiently/axiomatically/well. Even
something small like the class/className attribute thing is an implementation
detail that leaked through, which will bite and likely confuse a beginner for
3 seconds if they didn't throughly read the docs.

Other libraries don't have that problem (because they didn't accept that
trade-off in that fashion).

IMO Libraries that beginners should be shown should not be ES2015-in-every-
example, and introducing transpiled DSLs for generating DOM elements.

------
rhapsodic
I don't know how long it will take, but I'd bet that within a few years
everyone will be hating on React like they hate on jQuery now.

 _" Seriously dude, you're still using React? That slow, bloated pig that
creates a call stack 75 frames deep to change the label text of a button?
Sheesh, get with the times, and use _____.js! It rocks!"_

------
indexerror
Fantastic. Thank you so much for this.

------
scottydelta
this link seems broken: [https://bogdan-lyashenko.github.io/Under-the-hood-
ReactJS/pa...](https://bogdan-lyashenko.github.io/Under-the-hood-
ReactJS/part-2/book/Intro.md)

~~~
bliashenko
fixed, but it's still nothing there. I work on a big scheme for Fiber, it's
far from 'ready'...

------
pps
This is super cool, thanks, I'm eagerly waiting for comparison with fiber.

------
Jpoechill
Detail. A+

------
gfxl
Nice work, but some parts make as much sense as Lorem ipsum text. One of my
favorites so far:

> An instance of what should be created (03)? Component… right, but which one?
> Well, it’s a good point. No, not <ExampleApplication /> that’s 100% :) We
> actually should instantiate some internal class. Let’s check out the next
> scheme at first.

~~~
bliashenko
thanks, fixed that.

------
sAbakumoff
Wow, you really spent a lot of time of this, but why? What's the purpose? How
do React shenanigans can help me to be a better developer?

~~~
pknopf
You don't learn anything by studying other architectures?

~~~
adzm
For even more fun, compare with inferno

~~~
e1g
FWIW a React lead said Inferno is how they would've designed React if they had
to do it from scratch, and it's author joined Facebook to push React efforts
forward.

~~~
mst
So does that mean inferno is both theoretically better and already dead? :(

~~~
e1g
Hehe. I think it's Open Source at play: X publishes an innovative method, Y
iterates with a cleaner version benefiting from lessons-learnt, X says
"awesome, let's join forces!" and they live together happily thereafter.
Inferno passed over to another lead who's pushing it forward.

IMO this is a good outcome: there is some marginal value in yet another
"React-like but faster" library, but the same energy could help a lot more
people if applied directly to the source of the madness.

