If you manage to make Svelte aware of what needs to be tracked, chances are that the resulting code will be more performant than if you roll your own with events or whatever. In part because it will use Svelte's runtime code that is already present in your app, in part because Svelte produces seriously optimized change tracking code, that would be hard to hand code all while keeping it human friendly. And in part because your change tracking targets will be more narrow.

Svelte's advantage here is that it indicates the need for an update at the place where the associated data is updated, instead of at each place the data is used. Then each template expression of reactive statement is able to check very quickly if it needs to rerender or not.

But you can still run into strange race conditions where the browser displays stale data depending on if some other unrelated code has caused a digest update to run after the buggy code or not.

The advantage of ngOnChanges() is that we get all the changes at once if the component has several @Input()s. However, if we have a single @Input() a setter is probably the better approach.

how it uses zones