Visual Basic controls are more like React components, I think.

ECS is, traditionally, just a way to dynamically add behaviour (components) into "blank slate" entities.

Instead of making a EvilMonster class in a game you just have it as a conceptual entity (normally it's just an integer, like a database id) associated with a bunch of components (normally just plain structs) and their parameters: Renderable, RigidBody, Collider, HasEnergy, HasTransform, AudioEmitter, etc.

You can stitch entities and components together using either code or some external data source. The "S" part of ECS is called the system, and it implements the behaviour defined by components.

The upsides of this IMO is that this is a fantastic way to structure your code. The data-oriented aspect is also great for enabling non-coders to assembly complex entities. And some other clever people (such as the sibling answer) found out this is also a great optimisation technique.

There are multiple implementations, of course, so people have different opinions.

I wrote a comment on another post where I explain the cache optimization benefits of ECS, https://news.ycombinator.com/item?id=21674818

Ecs is more like a database.

ECS is all these things and none of these things. It's several separate concepts under the same name; different applications/games pick different pieces of it.

It's kind of meta, really; you can imagine ECS itself as an entity, and different meanings of it as different components that could be included in it.

ECS is meta? Love the recursive definition ;)