11 ms·

Show HN: Under the hood ReactJS

266 points by bliashenko 9y ago

beefsack 9y ago
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.
indexerror 9y ago
Fantastic. Thank you so much for this.
Jpoechill 9y ago
Detail. A+
sAbakumoff 9y ago
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 9y ago
  You don't learn anything by studying other architectures?
  - adzm 9y ago
    For even more fun, compare with inferno
    - e1g 9y ago
      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.
      - sAbakumoff 9y ago
        "Inferno 1.0 is really well written. It's how I would've rewritten React. I'd recommend reading its source to learn." - reading the source is much more effective than reading an article written by someone who read the source code.
        lazyasciiart 9y ago
        What are you doing on HN when you could be off reading source code?
        sAbakumoff 9y ago
        I don't think that your question makes any sense. I read both of HN and the source code.
        icebraining 9y ago
        And people can read both the article and the source code.
      - mst 9y ago
        So does that mean inferno is both theoretically better and already dead? :(
        e1g 9y ago
        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.
  - sAbakumoff 9y ago
    This is very specific architecture for a very specific product. I really don't think that I can learn anything from all these UML diagrams. I was just wondering what the author had in mind.
    - TimMurnaghan 9y ago
      Still not really a UML diagram. It's a flow chart. Of course if javascript programmers encapsulated things with actual objects then maybe UML would be applicable.
      - sAbakumoff 9y ago
        flow chart != UML activity diagram?
  - bliashenko 9y ago
    this's the answer.
deleted 9y ago
[deleted]
pps 9y ago
This is super cool, thanks, I'm eagerly waiting for comparison with fiber.
daliwali 9y ago
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
- jacobr 9y ago
  The place where complexity should be is exactly in third party library with a simple public API, avoiding as much complexity and optimizations as possible in your own application code.
  - daliwali 9y ago
    Why does the third party library need to be so complex? And why should there be complexity in the first place?
    - litzer 9y ago
      Not the OP but my answer to that is because something has to be complex in a large web app. Complexity can be avoided until the number of features reaches some threshold (I don't think there's any debate that it's impossible to avoid complexity entirely if the app is large enough). In those cases, which I think are the majority of use cases, a simple DOM utility like yours would be enough to hide complexity because there wasn't much to begin with. But some of the websites React powers exceed that feature threshold. For example, if multiple sections of a web app want to update at once, the author could leverage React's lifecycle hooks where needed and rely on its reconciler, but if using a simpler library, might have to explicitly schedule each update in a more hacky/less efficient way.
AriaMinaei 9y ago
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.
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
gfxl 9y ago
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 9y ago
  thanks, fixed that.
haterswillhate 9y ago
Reactjs coding is like copy paste these days. Whole army of FB fanatics who think they way of coding is the only way... Nah, relax a bit man. Give people freedom to code..
scottydelta 9y ago
this link seems broken: https://bogdan-lyashenko.github.io/Under-the-hood-ReactJS/part-2/book/Intro.md https://bogdan-lyashenko.github.io/Under-the-hood-ReactJS/pa...
- bliashenko 9y ago
  fixed, but it's still nothing there. I work on a big scheme for Fiber, it's far from 'ready'...
hardwaresofton 9y ago
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 9y ago
  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 9y ago
    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.
- ivanr 9y ago
  Perhaps you're right, but it would be useful if you mentioned those other choices here.
  - hardwaresofton 9y ago
    Sorry I actually purposefully didn't mention them because I didn't want it to seem like I was just trying to push my own favorite choice. Here are some options: Component libraries ------------------- 1) KnockoutJS (just data-binding, quite possibly the simplest I've seen) 2) Vue.JS (More complex, but one of the best sets of docs I've seen, fits in with the DOM model extremely well, few hacks, though I would have loved a simpler data-binding system) 3) Mithril.JS (super small, super fast, very simple. Transpilation tradeoff, it makes you just write the DOM as a JS function with elements like `m('div',[...])`. Have yet to use this one for a large project, but will very soon. Also has a little bit more support for the other thing you might need for a Single Page App. Full fledged frameworks ----------------------- 1) Ember (has been around a super long time, changes fast which is good and bad, and is great for large projects because it has a solid set of conventions)
jbucaran 9y ago
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.
rhapsodic 9y ago
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!"

266 points by bliashenko 9y ago

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.

indexerror 9y ago

Fantastic. Thank you so much for this.

Jpoechill 9y ago

Detail. A+

sAbakumoff 9y ago

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 9y ago
You don't learn anything by studying other architectures?
- adzm 9y ago
  For even more fun, compare with inferno
  - e1g 9y ago
    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.
    - sAbakumoff 9y ago
      "Inferno 1.0 is really well written. It's how I would've rewritten React. I'd recommend reading its source to learn." - reading the source is much more effective than reading an article written by someone who read the source code.
      - lazyasciiart 9y ago
        What are you doing on HN when you could be off reading source code?
        sAbakumoff 9y ago
        I don't think that your question makes any sense. I read both of HN and the source code.
        icebraining 9y ago
        And people can read both the article and the source code.
    - mst 9y ago
      So does that mean inferno is both theoretically better and already dead? :(
      - e1g 9y ago
        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.
- sAbakumoff 9y ago
  This is very specific architecture for a very specific product. I really don't think that I can learn anything from all these UML diagrams. I was just wondering what the author had in mind.
  - TimMurnaghan 9y ago
    Still not really a UML diagram. It's a flow chart. Of course if javascript programmers encapsulated things with actual objects then maybe UML would be applicable.
    - sAbakumoff 9y ago
      flow chart != UML activity diagram?
- bliashenko 9y ago
  this's the answer.

deleted 9y ago

[deleted]

pps 9y ago

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

daliwali 9y ago

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

jacobr 9y ago
The place where complexity should be is exactly in third party library with a simple public API, avoiding as much complexity and optimizations as possible in your own application code.
- daliwali 9y ago
  Why does the third party library need to be so complex? And why should there be complexity in the first place?
  - litzer 9y ago
    Not the OP but my answer to that is because something has to be complex in a large web app. Complexity can be avoided until the number of features reaches some threshold (I don't think there's any debate that it's impossible to avoid complexity entirely if the app is large enough). In those cases, which I think are the majority of use cases, a simple DOM utility like yours would be enough to hide complexity because there wasn't much to begin with. But some of the websites React powers exceed that feature threshold. For example, if multiple sections of a web app want to update at once, the author could leverage React's lifecycle hooks where needed and rely on its reconciler, but if using a simpler library, might have to explicitly schedule each update in a more hacky/less efficient way.

AriaMinaei 9y ago

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.

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

gfxl 9y ago

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 9y ago
thanks, fixed that.

haterswillhate 9y ago

Reactjs coding is like copy paste these days. Whole army of FB fanatics who think they way of coding is the only way... Nah, relax a bit man. Give people freedom to code..

scottydelta 9y ago

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

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

hardwaresofton 9y ago

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 9y ago
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 9y ago
  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.
ivanr 9y ago
Perhaps you're right, but it would be useful if you mentioned those other choices here.
- hardwaresofton 9y ago
  Sorry I actually purposefully didn't mention them because I didn't want it to seem like I was just trying to push my own favorite choice. Here are some options: Component libraries ------------------- 1) KnockoutJS (just data-binding, quite possibly the simplest I've seen) 2) Vue.JS (More complex, but one of the best sets of docs I've seen, fits in with the DOM model extremely well, few hacks, though I would have loved a simpler data-binding system) 3) Mithril.JS (super small, super fast, very simple. Transpilation tradeoff, it makes you just write the DOM as a JS function with elements like `m('div',[...])`. Have yet to use this one for a large project, but will very soon. Also has a little bit more support for the other thing you might need for a Single Page App. Full fledged frameworks ----------------------- 1) Ember (has been around a super long time, changes fast which is good and bad, and is great for large projects because it has a solid set of conventions)

jbucaran 9y ago

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.

rhapsodic 9y ago

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!"