upvote
> That's the definition, I didn't made it up.

Your prior claim was that they only solve one problem, not about a definition. They solve several problems:

- less data can move over the wire compared to sending a full page every time (this is in your definition, and is definitely not always true, as sometimes REST APIs can return far more data than what's needed to render the screen)

- the same REST/data API can serve your website and other consumers, e.g. any native mobile apps or third party API consumers

- you can write tests for your frontend, e.g. you can unit test components' behaviour and style in isolation

- the frontend can also work, or at least respond usefully to the user, when the network or the backend are not working

reply
That second point is almost never true " the same REST/data API can serve your website and other consumers, e.g. any native mobile apps or third party API consumers"

In a reasonably complex application, each interface ends up needing its own shape of optimized APIs. Otherwise the clients become very complex munging/reshaping data or making too many API calls, throwing away a lot of data etc.

reply
You said, that React/Vue/etc. solve a specific problem: SPAs - that's not accurate. That's not the problem they solve.

According to what you said, CSS also solves the problem of making an SPA because you could "switch pages" by changing CSS class names on `body`. But if someone asked what CSS is you're not gonna answer "you use CSS to make an SPA", even though _technically_ you can use it to make an SPA.

reply