The idea behind a virtual DOM is clear: Build an in-memory representation of the dom and just apply the differences to the "real" DOM. This makes p...
For further actions, you may consider blocking this person and/or reporting abuse
VDOM has never been faster to execute than tightly hand crafted Javascript, but writing such code is a nightmare, and it's been much faster to build apps, component libraries etc with frameworks that use VDOM that still have great performance.
VDOM lets you have components which are re-runnable factories. When something changes you re-run the factory and it spits out VDOM nodes, these lightweight Javascript objects are then compared with the ones spit out last time and only the differences are applied.
Hand crafted reactive Javascript will always be faster than this, but at the cost of real complexity and much harder to reason with code.
Libraries like SolidJS work by making a much nicer reactive interface that still allows you to write only simple Javascript that knows which DOM elements to update when things change. In SolidJS components are never re-run after the initial mounting, instead reactive logic is used to change DOM attributes or nodes when things change in the state. This makes the code slightly more complex and introduces restrictions you must adhere to (for instance not using JS destructuring of
propsto components) compared to VDOM implementations.So you have libraries like SolidJS and Svelte (more of a modified language) which are looking to create highly reactive components and libraries like Inferno, Preact, React etc etc that use VDOM.
In widely touted benchmarks (I borrowed a slightly out of date one of Ryan Carniato's examples below - Ryan is the author of Solid) the two closest to native Javascript are Solid and Inferno. Given how fast these are it's hard to imagine needing to write native JS because it would be so much harder to reason with. From this we can see VDOM can be crazy fast and reactive can be crazy fast and you know what? React isn't in that top ranking but actually it's also still fast enough for most people.
So do we need VDOM? Well I think that principles like reactivity (with Hooks in React and signals in Solid for instance) really help us construct our applications. I won't be going back to hand crafted JS for sure...
In fact, there is a lot of code out there that is a nightmare, but does this mean, we can´t write good code in Javascript? Do we need a virtual DOM because people are not willing to learn to write better code?
We have done some really nice applications recently, that are directly working on the DOM. Just plain event based Javascript. And it came out they work like a charm.
Well yep, I can see that could happen. I think you should certainly write the code you need. If you need the best possible performance or you can easily reason with your problem then that could well be the best way to go. It's all about the mental models you need to apply and at which level you should apply them right? Whatever gets the job done well enough, fast enough sounds good to me.
Sure, but there are reasons, why people developed frameworks like Angular or React years ago. For me it seems, that things have changed over the last 5 years and many of the reasons are gone. But the frameworks still are there.
This is a very interesting idea to me. I’d like to hear more about it. Maybe you could write a new post about what changes over the past 5 years have made frameworks less vital. I would read it and click the heart.
I suppose there are good reasons for every side in this discussion. As there are different tasks to solve, different tools might be useful. Read more about the backgrounds here.
Best regards
Chart updated with last versions, vue 3.2 and compared with vanillajs.
You need to read more about it! VDOM is faster on large trees, so if you give a huge tree svelte and react then react vdom will be faster on small tress svelte is faster
If the use of VDOM was about performance everybody would be using Inferno by now - especially if they don't need to support native web views.
So React's popularity has little to do with performant VDOM - because React's VDOM implementation isn't that fast.
Doesn't matter All I said is that on huge trees react vdom is faster. If you want to know the reason why we even need vdom the answer is xml/html is the worst language to parse(slow) thats the reason people switched from soap api's to rest with json because the format is faster to parse then xml so in order to never need it again the next ui language on the web needs to be a syntax like CSS maybe all features of HTML merged over to CSS? Never mind... all I can say in order to fix this HTML6 should not even come out.
That's misinformation; browsers are extremely efficient at parsing HTML and the DOM isn't slow - Live DB Monster Demo.
REST is media format agnostic so JSON had nothing to do with it; in fact RESTful web services (2007) by Leonard Richardson, Sam Ruby used HTML - SOAP collapsed under the weight of the WS-Deathstar specifications - while only reinventing RPC in the process.
I think of SPA(-frameworks) the same as I think of SOAP - neither of them are of the Web.
CSS was introduced in 1996 to remove the presentational aspects from HTML (1993) - they are not going to merge them after 25 years of separation.
Who is comparing parsing speeds of HTML vs CSS?
Your original comment was about React (VDOM) being faster than Svelte on huge trees. SolidJS is faster than either of them and doesn't use VDOM.
Are there any tests or videos which can prove that Solid is faster on huge trees? I don't think it is.
JavaScript Frameworks, Performance Comparison 2020: Group 1 — The Performance Elite
Thats not what I asked you, I said show me prove that solid is faster on huge trees.
In what way are operations on 1_000 and 10_000 rows not representative?
A DOM document is a tree of DOM nodes - but perhaps those are not the trees you had in mind.
The tests do prove that React performance is "just OK" - but not really anything special to warrant a claim that a VDOM-based framework is needed for performance reasons.
I had exactly those in mind but this tests seem fishi to me.
Clone the repository and see for yourself…
I will lets look how the tests will be over 10k rows
Adding 10K rows is possibly not what most Websites do. And the initial question was not: who is the fastest number cruncher.
The question was: There are two systems in a pipeline to optimize the screen update:
If the browser engine is slow and stupid, a virtual DOM will be helpful in most cases. But if the browser engine is fast and smart, maybe it does a better job than a VDom. The Chrome core was written in C++, which could be faster than Javascript.
AND: the browser knows, what is visible on the screen, while the VDom does not. So, from the point of user experience, there is a good chance that a browser does a better job if he does not need to wait for a slow VDom.
I think, the only way to find out is to perform some tests with and without VDom active.
Could you give us more information about your background and expectation? What precisely blew your mind?
What´s your problem? Just tried to understand your previous answer.
VDOM is just an implementation detail. The real goal here is declarative programming.
DOM is imperative and statefull so we need some framework/library to transform our declarative code into imperative commands that DOM provides.
This translation can be done entirely at runtime with something like VDOM diffing but most of the work can be done ahead of time (at build/compile time) and that's the current trend.
Relying on the DOM for declarative updates (essentially by recreating the DOM tree whenever there's a change) isn't a good idea since the DOM wasn't created to work like this so there are lots of problems with this approach.
The issue is that React specifically and VDOM generally imposes a "run time cost" for the developer convenience of "declarative design".
Given that the browser is the native application and JavaScript is just (the highly optimized) automation language to coordinate user interaction, client-side development really needs a more lean and mean mindset (The Mobile Performance Inequality Gap, 2021).
Given that situation developer conveniences should not impose run time costs but instead rely on design time tools to compile to an effective machine representation - i.e. code that manipulates the DOM efficiently and effectively without relying on runtime tricks like VDOM.
In a way SolidJS is a move in that direction but there is room for improvement tooling-wise - the more work can be done at design/compile time the better.
The other issue is that the claim that "React is declarative" is widely publicized but largely unrealized in code bases and wouldn't hold up under close scrutiny. People see JSX tags and say - "Ooohh! It's declarative" ignoring the all the imperative JavaScript code surrounding and permeating it.
CSS is declarative and many developers hate it.
When you write a React component you're writing imperative code that generates declarative code (a description of a view a.k.a VDOM). But what's the value in this?
An app can be thought of as a state machine: you start at 0 and from there you can typically go to any other state and from that state to some different arbitrary state. For each of these states you have to create a UI view that represents a given state.
Doing this naively you'd have to create code that updates the view from all possible state changes. If you have just 0 (initial) + 3 states it gives
3 + 3 * 2 = 9(n^2) code paths you have to create and maintain.But you can be smart about it and when there's a change from, let's say, state 3 to state 1, instead of going there directly, you'll go state 3 -> state 0 -> state 1. In other words, when there's a state change you destroy the view for
state 3and start building the view for state 1 from 0. Now you have all possible state changes covered with just3(n) code paths.Unfortunately, destroying and rebuilding the DOM tree at every state change isn't a good idea because DOM is stateful and isn't optimized to work in this manner.
That's where React comes in. With React you need to create a component that can generate a description of a view for any given state and React will take care to efficiently update the DOM from arbitrary state x to arbitrary state y by comparing the descriptions for the view for both states that your component generated.
So, once again: it's not your component code that's declarative in React - it's the code that your component generates. In other words, React is declarative in the sense that React takes declarative description of the view (that your imperative component generates) and instructs DOM to render or update the view so that it matches the description. Reconciliation process can be thought of as a translation layer that takes declarative code and returns imperative instructions required to update the DOM to the described state.
Declarative approach is a must when you want to build a complex UI because otherwise your code would quickly became unmanageable (for just 10 states you'd have
10^2 = 100possible code paths) even though destroying the view and rebuilding from scratch is obviously slower than smooth transition from one state to the other.Technically you could destroy and rebuild the DOM on every change (and force browser vendors to optimize for that) but as you mentioned a better way is to optimize code at build time and React team is aware of that:
Engineers have proved that bumblebees can't fly! Luckily the bumblebee does not know this....
animal-dynamics.com/ad-blog/the-bu... 😛
The original statement:
… an excerpt from Wikipedia
Given that definition SQL seems like a good example of declarative programming. A statement expressed in Data Manipulation Language "declares" the nature of the data desired while the manner in which it is obtained is left entirely up to the RDBMS engine.
Now based on that example writing components containing imperative code to generate SQL statements (DML) is not declarative programming.
From the React landing page:
So "declarative approach to building UIs" is double speak for "I can't be bothered dealing closely with the actual DOM - ever."
I wouldn't hold my breath - Compiler Optimization Umbrella #9223.
Also Scheduling:
i.e. the design philosophy prefers run time control over compile time commitment.
I've just written a post about it here
But you can have stateful function components with hooks and using hooks makes a component impure, right? Technically yes, but in practice not really as I touched upon here.
That makes perfect sense. Thank you very much.
Just, I tried to find out, which paradigm REACT follows, but it seems, people have different oppinions on that point.
JavaScript is multi-paradigm and so is React. Locking yourself to just one paradigm for no good reason isn't practical.
Hooks allow to have stateful function components. With just stateless components you'd have to re-render the whole React tree on every change.
Hooks technically make components impure, but in practice they can be thought of as pure - hooks are there just for developer convenience.
A pure version of a "stateful" function component would require passing in state as argument and you'd have to return it along with effects and the rendered element tree. It would look pretty ugly.
Some years ago we would have named this "spaghetti code", today it´s called "multi-paradigm". I should remember this...
Are you suggesting that people who write React write spaghetti code? That was rude and haughty.
Hooks despite looking weird allow you to collocate all code for a given feature in one place (you can't do it with class components) so the code is more organized and manageable - it's the opposite of spaghetti code.
You shouldn't bash on features just because they didn't exactly fit the concepts you learned some years ago.
Conceptually React follows declarative functional paradigm (
UI = fn(state)) but at implementation level it makes compromises when it's beneficial from performance or DX standpoint since JS isn't a purely functional language.Sorry, i didn´t want to insult anybody. But we see a lot people praying about the welfare of functional programming these days and that people using other concepts are wasting their time with complicated and inefficient code.
Above, we learned, that "The real goal (of VDom) is declarative programming. DOM is imperative and statefull...", which means, that it would better apply to a imperative and stateful paradigm (-> OO). So, in this case, the "declarative approach" has some overhead.
It seems, there are more cases where the brave new world of functional programming has a high price, which makes a solution like a "hook" very appealing. It´s fully ok, even if people start using goto again. But then they should stop praying about "pure functions as a solution to everything" (or bashing people about "concepts they learned some years ago.")
Even if a hook is well organized, using a hook in a pure function just makes the function impure, so "Multi-paradigm" is just a nice wording for that.
Declarative approach isn't used as an optimization technique but to facilitate development of complex UIs that are both efficient and manageable as I explained here.
Using a hook actually allows a function to stay pure because it takes care of code that produces side-effects so that you don't have to call it inside of the function.
Compare the code:
That statement is bordering on self-delusion.
Haskell Programming from first principles — Chapter 29: IO - 29.6 Purity is losing meaning:
So even if we ignore side effects, stateful function components violate referential transparency which is part of what pure functions have to guarantee.
Hooks (
useState()in particular) give the stateful function components access to React-managed mutable state — so same inputs (i.e. function arguments), same results is not guaranteed. That state is stored inside a closure on a per component instance basis. Object instances and closures are duals of one another.All hooks did was replace
this.state, this.setState() with useState(). Stateful function components are no different than a render function on class-based components - they simply useuseState()instead ofthis.setState().So what React has accomplished is that everyone can still work in their comfort zone of class-based object orientation while pretending to be functional — Look ma, no classes, just functions.
When you see Haskell
donotation:you might say: Look ma, imperative statements and side effects - Haskell is like Java. But there is much more than what meets the eye, isn't it?
donotation is just syntactic sugar that translates directly to monadic operations.Dan Abramov:
again Dan Abramov:
Let's do some example to see what's this all about.
Having this component:
we can see that it escapes outside its boundaries twice by calling
useState.useStatecall yields control to React and React passes in some data and then gives control back to the component. Hm... yielding and then taking back control... It seems like a generator, so let's make it a generator:It looks a bit weird but when you look at how it's used:
You'll see that it's just a curried function:
That can be shortened to:
As you can see it's just a pure function - the only thing that is special about it is that it can be called in three separate steps and this doesn't break its purity. Yielding to the caller for more data in the middle of operation is completely legal - that's what IO Monad is doing under the hood.
Summing up,
hooknotation is likedonotation - it doesn't make the code impure; it's just an abstraction that makes working with the code easier.From React design principles:
and:
It's the other way around: React uses functional concepts that provide real benefits but serves them in a digestible form suited for plain JavaScript.
The Curse of the Excluded Middle — "Mostly functional" programming does not work.
do notation is just a language feature, not the defining characteristic of Haskell — being firmly based on lambda calculus is. The
donotation is just imperative sugar over a functional core. Haskell doesn't pretend to be imperative.Compare that to React which has a somewhat functional appearance (skin) over an essentially imperative core. React pretends to be functional.
In many ways React's true nature is best revealed by createReactClass (formerly
React.createClass).Even the naming is awkward — it really should have been
React.createComponent- but to seem more current they went with Class in ES5 to seem more respectable in context of a OO mainstream.The parameter being passed is a Crockford specification object:
specsspecifying the behaviour for the custom component instances), each function handling one particular life cycle event. Therenderhandler is mandatory while all the other events have default handlers. These life cycle handlers get access to React-managed component instance state viathis.propsandthis.state(which is mutated viathis.setState()) when they are invoked.Even with hooks React's fundamental character is largely unchanged only that now there is only the
renderfunction (making it seem more functional) which in it's body has to somehow register/manage the handling of the other life cycle events.Algebraic Effects are reflected in the type system. That's why in Haskell input/out happens inside of the
IOmonad. Algebraic effects have no reflection in the type system of JavaScript, TypeScript or Flow - so there is no rigor behind it, no containment or isolation, and it's just the Wild, Wild West.Generators are not pure functions. They are based on an internal mutable object/closure which means that they are not referentially transparent and therefore not pure.
And the whole "it's just a curried function" is just a sleight of hand. Currying solves a very specific problem.
Haskell Programming from First Principles — Chapter 1: Anything from Almost Nothing - 1.5 Beta Reduction, Free Variables
i.e. to have multi-argument functions in an environment that only allows each function to have a single argument.
useState()doesn't address that problem.useState()serves to have former component invocations affect later invocations and more importantly allows the "outside world" to have an effect on the component instance state. Even if this happens somewhat under the control of React there is no rigidly enforced compile and run time contract like there is with, for example, theIOmonad.I disagree, the comparison between do notation and hooks is seriously flawed at best. Hooks make functions impure and are just a React specific mechanism for code organization and perhaps reuse - that's it and in that capacity they may be considered an abstraction of some sort.
I continue to disagree - React also claims to be a "not a framework" when in fact it's manner of operation belies that claim; i.e. one has to take the claims made inside the React documentation with a bunch of salt.
When you compile your pure Haskell code the resulting machine code is imperative and effectful. What's more, Haskell compiler (GHC) is partly written in imperative languages like C. From your strict point of view that probably make it an impostor that pretends to be functional while having imperative core. ;)
React doesn't pretend to be functional. It clearly states that it is influenced by functional programming concepts and this is reflected in its API.
React can't have a fancy functional syntax that could please every purist because it isn't a compiled language but a view library.
Yes, a library. A library is just a bunch of code providing some functionality that can be shared and used easily in many applications. React fulfills that definition. It also fulfills the definition of a framework so you can call it a view framework if you wish, but "view framework" name is kind of already taken by another project.
But if you see a sentence:
and all you get from it is that "React is not a framework" then it's not the sentence that's wrong - it's your interpretation of the sentence.
It's called
createClassbecause it creates a class. It was needed because creating creating classes in ES5 is really awkward.useState()serves the same purpose as State Monad. The difference here is that state management is pushed out of your Haskell code and managed outside (Haskell compiler does the dirty work). React is just a bunch of JS code so the state is still kept within the realm of JavaScript. But no, "outside world" cannot directly change the state - even a component can't do it directly - all state changes must have to go through ReactsetStatecall and only React can change it. React guards the access to component state in similar way as Haskell guards access to State Monad.Yes, it's not Haskell, it's JS so you still can do some weird stuff but React is rigid enough and doesn't give you many options to mess things up.
Yeah, you can be very picky about functional programming and only recognize the following definition:
But this makes you like this:
If I can have more or less the same benefits as in a pure functional language but without having to switch from the most universal and ubiquitous language in the world that's a pretty good deal for me.
And during the compilation process the code is verified to comply with numerous constraints that permit the compiler to make some very specific and beneficial assumptions about the code.
I think here we have to differentiate between React and the React community. Now clearly React itself can't be responsible for the entire React ecosystem - but often the wording in the documentation or the statements by core members encourage certain notions in the community.
React's mental model is often oversimplified as
view = fn(state)— which is clearly functional as it implies view generation from state through transformation by a pure function.React actually doesn't work that way — there are two sources of state — props which is state as handed down from the owner component to the nested component and state which is "persisted and managed" by React on behalf of the component instance. So while components do generate the view they also can change state in the process - i.e. components are not enforced to be referentially transparent or in web terms idempotent. So React cannot grant the typical benefits or guarantees that a typical FP environment can.
React's reliance on immutability further feeds into the image of being functional.
Then there is the fact that the community often refers to Function Components as Functional Components.
So when it comes right down to it, one has to wonder how much of "hooks and stateful function components" actually had to do with necessary innovation or whether or not the whole "functional image" is about keeping React trendy within the web development community at large.
React predates Vue by about a year and despite its name Vue doesn't get to monopolize an entire tool category by virtue of how its name sounds.
It's not my interpretation, it's an active image being defended by a large portion of the React community. A framework, due to inversion of control, exerts a significant amount of design pressure on the structure of the "client side architecture". Calling React a library is disavowing the influence that React has as evidenced by countless sources describing React as unopinionated. Just because React is less constraining than Angular does not imply that it is "unopinionated" — it's just a matter of degree — React is very much opinionated, just not as much as Angular.
Did it return a constructor function? A factory function for component instances? At best it's bad naming because
createComponentwould have been more apt — at worst it's trendy naming because in 2013 "real programmers" used class-based object-orientation — not just plain functions and objects.Most generators used in JavaScript are not pure. And JavaScript has no controlled runtime support for lazy evaluation, so lazy evaluation is emulated with mutable state inside the function's closure.
"Purpose" perhaps but again without committing to any constraints. In order to preserve referential transparency functions operating within a state monad have a signature of
(state) => [state, result]. React function components could have easily adopted a similar signature. One benefit would have been that it would be trivial to micro test components without having to provide an entire "React environment" for the component to run in.And that's just the point — React does just enough to pander toward maintaining a "functional image" but doesn't commit to the necessary constraints that would afford developers the actual benefits of many FP techniques.
Of course it can - that is the whole principle of how third party libraries like Redux integrate themselves with the React component tree — especially since the introduction of hooks. And even before that the "outside world" invaded the component tree via Higher Order Components (connect, Provider pattern) which are all still "React Components".
There is no "guarding" of any constraints.
It maintains control for the purpose of detecting changes to component instance state and to maintain full control over view reconciliation and scheduling.
So the the Curse of the Excluded Middle is just Erik Meijer ranting again? And he can rant.
Frankly, I couldn't care less if React was functional or not — but I am getting tired of the pretentiousness exuded by it and a significant part of it's community.
For example wickedElements is not functional in nature at all but it is brilliant in the way it leverages JavaScript and the DOM ("the platform"). It is what it is and it is good at at it.
Meanwhile there seems to be a cult-like following around React unwilling to examine and evaluate the tool objectively but instead is willing to propagate half-truths:
A virtual DOM has still some benefits. It's easier to mutate than actual DOM and the abstraction allows for some sophisticated dev tools.
However, when it comes to performance, the overhead of a vDOM becomes problematic in terms of scalability. While interference between reconciler and layout engine are mostly taken care of by batching the changes, if the reconciliation takes longer than a render frame, things become jerky fast.
In any case, going sans vDOM as well as using it is no silver bullet, because the bottle necks are usually more in the reactive flow, which is why there are state management libraries like immer or frameworks like Solid.js that allow for fine-grained control over it.
Ten years back the browser landscape was still very inhomogenous. Creating Apps that could run on every computer needed tools like babel or forced to use a very limited set of commands that where common sense. And, Javascript was still a bit slow.
About 5 years ago (maybe a bit earlier), companies managed to syncrhonize their development, so today we can be pretty sure that Javascript will run on every current browser. There are still some minor differences, but the common sense is pretty broad.
Browser engines gained a lot of speed and possiblilties with HTML5, so the brower serves pretty well as a programming platform for all kinds of tools.
Javascript developed a lot from a simple scripting language to a full features programming tools. In parallel it is very fast today so it can compeed with compiled code.
I´m not sure that 5 years ago it was a good idea to create native JS apps. Maybe it was possible, but still not easy. Today, things are different. We can use JS to write native apps and can be pretty sure they will run on more or less any machine.
I started the journey with my own framework DML recently, and the results are pretty amazing without any virtual DOM and bulky toolchain. The project is still in it´s baby shoes, but develops very nicely. So, I´m pretty sure that VDom is pure overhead. But as we have learned, a VDom is necessary for declarative code only. As DML relies on the OO paradigm, it plays very smooth on the real DOM.
During that time period and to this day people are chasing "emulating the native experience" in the browser.
But even back in 2015 PPK wrote Web vs. native: let’s concede defeat:
And more recently A clean start for the web (also Second-guessing the modern web, If not SPAs, What?) - the "application web" needs to stop chasing the native experience and devise leaner ways of successfully working with the most hostile development platform in the world.
As it happens, I have experience in both.
Frankly, no matter what it is, I can optimize it to the mechanism, but the principle is different.
The main work of vdom is to create a data structure, and then make an algorithm based on the data structure.
We can't change the DOM tree, we can only reuse it as much as possible.
This is the difference between the two, but it is undeniable that they can both fastest.
After a some research and discussion I like to add another finding to the discussion, that might be enlighting.
I was ever wondering, what a VDom is good for, because I was using an Object Oriented Approach. Objects have a state, so it is easy to keep track of the state of an DOM element. The DOM itself is also stateful, so Objects and DOM work seamless together. As long a s an object know the reference of an DOM element, it does not even keep track of the element state, it can just read the element state directly.
Things are different with a functional approach. As functions are stateless (or should be stateless in FP), it is much harder to keep track of state changes. So, you need a complex system that manages states and state transistions.
Bottomline, Using an OOP-approach makes it much easier to access the DOM, while FP and the DOM are not a really good team. Nevertheless, there might be good reasons to use Functional Programming. But then you will need a VDom to manage your state changes efficiently!
There is a typo
cpableThx!
I'm guessing VDOM is still faster, but it isn't noticeable enough to use it (I once did a benchmark and I found that VDOM is ~0.00001612903ms faster).
As VDom adds some operations before an action is performed in the DOM, it cannot be faster - except you can save some unnecessary operation. So any benchmark depends much on your task.
But we see today, that modern browsers can remove unnecessary operations as well, so the questions is: Who performs better.
That is really an impressiv presentation of Sindre Osen Aarsaether, that just gets it to the point. Really amazing!