Discussion on: Is VDom still faster?

View post

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.

Eckehard • Aug 24 '21

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.

Marc Ziel • Aug 24 '21 • Edited

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.

Eckehard • Aug 24 '21

Some years ago we would have named this "spaghetti code", today it´s called "multi-paradigm". I should remember this...

Marc Ziel • Aug 25 '21 • Edited

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.

Eckehard • Aug 25 '21

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.

Marc Ziel • Aug 25 '21 • Edited

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.

Even if a hook is well organized, using a hook in a pure function just makes the function impure

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:

function impure() {
  console.log("side effect");  // state of the world changed during the execution
}

function pure() {
  // this function just returns another function so it's still pure
  return () => console.log("side effect"); 
}

function Component() {
  useEffect(() => { // takes this side-effectful code out of the component
    console.log("side effect"); 
  })
  return "Still pure. Yay!"
  // technically it's impure since we call `useEffect` to register an effect
  // but we could theoretically do the same by returning it:
  // return { renderTree, effects: [logger] }
}

peerreynders • Aug 28 '21 • Edited

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.

That statement is bordering on self-delusion.

Haskell Programming from first principles — Chapter 29: IO - 29.6 Purity is losing meaning:

It’s common at this time to use the words “purely functional” or to talk about purity when one means without effects. This is inaccurate and not very useful as a definition …

Semantically, pedantically accurate
… What was originally meant when describing a pure functional programming language is that the semantics of the language would only be lambda calculus. …

Referential Tranparency
Referential transparency is something you are probably familiar with, even if you’ve never called it that before. Put casually, it means that any function, when given the same inputs, returns the same result. More precisely, an expression is referentially transparent when it can be replaced with its value without changing the behavior of a program.

One source of the confusion between purity as referential transparency and purity as pure lambda calculus could be that in a pure lambda calculus, referential transparency is assured. Thus, a pure lambda calculus is necessarily pure in the other sense as well.

The mistake people make with IO is that they conflate the effects with the semantics of the program.

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 use useState() instead of this.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.

Marc Ziel • Aug 29 '21 • Edited

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.

When you see Haskell do notation:

do { putStr "Hello"
   ; putStr " "
   ; putStr "world!"
   ; putStr "\n" }

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? do notation is just syntactic sugar that translates directly to monadic operations.

Dan Abramov:

Finally, if you’re a functional programming purist and feel uneasy about React relying on mutable state as an implementation detail, you might find it satisfactory that handling Hooks could be implemented in a pure way using algebraic effects (if JavaScript supported them).

again Dan Abramov:

conceptually you can think of useState() as of being a perform State() effect which is handled by React when executing your component. That would “explain” why React (the thing calling your component) can provide state to it (it’s above in the call stack, so it can provide the effect handler). Indeed, implementing state is one of the most common examples in the algebraic effect tutorials I’ve encountered.

Let's do some example to see what's this all about.

Having this component:

function Component() {
  const [name] = useState();
  const [greeting] = useState();
  return <p>{greeting}, {name}!</p>
}

we can see that it escapes outside its boundaries twice by calling useState. useState call 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:

function* Component() {
  const [name] = yield;
  const [greeting] = yield;
  return <p>{greeting}, {name}!</p>
}

It looks a bit weird but when you look at how it's used:

const iter = Component();
iter.next()
iter.next(["Greg"])
iter.next(["Hello"])

You'll see that it's just a curried function:

function Component() {
  return ([name]) => {
    return ([greeting]) => {
        return <p>{greeting}, {name}!</p>
    }
  }
}

That can be shortened to:

const Component = () => ([name]) => ([greeting]) => 
    <p>{greeting}, {name}!</p>

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, hook notation is like do notation - it doesn't make the code impure; it's just an abstraction that makes working with the code easier.

From React design principles:

React is pragmatic. It is driven by the needs of the products written at Facebook. While it is influenced by some paradigms that are not yet fully mainstream such as functional programming, staying accessible to a wide range of developers with different skills and experience levels is an explicit goal of the project.

and:

We try to provide elegant APIs where possible. We are much less concerned with the implementation being elegant. The real world is far from perfect, and to a reasonable extent we prefer to put the ugly code into the library if it means the user does not have to write it. When we evaluate new code, we are looking for an implementation that is correct, performant and affords a good developer experience. Elegance is secondary.

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

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.

peerreynders • Aug 29 '21

Haskell is like Java

The Curse of the Excluded Middle — "Mostly functional" programming does not work.

The ease with which you can define reusable abstractions over effects is why people often call Haskell the world's best imperative language.

do notation is just a language feature, not the defining characteristic of Haskell — being firmly based on lambda calculus is. The do notation 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).

var specs = {
  render: function() {
    return React.DOM.span(null, "I'm so custom");
  }
};

var Component = React.createClass(specs);

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:

React manages the component instances and their state that render against the VDOM.
To register a custom component one has to supply a set of functions (the specs specifying the behaviour for the custom component instances), each function handling one particular life cycle event. The render handler is mandatory while all the other events have default handlers. These life cycle handlers get access to React-managed component instance state via this.props and this.state (which is mutated via this.setState()) when they are invoked.

Even with hooks React's fundamental character is largely unchanged only that now there is only the render function (making it seem more functional) which in it's body has to somehow register/manage the handling of the other life cycle events.

you might find it satisfactory that handling Hooks could be implemented in a pure way using algebraic effects.

Algebraic Effects are reflected in the type system. That's why in Haskell input/out happens inside of the IO monad. 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.

As you can see it's just a pure function

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

Each lambda can only bind one parameter and can only accept one argument. Functions that require multiple arguments have multiple, nested heads. When you apply it once and eliminate the first (leftmost) head, the next one is applied and so on. This formulation was originally discovered by Moses Schönfinkel in the 1920s but was later rediscovered and named after Haskell Curry and is commonly called currying.

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, the IO monad.

Summing up, hook notation is like do notation - it doesn't make the code impure; it's just an abstraction that makes working with the code easier.

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.

React uses functional concepts that provide real benefits but serves them in a digestible form suited for plain JavaScript.

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.

Marc Ziel • Aug 31 '21 • Edited

The do notation 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.

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:

React is not a framework like Angular but just a library for building user interfaces

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.

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.

It's called createClass because it creates a class. It was needed because creating creating classes in ES5 is really awkward.

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.

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 React setState call and only React can change it. React guards the access to component state in similar way as Haskell guards access to State Monad.

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, the IO 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.

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.

Yeah, you can be very picky about functional programming and only recognize the following definition:

Functional programs contain no assignment statements, so variables, once given a value, never change. More generally, functional programs contain no side-effects at all. A function call can have no effect other than to compute its result.

But this makes you like this:

The functional programmer sounds rather like a mediæval monk, denying himself the pleasures of life in the hope that it will make him virtuous. To those more interested in material benefits, these “advantages” are totally unconvincing.

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.

peerreynders • Aug 31 '21 • Edited

When you compile your pure Haskell code the resulting machine code is imperative and effectful.

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.

React doesn't pretend to be functional.

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.

but "view framework" name is kind of already taken by another project.

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.

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.

Dan

@dan_abramov

@jpochtar @reactjs @angular I think React is a UI library. It’s possible that our definition of “UI” might be a bit broader than what people tend to consider “view layer”, but I also think it’s not a framework.

19:12 PM - 09 Aug 2018

but I also think it’s not a framework.

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.

It was needed because creating classes in ES5 is really awkward.

Did it return a constructor function? A factory function for component instances? At best it's bad naming because createComponent would 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.

Generators are pure functions as long as you don't mutate state within them.

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.

useState() serves the same purpose as State Monad.

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

But no, "outside world" cannot directly change the state

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

React guards the access to component state in similar way as Haskell guards access to State Monad.

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.

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.

So the the Curse of the Excluded Middle is just Erik Meijer ranting again? And he can rant.

The functional programmer sounds rather like a mediæval monk,

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:

React is not a framework — of course it is.
React is unopinionated — due to inversion of control it has a definite opinion, just not as severe as Angular.
React is functional in nature — it uses functions. So does the C language, neither of them is functional in the FP sense.
React is declarative — it manipulates the DOM so you don't have to. Meanwhile there are no benefits of declarative programming, it's just the usual BBoM; i.e. it's just an excuse to avoid learning how to manipulate the DOM or use something else that actually leverages the browser's strengths.

Alex Russell

@slightlylate

I'm not saying React was a mistake, exactly, but its apologists need to reckon honestly what it has done to the ecosystem. twitter.com/TheRealNooshu/…

09:57 AM - 29 Aug 2021

Matt Hobbs @TheRealNooshu
@slightlylate @AndyDavies @samthor That image tells quite a story doesn't it. That poor Moto G4 user! 😬 https://t.co/2CvGSowwqh

peerreynders • Aug 25 '21

The real goal here is declarative programming.

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.

Marc Ziel • Aug 25 '21 • Edited

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 3 and start building the view for state 1 from 0. Now you have all possible state changes covered with just 3 (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 = 100 possible 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:

Additionally, React has been out for about five years, and we want to make sure it stays relevant in the next five years. As Svelte, Angular, Glimmer, and others show, ahead-of-time compilation of components has a lot of future potential. Especially if it’s not limited to templates.

Eckehard • Aug 25 '21

Engineers have proved that bumblebees can't fly! Luckily the bumblebee does not know this....

Lito • Aug 25 '21

animal-dynamics.com/ad-blog/the-bu... 😛

peerreynders • Aug 26 '21

The original statement:

The real goal here is declarative programming.

… an excerpt from Wikipedia

… a style of building the structure and elements of computer programs—that expresses the logic of a computation without describing its control flow.

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:

Declarative - React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes.

So "declarative approach to building UIs" is double speak for "I can't be bothered dealing closely with the actual DOM - ever."

as you mentioned a better way is to optimize code at build time and React team is aware of that

I wouldn't hold my breath - Compiler Optimization Umbrella #9223.

Also Scheduling:

However the freedom to do something like this is why we prefer to have control over scheduling, and why setState() is asynchronous. Conceptually, we think of it as “scheduling an update”.

The control over scheduling would be harder for us to gain if we let the user directly compose views with a “push” based paradigm common in some variations of Functional Reactive Programming. We want to own the “glue” code.

i.e. the design philosophy prefers run time control over compile time commitment.

Marc Ziel • Aug 26 '21 • Edited

From the React landing page:

Declarative - React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes.

So "declarative approach to building UIs" is double speak for "I can't be bothered dealing closely with the actual DOM - ever."

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.