artwork

too complex to hand-write the individual updates manually The other decision React made that was wrong was the need for JSX. They decided on JSX because they made a mistake many people make when just using the pure JavaScript API for creating components - they tried to make it nested like html using a fluent/chained call approach. As it turns out, trying to keep the nested HTML structure is not necessary for readability. My library is github.com/thebinarysearchtree/artwork After using it, it makes React look like SOAP vs JSON. It has less code, runs as fast as you can get, and everything is in your control because it is just web components with some functions to handle the repetitive parts.

t makes me uneasy is that ultimately you are creating content in JavaScript, which I don't think is ideal. The lack of HTML structure isn't a problem as devtools and so on show that. The problem is things like: const label = label('Email:'); I want the HTMLLabelElement variable to be called label... but that is the name of the function that creates it. Then there is the setText example on the github page... I just didn't want to write label.innerText.. h3.innerText... etc etc .innerText. Variadic arguments are not ideal though, and when you have lots of elements with lots of attributes, eg: const content = div({ className: 'content', title: 'whatever', innerText: 'something' }); it doesn't look like art, which is the point of the library. It is just hard to create content with JavaScript and not really the tool for the job. If I could solve that, I would be very happy with the library. It kind of needs JSX, but then it is back to having the JSX variable auto-update the state and well.. I guess that is why knockout and so on do it. Maybe I could do just plain HTML without state. So yeah, I don't know. I mean, it does end up being half the code. If you look at the todo example on my github page, and compare it to the one on React's homepage or solid's homepage, it is literally half the amount of code with native hand-written performance. This continues on to real-world components, it is just that.. I am a perfectionist I guess, and I want it to be elegant always. anyway.. I haven't even finished writing the documentation.

al_count is unknown, and then it becomes known with a query and must be included in the query state for optimisation, etc (don't try to get total_count second time, etc). That is the problem with React - state has timing issues. I hate it and don't use it anymore. I just use pure JavaScript github.com/thebinarysearchtree/artwork. Half the code of react with orders of magnitude more performance just by using standard JavaScript stuff. It is hard to argue with that, but people will try until it can't be denied.

> query updates state updates -> url / history updates >A library that let's me focus on business logic rather than boilerplate or implementation details is one that I want to continue using. From my experience, these implementation details are important. The library I use is less code than React and shows the implementation details so you know what is happening. >The [rules of hooks][1] that React provides is just two items That definitely isn't correct. It is missing the warnings about dependencies, where async methods can run, and a lot more. There is a list of eslint warnings somewhere. There are a lot of rules of React and hooks and the different types of hooks and they are all in the documentation and not visible in the code. The order of your setState calls is important, you can't use async in certain places, the state has to be assumed to be stale unless you do setState(a => a + 1) etc. It is quite frankly ridiculous. There is so much happening that is all hidden in magic. Bluntly, I think it is all complete garbage that is more complex than it should be and there are now so many people writing incompatible React instead of standard JavaScript that works for everybody. I just find it hard to believe that there is anybody who has written a large project in React and has come away with any conclusion other than that React is complete and utter garbage. It is a failure and it will not stand the test of time. The only people who could think otherwise: have some kind of cocoon set up by a large tech company and they basically just write demo code all day, or they haven't worked with React long enough. My library, which I have used to rewrite a large application with, is less code, faster, and easier to understand. I proved that React is complete garbage to myself by doing that.

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