rembrant

I believe React is inherently terrible, rather than your reason. I think all libraries that try to abstract an underlying technology into something that it is not, and then also have to provide escape clauses for the abstraction because the user actually has to know how the underlying stuff works, are inherently broken. I also think state-based reactivity is a terrible way to reason about things because sometimes you don't want a certain part of the state to participate in the reactivity, and then at another time you do, so you have to add another state variable to say when it is OK for the other state variable to start participating in the state. It just isn't a good way to create algorithms.

The whole idea of React performing a bunch of tasks in the background and updating everything when it feels like is just all a bunch of silly magic. In fact, my state of JavaScript 2021 would be pretty damning, but because of the libraries used instead of JavaScript (like React and TypeScript), not because of JavaScript.

React presents a simple view of the world, but in doing so, you now have no idea what is actually happening, and you need to know that. This isn't like an array in JavaScript that is abstraction of an array in c that needs memory allocated and new arrays created and so on. You don't need to know how that works other than that the JavaScript version is a bit slower and you accept that. You need to know how all of the stuff React hides actually works to create your program.

In terms of hooks, there are so many "rules". Instead of seeing an API, the API is moved into the documentation and not visible in the code until run-time when you get one of the many errors like not adding a dependency to a hook, using a hook outside of some specific area, etc, etc. It isn't JavaScript at all, so you no longer have the tools of the language to freely use to make your life easier.

Proxies are cool. I use them in github.com/thebinarysearchtree/artwork which I haven't released. That libraries tag line is "you wanted less javascript and more html, so we delivered - artwork, the 100% javascript and css front-end framework". Anyway, I use proxies when I want a bunch of divs with classnames. You just do

  const { container, heading } = divs;

and then container is assigned to an HTMLDivElement <div class="container"></div> and the same type of thing for heading because divs is a proxy for an object with getters that can figure out the name of the variable you are destructing into and create a new element with that class name. It saves a lot of code.

  const container = document.createElement('div'); 
  container.className = 'container';
  const heading = document.createElement('div'); 
  heading.className = 'heading';

The other way you can create elements is just with a common:

  const heading = span({ title: artName, innerText: whatever });

etc so my web components have less code than react components, and run at native hand-written speed. Proxies aren't actually slow despite what I had read via google. In fact, the proxy is a bit faster than the naive implementation because it caches the divs and cloneNodes them.

For the second way of creating elements (the span example), instead of creating a function for every html or svg tag, I use another proxy so you can do:

  const { span, h3 } = html;

and it creates the span and h3 function dynamically. This saves me writing all the code for each tag and allows new tags to be used without me having to add them to the library.