There are two different meanings for rendering, which is probably what confuses you.
Angular can take a piece of 'raw' information and 'render' the DOM elements required to display that data. The data could be, for example, a JavaScript object, which could be fetched as a JSON object from some API.
Rendering on servers vs client
In the more traditional approach, the HTML code comes 'pre-rendered' from the server. That means the server contains static HTML (just an HTML file that you could have typed in Notepad), or a server side script like PHP, which would "render" the HTML code with all the data in it. The server returns this HTML source code and the browser just "renders" it.
So "rendering on the server" means taking templates and data and combining them into raw source code.
And "rendering on the client" traditionally means taking that HTML source code and displaying it on the screen. Angular uses a third variation, which means doing DOM manipulation to "render" the data into the document. But I'll get to that later.
So server side rendering doesn't mean (now or ever before) that the actual display, the page that you look at, is rendered on the server. Not even the DOM is rendered on the server. The server just renders the textual HTML source code from the data it fetched, and the client (the browser itself) still generates the DOM and does the graphical rendering of the page.
And PHP therefore also doesn't respond to a button click directly. It only responds to HTTP requests, which can originate from an URL being typed in, a link being visited, a form being posted, or an AJAX request being performed.
HTML has built-in behavior
Traditional HTML has built-in behavior, which is why it could work without any client side scripting. A normal hyperlink is not clickable because of the script, but because the browser knows this element and its intention. So the logic of hopping from one page to the next is built-in in the browser itself. Same goes for forms. The browser knows that the data of a form should be sent to a server when you click the submit button. All you do in HTML is define (in the form attributes) what the URL is, the method, and which button to press to send the information. Again, no scripting needed.
Client side JavaScript can manipulate an already loaded page
The client side process is actually a two step process. First, the HTML source code is parsed and transformed into a DOM document, a list of in-memory objects containing information about the elements.
This document is then rendered (displayed) on the screen.
JavaScript (and that includes jQuery or Angular too), can work with these in-memory objects. It can bind events to them, so you can validate form input before sending it (saving the time of doing the round trip, server side checking, and parsing a complete response page), or respond to the click on any element. And you can even manipulate the objects themselves by just changing their contents, their appearance, removing them, or adding new ones.
So JavaScript's approach seems to be somewhat in between. You don't have to actually draw the changes you want, but you don't have to rely on HTML loading either. You have direct access to the objects, and any change you make to them automatically reflected on the display by the browser. So you can insert an extra element object and it will automagically appear on the screen.
And that is what makes JavaScript so fast and powerful. This approach is more direct than loading a big chunk of HTML from the server. So in the old days, you could just hop from one page to the next, and the whole page would need to be reloaded and re-rendered. With JavaScript, you could do small interactions, and with AJAX you could get pieces of information from an external source and display that information on the page without having to reload the entire page.
NB. AJAX by the way is also not very new. It was invented years ago by Microsoft to build a rich, web-based version of Outlook. The X in AJAX stands for XML, which is nowadays replaced by JSON as the notation of choice for communicating these pieces of information.
Angular 'hides' this DOM manipulation
Angular is just a framework that abstracts all this DOM manipulation that JavaScript can do. It lets you put markers in the HTML, and manipulate object data in JavaScript, and it will automatically put those together to update the page. This makes it easier to build a web application on a high level. You just have to worry about the design and the data, and much of the technicality to put them together is taken out.
Apart from that, Angular is not more than any other way of JavaScript DOM manipulation. It just lets you mess with the document that is currently loaded, something that a server side script cannot do.
However, in most cases the server (and the server side scripts) still plays an important role. It is this server side process that now 'renders' the JSON data that is fetched by your Angular application. That is, of course, unless you have some application that doesn't require any additional data to be loaded from anywhere else.
