1. 22

I had a lot of fun last weekend trying to build a simplest-possible UI framework, and learned a lot about why React (and friends) do things the way they do. I thought it was interesting, so here’s my first blog post in years – feedback of any kind very welcome! :)

  1.  

  2. 5

    There is somewhat of an analogy that could be made between a virtual dom and the rationale behind framebuffer double buffering. Googling reactjs double buffering shows a few people making that comment. It’s a very useful technique and luckily it’s being used beyond just react now in the JS world.

    1. 4

      I think that saying “algorithms that operate on the Virtual DOM” are a feature is analogous to saying “virtual DOM is a feature”. If the only way to do this stuff in a usable and fast way is to use a virtual DOM, then that’s a feature.

      1. 5

        Thanks for the comment!

        To your second point: The thing that surprised me and lead me to write this up is that Virtual DOMs are not “the only way to do this stuff in a fast and usable way”, they are the only way to build declarative UIs on the web, period. The declarative UI is the feature there to me, not the Virtual DOM implementation detail.

        I don’t know about your first sentence – do you consider algorithms that operate on an Array features of the Array, or features themselves? The algorithms React uses to make diffing fast are not a necessary part of using Virtual DOMs, they’re the tech React brings to the table to make sure your UI can become very complex and remain very responsive.

        1. 2

          do you consider algorithms that operate on an Array features of the Array, or features themselves?

          Both, in a way. If an algorithm requires a feature that arrays provide, like fast random access, then I would consider it a feature of an array. But if an algorithm works on linked lists the same as arrays, then I’d consider that a feature by itself.

          1. 1

            I can get on board with that. I updated the post title, and if I could fix the title on lobsters I would :)

        2. 2

          “Feature” is hard to define. :) But I still found this piece to be a really nice explanation of the motivating pressures for the virtual DOM to exist.

          1. 2

            Thanks! And yeah! “feature” was probably a poor word choice. “Virtual DOM is not an optimization” is really what I mean.

            edit: updated the post’s title, but can’t find out how to change it on Lobsters. Do you know where I can find that button?

            1. 1

              Yeah, Lobsters doesn’t have that sort of edit feature, though jcs is active and can change things when it’s important. This probably doesn’t really affect anything, but shrug.

        3. 2

          This page doesn’t work at all on current Safari (because “Const declarations are not supported in strict mode.”).

          1. 3

            Yeah sorry about that – I considered pulling Babel onto the page to make it work for all browsers, but for what was originally just a quick note to myself about stuff I’d learned, it looked like too much work. I’ll add a feature-detect to show a notice on older browsers and make the code samples at least readable.

            edit: to be clear – if the page “doesn’t work at all” for anyone on any browser please let me know, but it is pretty much just progressively-enhanced and all the content except the illustrative demos should be fully accessible on pretty much any browser.

            edit2: I went to set up babel-browser and learned that it’s a retired project. I guess the live-reloading demo use-cases is not common enough. I’m sticking with the es6 syntax for the demos for now though. I added a warning for incompatible browsers. Sorry :(

            1. 3

              Not to pick on you, but it’s amazing to me that somebody can try to justify a pure text web page not working in any browser in 2015, much less the current release of a major one.

              1. 5

                Seriously, I agree with you so hard on this :)

                I don’t have a defense, except that this started as notes-to-myself and I decided to share it. Also it’s not like it’s a SPA or something – code samples and demos might break but the text content should be fine back to IE6 or something.

          2. 2

            would it make sense for a virtual DOM style state diffing API to ever be built natively into browsers?

            1. 5

              Gee, I hope not. The benefits of the virtual DOM are:

              • declarative UI
              • unidirectional dataflow
              • support for arbitrary backends (react-canvas, react-native, server-side rendering)

              The virtual DOM is not the only way, or the best way to do this. The best way is probably self-adjusting computation (OCaml example). That’s going to be faster because you can avoid diffing altogether. We just don’t have a library like this in JavaScript (yet). But if/when we do, it will give you all the benefits of the virtual DOM without the drawbacks.

              Diffing is one reason that React is slower than libraries like Vue. On the other hand, Vue doesn’t lend itself to unidirectional dataflow the way React does. But it’s possible to have your cake and eat it too. It’s just going to take a little more technical sophistication than what we’ve seen so far in the universe of JavaScript frameworks.

              In my opinion the virtual DOM is just a stepping stone along the path to a great UI framework, and putting something like that into a standard is premature.

              1. 4

                Hmm. I don’t know exactly what this would look like, but I can imagine something like native support for a JSON representation of the DOM, and the browser being able to render and update from that directly. It’s an interesting idea, and I’m not sure if it makes sense or not!

                Virtual DOMs are not exactly a React innovation though – see JXON (2011?) for example.

              2. 2

                Interesting post :) Thanks for sharing!