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.

I am working on the same problems as these people. I have had to implement polygon merging and simplification, spatial indexes, adding and removing elements on demand, and so on. I chose SVG "because it is cool", which is how I make all of my engineering decisions. I have used canvas before and it isn't really that much faster for a lot of things.

Reading through the first part of the series of posts, I see a few issues. Firstly, React seems like a terrible idea. I imagine the staff were just familiar with it. I use straight JavaScript and DOM manipulation. Secondly, it mentions stuttering at certain times. There should be no stuttering because you can just offload to web workers. There will just be delays in painting things.

I think SVG is fast enough to get the job done. I mean, you can even just use it without all of the DOM elements and make everything a big path and then manually handle the events if you really want.

Anyway, converting between GPS, mercator, viewbox, etc really sucks!

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.

It isn't possible because JavaScript doesn't have the required reflection abilities to understand what the anonymous function in

  users.Where(u => u.id == id); 

means. It can get a string representation, eg. 'u => u.id == id', but it has no access to id, so it won't know what to put in place of $id here:

  select * from users where id = $id

I used to use EF a lot, and it does feel very easy to write non-complex queries that traverse whatever abstraction it represents the database as, but ultimately, that abstraction is not really what the database is at all, and that can have some downsides.

I agree. JavaScript can be used on big projects as well, but the team probably has to be fairly small and stable. I much prefer writing in JavaScript. For libraries that I create, I add in TypeScript declaration files to improve auto-complete.

I feel like there are two different types of people, who work very differently. There are the highly collaborative people who work in large groups and use certain types of tools that have a large social aspect to them, and then there are the more individualistic people who work alone or in small teams and have a different set of tools.

I personally write code quickly, and only neat enough for myself to understand. When the code hampers my own ability to progress, I refactor it until it stays within a certain range of maintainability. On the other hand, some people write very structured code that is very easy to maintain, but they write it at a much slower pace. These are the more collaborative people, who are writing code that will be used and changed by many random people.

TypeScript is much slower to write than JavaScript.

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.

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

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.

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

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.

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.

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.

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.