My name is Matteo and I'm a cloud solution architect and tech enthusiast. In my spare time, I work on open source software as much as I can. I simply enjoy writing software that is actually useful.
I think you misunderstood what SPA and MPA really mean.
A single page application is not just a website that can fit in a single HTML and adapt itself to the screen (this is just responsiveness, MPAs can use it too) but rather it is an application that can leave entirely on the browser, requiring a static asset download only for the first page request (not counting local cache) and then modify itself through DOM manipulation, simulating a multi-page app, with multiple routes and whatnot, but without actually relying on a web server to serve all the pages and without the need to reload in order to change the view. Trello or Google Docs are indeed SPAs but Facebook, for instance, is not, as it reloads the page when you visit a different URL.
SPA can (and typically MUST) have multiple "pages", or routes as they are called, the key difference is that each page is actually being rendered directly by the client and not on the server, which makes SPAs able to navigate quickly and swiftly because no network request must be made.
A multi-page application is a website where every URL (or route inside the app) is tied to a particular page (or HTML file) served by a web server. They are slower, because you have to request and download HTML and static assets for every page (again, you can cache it but that's not the point) but they are easier to optimize (you can cache rendered pages on the server and ease the browser of some load) and the first load is faster (in SPAs, views have to be built client-side through JavaScript, which increases loading time for the first page).
Another thing you missed is that while MPAs can (but usually are not) be built of single standalone HTML file, one for each page, SPAs views are much more fragmented since you normally split your UI in multiple, composable fragments called components. Which make it easier to reuse and organize code, but also increases your codebase size.
Again, I think you're wrong when you say that SPA development is leaner and faster (but I think it's correlated to the misunderstanding of what an SPA is), since you can't just have some JS laying around and imported into your HTML, but you actually have multiple JS files containing custom components that must be imported, bundled (alongside your dependencies, and this typically involves learning how to operate a module bundler like Webpack) and minified.
Finally, a quick note on SEO. While it's true that SPAs are more difficult to SE-optimize, search engines like Google can now crawl JS-generated contents without problems and SPA rankings have much improved over the past few years. I would use an MPA only for sites with long-lasting contents (like blogs for example), but for the rest, there is not so much difference between SPAs and MPAs nowadays, SEO-wise.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think you misunderstood what SPA and MPA really mean.
A single page application is not just a website that can fit in a single HTML and adapt itself to the screen (this is just responsiveness, MPAs can use it too) but rather it is an application that can leave entirely on the browser, requiring a static asset download only for the first page request (not counting local cache) and then modify itself through DOM manipulation, simulating a multi-page app, with multiple routes and whatnot, but without actually relying on a web server to serve all the pages and without the need to reload in order to change the view. Trello or Google Docs are indeed SPAs but Facebook, for instance, is not, as it reloads the page when you visit a different URL.
SPA can (and typically MUST) have multiple "pages", or routes as they are called, the key difference is that each page is actually being rendered directly by the client and not on the server, which makes SPAs able to navigate quickly and swiftly because no network request must be made.
A multi-page application is a website where every URL (or route inside the app) is tied to a particular page (or HTML file) served by a web server. They are slower, because you have to request and download HTML and static assets for every page (again, you can cache it but that's not the point) but they are easier to optimize (you can cache rendered pages on the server and ease the browser of some load) and the first load is faster (in SPAs, views have to be built client-side through JavaScript, which increases loading time for the first page).
Another thing you missed is that while MPAs can (but usually are not) be built of single standalone HTML file, one for each page, SPAs views are much more fragmented since you normally split your UI in multiple, composable fragments called components. Which make it easier to reuse and organize code, but also increases your codebase size.
Again, I think you're wrong when you say that SPA development is leaner and faster (but I think it's correlated to the misunderstanding of what an SPA is), since you can't just have some JS laying around and imported into your HTML, but you actually have multiple JS files containing custom components that must be imported, bundled (alongside your dependencies, and this typically involves learning how to operate a module bundler like Webpack) and minified.
Finally, a quick note on SEO. While it's true that SPAs are more difficult to SE-optimize, search engines like Google can now crawl JS-generated contents without problems and SPA rankings have much improved over the past few years. I would use an MPA only for sites with long-lasting contents (like blogs for example), but for the rest, there is not so much difference between SPAs and MPAs nowadays, SEO-wise.