How are custom events in JavaScript different from simply calling regular functions?

The custom events in Javascript are an implementation of the observer-pattern, where the the listeners are grouped by the event-name.

Quote from Wikipedia:

What problems can the Observer design pattern solve?

The Observer pattern addresses the following problems:

• A one-to-many dependency between objects should be defined without making the objects tightly coupled.
• It should be ensured that when one object changes state an open-ended number of dependent objects are updated automatically.
• It should be possible that one object can notify an open-ended number of other objects.

Defining a one-to-many dependency between objects by defining one object (subject) that updates the state of dependent objects directly is inflexible because it couples the subject to particular dependent objects. Tightly coupled objects are hard to implement, change, test, and reuse because they refer to and know about (how to update) many different objects with different interfaces.

What solution does the Observer design pattern describe?

• Define Subject and Observer objects.
• so that when a subject changes state, all registered observers are notified and updated automatically.

The sole responsibility of a subject is to maintain a list of observers and to notify them of state changes by calling their update() operation. The responsibility of observers is to register (and unregister) themselves on a subject (to get notified of state changes) and to update their state (synchronize their state with subject's state) when they are notified. This makes subject and observers loosely coupled. Subject and observers have no explicit knowledge of each other. Observers can be added and removed independently at run-time. This notification-registration interaction is also known as publish-subscribe.

While the loosely coupled code with custom events is super flexible, the process-flow quickly can become opaque, if they are used in an unstructured and excessive way.

From MDN About custom events - they mainly used for creating synthetic events.

...Such events are commonly called synthetic events, as opposed to the events fired by the browser itself.

Synthetic event is a cross-browser wrapper around the browser’s native event. It gives the developer more control, and making it possible to add extra functionality which not exist in standard native events, like adding extra data, like suggested in David Walsh's article.

Another usage for synthetic events is creating event's pool, so you can reuse events instead of creating them from scratch. React is using that method under the hood.

This is a generic explanation, but I think it useful to understand the idea behind event driven architecture.

TL;DR

You can use custom events if you want your program to be extended by someone else according to their needs; usually this happens at some kind of framework level where you can't predict the final behavior of an application.

---

An event has three parts associated to it - defining, triggering and attaching.

The browser exposes a lot of inbuilt events like onload etc which can be used to customize the behavior of your browser. Here, the "defining" and "triggering" part is done by the browser (developer) for you. You as a consumer can extend it by attaching functions to it.

So, why did the browser think of creating an event and calling it onload? Why couldn't it call fetchMySuperContent? Because the browser wanted to give you an ability to extend it with any function(s) of your choice; and the best name it could give was onload because that's what is happening under the hood! You could magically attach it anywhere in your program to modify the behavior of the browser -- since it programmed to call anything that is attached to it. This ubiquity is what makes it super easy and useful. It can't guess that fetchMySuperContent is what you wanted to do; also someone else could do something else.

I think you could say this is the purpose of custom events as well; except here the author is the framework developer and consumer is someone like you or me to who wishes to extend it.

It is a nice example of the power of indirection, and separation of concern.