Do you browse SO with JavaScript disabled?
You can, but voting etc. break.
Google can crawl React.
And apparently you can run React on the server too or instead.
So I don’t know that it’s a non-starter – I gather it is a modern standard.
Well that wasn’t the point though, the fact that it’s single-page isn’t much relevant, those are a packaging and deployment details – various forms of caching.
What’s more relevant IMO, i.e. to the estimate of the implementation time, were as mentioned here.
The above, the URL I posted, is a demo – with no real web server or database. For that demo, my front ends is bundled together with a simulated backend via a simulated REST API, and that back-end is just TypeScript reading and writing some data in memory in your browser – the whole thing is physically just a static web page without a real database – my object was to prototype the UI.
I assume that in the real thing (i.e. if there were a real server for this application) then any page URL could be dual-purpose, i.e. that:
- If a browser requests a page (e.g. from a bookmark) then it’s asking for HTML (in its accept header), and the server complies by returning the app and the data for that page.
- Or if the app is already loaded and requests a page (e.g. because the user clicks on a link within a page), then it requests just JSON (rather than html) from the server, and the server returns just that.
It’s really neat IMO.
But it’s wandering off-topic – because you decided to implement (and estimate) something different.
Still, as I said, I think a short implementation time (i.e. within “6-8 weeks”) is feasible in theory – if I were optimistic, and assuming a small number of dedicated developers, and an already-defined UI to sprint with. Which seems to me the same ballpark as a previous estimate i.e.: