I think you are looking at this in completely the wrong way. A GUI app and a web page are worlds apart so the exact same definition of MVC will never work for both. MVC is more about the ideal: separating certain parts of the app like display and logic.
In PHP (or the web in general), a View is the web page itself: the HTML output. It's not "live" as per your definition, but you simply click links to go back to the controller (i.e. another page request).
The Controller and Model is where things do differ, like you explained. In PHP the model tends to be the data layer, interacting with the database and so on. But it is still modelling the situation, and the controller still controls the application flow, if only once per page load.
So the name "Model-View-Controller" is perfectly logical, albeit a different implementation in GUI apps vs web apps.
'Framework' is a generic term.
Django is a web development framework built on top of Python. It provides commonly needed tools for creating a website: tools like connecting to a database layer, running a development server, rendering views, and routing requests to the correct controller are all provided by the framework.
Rails is a similar framework, just built on Ruby. Theoretically you could create a web app in just Python or just Ruby without the framework, but it would be a pain to rebuild all those tools from scratch.
Angular is a front-end framework for creating interactive HTML views out of standardized data structures - take a look at the section on their home page about 'wiring up the backend'. Angular does not have a way to 'save' data beyond basic Javascript tools like saving to cookies or local storage; it needs a backend system for that. It uses some of the same language to describe code organization (such as "MVC") but it is not providing the same tools.
Front-end frameworks do not do the same things as back-end frameworks, and indeed, sometimes one front-end framework doesn't do the same things as a different front-end framework.
Web developers use 'front-end' and 'back-end' frameworks for handling two different types of interaction with the user.
django can do both frontend as well as backend.
Unless I dramatically misunderstand Django's abilities, it cannot create dynamic in-page interactions such as modal pop-ups, live editing, etc. It can render HTML, yes; but it cannot make any text you type into the text box also appear on the page simultaneously.
Back-end frameworks such as Django, Rails, or Symphony are used to handle idempotent browser requests and HTTP calls. You load a page, the framework inspects the url that you have requested and builds the entirety of the page, piece by piece, and returns the whole thing to the browser. (APIs too)
There are some exceptions to this, but in general when you "navigate" around the internet, "back-end" systems are handling those requests. When you see the URL change and the whole browser window whites out for a moment, that is this type of navigation.
"Front-end" frameworks are more important for handling in-page user interactions. Things like modal pop-ups, loading more data via AJAX without loading a new page, submitting a form and displaying a message without redirecting, hover effects.
The simplest front-end framework that you can use is just HTML plus CSS. If you need more complex interactions, you can add Javascript to those tools. If your javascript is complicated or you are recreating common patterns, you might add jQuery for it's animation tools.
If you find yourself reimplementing an entire application (replacing the entire content of the page when you click certain links or take certain actions - a "Single Page App"), then you might use a Javascript framework like Angular to build up those interactions.
Rarely will you see a front-end-only web application. Just about any website or application will require some sort of persistent data storage - logins, page content, comments, product data, user-submitted content, anything. The backend framework then acts as a communication layer between the database and disk and the front end. It could do as little as providing a simple REST API for accessing/creating/editing data while the Javascript handles all templates and HTML, or it could build out HTML partials, and the Javascript front-end assembles them together, or it could assemble the entire page, and Javascript is used only for animations and occasional Ajax requests.
Best Answer
My experience is pretty much the opposite of yours. When doing small, quick things, a framework can "get in the way" a bit as you need to lay out your code in a certain way and think about things carefully before proceeding. By just jumping straight to
mysql_queryyou can have your prototype up and running much quicker.But for large, complex sites, carefully laying out code and really thinking about how you write your code is extremely important if you want a site that will be maintainable going forward.
In particular, adding
mysql_querycalls to random parts of the page cycle are generally a really bad idea. You might have one here and one there to begin with and it's no big deal, but before long you'd got dozen spread all over the place and you're wondering why your pages take 3 seconds just to render. Or you change your schema and seemingly unrelated sections of the site break for unknown reasons.