Why should we use server side components to benefit from event handlers?

In Nextjs 13, why should we use client-side components to be able to use event handlers such as the onClick? I believe that at-end a server-side component will be rendered into a static HTML right?

so why can't we return a <button onclick="console.log(123)">Print123</button> from a server-side component as it will be rendered into a static HTML?

Short version

A server-side component assumes that all the changes and activity will occur server-side.

To put it another way, server-side components are not just static, they are inert, but can contain client-side components.

Ok, so 'why?'.

A react app pre-renders most if not all the stuff on screen, then 'hydrates' the dynamic bits by hooking them up to the events and JavaScript powering them.

Server-side, if any JavaScript or events are specified, the renderer should try to hook them up, run everything, and return a static form of the result. Sorta, React wizards are screaming at the screen right now.

So the server-side rendering sees onChange=alert('woot') and reads it as "Hook this JavaScript up to an event that doesn't exist and...😨!", and chokes.

What's the point then?

Anything that is time consuming, computationally expensive, or that you could build once, save and reuse again until something changes can be done server-side, so you're not relying upon the end-users TI83 level laptop to do it.

Say, your page needs to hit the database a dozen times to build a page. You could have the client-side code smash the API, but user's are icky and you don't want them near your nice clean servers.

(also something about keeping loading times, and bandwidth usage down)

So we have a client-side component hit the database API instead, from a server that might be in the same room as the DB. Then it pre-builds the static bits of itself, and hands the data off to client-side components that need it.