unemployable

2 anni fadiscuss

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.

unemployable

2 anni fadiscuss

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

unemployable

3 anni fadiscuss

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.

unemployable

3 anni fadiscuss

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.

unemployable

4 anni fadiscuss

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.

unemployable

4 anni fadiscuss

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.

unemployable

4 anni fadiscuss

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

unemployable

4 anni fadiscuss

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

unemployable

4 anni fadiscuss

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

unemployable

4 anni fadiscuss

When you want to update the types, you have to run something to update the one file that contains the types (or put it in watch mode to do it automatically). You don't necessarily have to update the types straight away though as I use proxies to make everything dynamic.

The other tools I have seen that try to figure out SQL types do not accurately create types for things like left joins.

unemployable

4 anni fadiscuss

>Every ORM that I've worked with is a separate DSL that I need to learn

That is the point of Flyweight. The API is very small, and for everything else you use SQL. The ORM parses the SQL to figure out the types, and when you want it to, it maps the SQL into more complex data structures.

unemployable

4 anni fadiscuss

In an ORM, you will write

  include: ['posts']

in SQL, you will write

  join posts on p.authorId = a.id

I would argue an ORM is more about getting the flat structure of the result set into an hierarchical set of objects with more complex types.

unemployable

4 anni fadiscuss

You are missing the steps to get that select statement into JavaScript (running the database command, passing in the parameters, parsing the result, etc).

unemployable

4 anni fadiscuss

Flyweight parses SQL statements to generate a TypeScript API, uses convention to automatically map SQL into hierarchical data structures, and combines this with a simple CRUD API.

unemployable

4 anni fadiscuss

Everything in this article is true. As you can see by the comments in this thread, saying "I love TypeScript" is not enough to please the TypeScript cult. Nothing but complete devotion is required. You can say "it has its flaws" but don't mention them, just say that phrase to pretend you aren't biased.

The comments in this thread say that the way you are writing TypeScript is wrong. What they are advocating for is essentially turning TypeScript into Java in terms of its style. This is what good TypeScript codebases end up looking like. They don't look like JavaScript. You could take all of the type information out and they still wouldn't look like JavaScript.

I think that when people find that their ex-JavaScript, now TypeScript codebases have become Java codebases, many of them will realise they don't really like TypeScript anymore. If they are the people that said "You aren't professional if you don't use TypeScript", etc, then they are not welcome back into the JavaScript cult. If they are not one of those people, they must profess their hatred of TypeScript, and then we will let them back in.

Anyway, no matter what, you still have to work with the native APIs and so on, which just don't work with TypeScript. Take Web Components for example. You create a web component by defining a class, but you never instantiate the class yourself. You use document.createElement('my-component'). Good luck typing that. Good luck typing proxies.

I hate TypeScript.

unemployable

4 anni fadiscuss

Yeah that is the main problem with not using soft deletes. The question is though, if you delete a user, should the user's personal information still exist in your database, or does that violate some kind of privacy regulations? The idea of the deleted user's table is that it can be kept around and then pruned after x number of days to satisfy both privacy and undeleting. To keep the references around, I think one way might be to create two tables, so one table is used for all of the references and it stays around, and the other one gets deleted. Eg Account and User tables, or something.

unemployable

4 anni fadiscuss

Everybody always did soft deletes with the is_deleted column at companies I once worked for so that is what I would do. I noticed that a lot of bugs would occur this way because you would forget to add the is_deleted to the query somewhere. The queries were also longer due to the longer where clause and so on.

These days I use a deleted table as per the article as I decided it would be better to deal with the more complex undelete process. It keeps that process to a single section instead of spreading it all throughout your database.

Some of the suggestions here like "use views" don't really work for two reasons - sometimes the is_deleted check must be performed in the ON clause, not in the WHERE clause, and sometimes you want to count the deleted or show the deleted, while other times you don't.

unemployable

Submissions

Flyweight: A Node.js ORM Specifically for SQLite

Show HN: Quietone – search audio and video by transcript

Comparing React to VanillaJS

Artwork – a simple front-end framework with no HTML

Flyweight: An ORM for SQLite

comments