leonardopainter

Well, I think when they moved away, they also increased the complexity of their applications as well.

My library (see other comments) has components that are about half the amount of code as react or solid and in pure javascript. The javascript shows exactly was is happening, as opposed to the "simplicity" of react that shows a pretend version of what is going on, then 5 years later people discover that is a bit of a problem and now we are onto the next library (solid?).

I wonder if I could have your opinion on my library, and why half the code, native performance is actually more complicated in the long-run. I don't know the answer at the moment. Documentation isn't complete... it is just web components. eg hello world just becomes a function like const component = hello('Andrew'); document.body.append(component); in the example on github. Anyway, the todo shows a more typical real world example I guess.

In terms of the placeholders in JSX, no they are escaped.

<img src='x' onerror='alert(1)'>

https://developer.mozilla.org/en-US/docs/Web/API/Element/inn...

One reason is probably that creating UIs programmatically was historically very cumbersome in JavaScript due to various issues that are no longer relevant. That means everything had to be HTML-based hybrids of some sort.

Using template literals to represent html is a security issue. If the state comes from the user, they can add script tags into the html. People try to solve this with tagged templates, but then if you forget the tag, you have a security issue again. Lit checks for this, but the fact that it has to check means it is less secure than not using tagged templates. There are libraries on github for creating sql using tagged templates which have the same security issue. The problem is that if your function works with both tagged templates and plain strings, when you forget to add the tag, you will never know.

That isn't a solution. Everybody moved away from this approach for web applications for good reasons.

The problems with knockout were:

very hacky syntax embedded into html. Sometimes you had to even use some kind of comment notation because there was no entry point into the html to add data properties or whatever it had.

it was slow.

the observables weren't variables you could use like plain JavaScript variables

it has the same problem as React - state-based algorithms are not very good ways to solve problems (if (showDialog && !open && ranOnce). You have to keep creating more variables to represent more states instead of using normal programming language concepts, and then all of the observables ping around and become complicated.

>If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges. Lints are not rounded edges!

Those linter warnings with React hooks show just how much of a disaster it is. All of the "simplicity" that comes with hooks is just complexity that is now completely out of sight, and only appears once the code is run in a linter. That is even worse than having the complexity in the code.

>The reason _why_ React has a virtual DOM is to enable more interesting relationships between your data and your presentation. Anyone can make a framework that makes the source code for an incrementing number look pretty!

Actually, that is only half the reason. You can do whatever you want in my library (github.com/thebinarysearchtree/artwork) and it doesn't have any kind of virtual DOM or whatever Lit does, because you just create elements with JavaScript. The second reason, that everyone just assumes is the default, is that React has to use HTML-like templates and not just JavaScript.

This article points out how ridiculous React is. This is just a simple timer, yet there are so many things you can get wrong. This article doesn't seem to even clear the interval so it runs forever. Solid solves some problems, but I don't know why everything has to be reactive. I have never understood it, I just noticed that from knockoutjs onwards, every front-end framework was based on automatically updating views based on state.

I create a library at github.com/thebinarysearchtree/artwork. To be honest, I don't know if it is going to work or not. It is just javascript with no reactivity. When I rewrote a fairly typical large application that you would find at most corporations (not a giant tech company application), every component ended up being about 50% of the code of react, with excellent performance.

The problem I have with it that 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.