unemployable

Memory leaks can occur when a component adds events to an element outside of the component (such as the window) and then gets removed from the DOM without removing the event handler from the window. This is solved in native Web Components by the mount/unmount methods where you can run code to remove event listeners when the component has been unmounted.

For other event listeners, they get removed when the DOM element is removed.

The frameworks do not solve this to any greater degree. They also just make everything invisible and behind-the-scenes and hard to debug due to their declarative nature, but that is another topic.

>If you want to get deeper into it, have a look at event bubbling and propagation.

In this example, the event is on the Window. There is no bubbling. It is already at the top level.

>Believe me, you don’t want to use the standard event handling API without a framework. Adding, deleting, cloning, firing, removing, fire once etc on many elements can have serious unwanted side effects.

I don't know what this means. The frameworks do not have much to do with this topic.

Exactly. All I care about is getting things done quickly and moving on. At university I was taught about "maintainable code", but in real life, I have never seen such code.

I have inherited code written by teams and it was not good quality. I just rewrote each section when I needed to change something. This seems like a much better approach then trying to write maintainable code - write code that can be thrown out and rewritten.

I found React to be the worst framework I have ever used. There is no chain of functions to debug or follow. Changing the state sets off a chain reaction of chaos that spreads throughout the codebase that can never be traced back to its origins.

Why do you think it is more complicated? The logic of the UI and application itself is the complicated part. That is the difference between a document and an application. The HTML ends up being turned into small pieces and has to be dynamically manipulated in an application. There are lots of if and else statements to create the HTML.

Applications do not really benefit from markup language. Artwork uses only JavaScript and CSS, and uses web components to enable scoped CSS and so on. It avoids classes as they are too much ceremony.

Projects using Artwork can be run without any transpiling or compiling thanks to import maps and CSS imports.

I am very happy with it. Maybe it is not for you, but I like it.

There is also Cloudflare D1, which is now in public alpha.

>I think this is something that pgsql got quite right

I don't think so. For example, pgsql had an array type before it got JSON, so the drivers can't automatically convert arrays that you want to insert into JSON. With my SQLite ORM, you can just insert arrays and objects and it knows to convert them automatically to JSON.

I like that SQLite just has a few primitive types. My ORM will be able to build on top of them. For example, JavaScript will soon be adding new date types (Temporal), and I will create new types for that, which will be stored as text ultimately.

>If there are many client programs sending SQL to the same database over a network

I believe this is a reference to enterprises that have different users querying the database directly with SQL that they wrote over a network to a central database.