Virtual DOM replacement with template literals as in hyperHTML

[janat08]

Do you want to request a feature or report a bug? feature

What is the current behavior? Usage of virtual DOM that prevents console errors, and direct DOM manipulation, meanwhile it is slower than suggested/example api which makes it obsolete altogether (and in real world terms too).

What is the expected behavior? Ability to use libraries that expect to manipulate DOM, as in styling frameworks, as in hyperHTML which has the server side, and also experimental native implementation.

[gaearon]

It’s hard to understand what you’re proposing.

The ability to create React elements (which you’re probably calling “virtual DOM”) and pass them around is a fundamental design decision in React. UI is a first-class value (just like a function or an object is), so you can do anything with it. While we may explore advanced compilation techniques that automatically reduce creation of unnecessary elements, I don’t see us abandoning the concept of elements themselves. They’re what make React components so expressive.

that prevents console errors

How is React preventing console errors? What does this mean?

meanwhile it is slower than suggested/example api which makes it obsolete altogether (and in real world terms too)

Again, I don’t understand what it is slower than, and what makes it obsolete. React is fast enough for the vast majority of use cases, and offers escape hatches for the minority of cases when it’s not. The speed of “virtual DOM diffing” (which you might be looking at) is often irrelevant in real applications because the majority of time is being spent in the application code.

I hope this is helpful! But I’ll close because it’s hard to understand what’s the actionable takeaway here. If you have specific issues with React (such as some problem with the console?) please file a bug report with an example that fails for you. If you’d like to propose new APIs, you’re welcome to contribute to the RFC process.

Thanks!

[janat08]

*as in hyperhtml, hyperhtml being the view library that replaces virtual DOM. Virtual DOM in vue may cause error stack trace to consist of nothing remotely related to user generated code.

I don't actually know what the todoMVC benchmark does, but there is one and it beats react there, otherwise the library itself, in regards to performnce, links list of stuff that updates fast which I suppose is to match virtual DOM speed.

[gaearon]

Sorry, I don’t think this discussion is going to be productive. I would suggest to learn how to profile apps in Chrome, and we can discuss specific performance issues with React (this is not a Vue repository) if you can show specific examples where it is being slow. TodoMVC was never meant to be a benchmark, as stated multiple times by its authors. Most apps are also larger than TodoMVC and face different kinds of performance problems than “reorder the list many many times”.

[janat08]

What I mean by virtual DOM preventing console errors is that they're useless (in my experience with vue). Point I was making about virtual DOM being slower than non-virtual DOM implementation (hyperHTML) is that at this point it only detracts with bad errors and making it difficult to use them libraries that want nothing more than to manipulate DOM.

[gaearon]

I haven’t worked with Vue so I can’t speak to its error reporting abilities, but it’s definitely something we care about in React:

https://reactjs.org/blog/2017/07/26/error-handling-in-react-16.html#component-stack-traces

If you find unhelpful errors coming from React we’d love to take a look and fix them.

React can work with libraries that manipulate the DOM if you abide by some rules. You can read about the nuances here: https://reactjs.org/docs/integrating-with-other-libraries.html#integrating-with-dom-manipulation-plugins

It might be that React is not the best library for your use case, and that’s fine. I’m glad you found the library that works well for you.