[shooly]

> React/Vue/etc solve a specific problem: single-page application

That's not true. They solve the problem of requiring separate code paths for interactive elements - one for initial render and another for updates.

Previously the server rendered the initial HTML and then client JS updated it after e.g. user clicks a button, but with React/Vue/etc., it's merged into one code path because HTML is derived from the current state.

> Even multi billion companies hiring leetcode ninjas can't get acceptable user experience

Modern UX is bad because many front-end programmers fundamentally just do not care about the UX, it's not about the specific tech they use.

[austinthetaco]

> Modern UX is bad because many front-end programmers fundamentally just do not care about the UX, it's not about the specific tech they use.

This is untrue and is weird misunderstanding on your part. Most of modern UX and UI is designed to fit the needs of the customer for the frontend team/dev: the product or marketing or sales department. The user of the website is very rarely the customer for the dev.

[recursive]

Only react "solves" that. In vue component setup only runs during mount. Update is not a thing in the way react has it.

[shooly]

The point is that there's only one template and DOM is derived from that template. This concept is the same in both Vue, React and other popular component-based UI frameworks.

[epolanski]

> A Single-Page Application (SPA) is a web application or website that loads a single HTML page and dynamically updates its content as users interact with it, rather than loading entire new pages from the server.

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

And those libraries solve that.

Your other definition, can be fully implemented server side, Elixir's Phoenix does that. But it's not the only one.

[robertlagrant]

> 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

[throwaway7783]

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.

[robertlagrant]

Fair point, yes.

[shooly]

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.