Virtual DOM is pure overhead (2018)

Strangely, after having read the article, now I am wondering why the React team can't just borrow some of these optimizations. It would take a massive overhaul, but it's not like React has ever stood still, it's constantly evolving and changing. I wouldn't be surprised if the under the hood stuff continues to change in a huge way, just like it did when React Fiber was completed.

At the end of the day, I've never spoken to a developer who was using React because it was fast, but because it was easy to use and understand.

The only reason you need that in the first place is because of how expensive updates in react are. It’s lack of true reactivity and user-controlled memoization lead to a ton of trashing.

Svelte on the other hand is as optimized as possible - update the data, modify the corresponding DOM pieces directly. There is no realistic use case where you’d need to spread an update over multiple frames.

And for me, both are unnecessary overcomplicated abstractions over mithril+js based classical MVC (not web-renamed one):

  class App {
    constructor() {
      this.message = 'Hello'
      this.foo = new Foo
      this.show_foo = true
    }
    bye() {
      this.message = 'Bye'
      this.show_foo = false
    }
  }

  class AppView {
    view({attrs:{app}}) {
      const attrs = {
        onclick: (e) => app.bye(),
      }
      return m('div.container', [
        m('h1', attrs, 'Hello!'),
        (app.show_foo
          ? m(FooView, {foo:app.foo}),
          : null),
        this.render_footer(app),
      ])
    }
    render_footer(app) {
      return m(…)
    }
  }

  window.app = new App

  m.mount(document.all.root, {
    view: () => m(AppView, {app}))
  })

As users of these web-frameworks it's not really noticeable if there is a V-DOM or not I think. The only thing that's really noticeable is the smaller bundle size (and maybe performance).

But what I really, really like about Svelte is how refined the experience is. I think that's just a natural progression though. React got invented, then it got clear that some things have to be done again and again (boilerplate code) and some parts of it are too complex. Things you can only notice in hindsight. Then Vue came along and fixed a lot of these issues (making it beginner friendlier and simpler). And now we have svelte which takes the learnings and hindsight of Vue and what React did in the meantime and improves upon them.

When projects grow, there is always this point where you have to start fighting the framework. The magic functions and implicit behaviour that makes them so easy to start with suddenly don't work for a use-case anymore and you have to almost hack a solution within the confines of the framework. Svelte on the other hand seems to be a lot more hands-off, a lot more vanilla javascript, where so far I didn't have the feeling I needed to fight it, even for ideas that were a lot more out of the box.

I started using Vue when it was there where Svelte is now, so I'm fairly confident the tooling and larger community support will be a lot better in 1 to 2 years ^^

>The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning.

Svelte's main point is that the performance claims of frameworks like React are just bullshit marketing-speak. That I agree with it. The value of JS UI frameworks in general, isn't in performance, but rather to provide a "declarative, state-driven UI development" because raw JS/HTML/CSS development is terrible and makes it easy to make terrible architectural decisions and write unmaintainable spaghetti code. In this way, whether you go with Vue or React or Angular, it makes no effin difference to performance.

But yes, there is overhead in managing the virtual DOM and yes, you can get yourself in trouble if you don't structure your application in line with how the framework expects you too.

>React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day.

React made a stronger claim. It wasn't just about React vs some Templating framework. React tried to argue that direct DOM mutations are expensive and that using virtual DOM will yield more performance. As a general claim, that is a bullshit claim.

>Their alternative is to add more complex compiler steps, which I’m sure could work great. However it’s awfully dogmatic to suggest that this is better simply because it eliminates one kind of not-strictly-necessary overhead.

And it's not a bad argument. The DOM is an abstraction and the underlying implementation is highly optimized. DOM mutations are not the expensive thing, it's the final render, and that part has had an enormous amount of work done to make it smart and fast. By the way, Flash had a great built-in rendering model. The Flash display list hierarchy was very well architected and it wouldn't re-render the entire page if only a part of it changed.

>But this isn’t how you sell a framework to programmers, in my opinion.

Claiming your framework is faster than the other guys IS how you sell a framework to programmers. That's how React and Vue were/are being sold.