Podejście, które obecnie stosujesz, w sumie powoli zyskuje drugą młodość, dzięki rozwiązaniom pokroju Hotwire. Zresztą GitHub AFAIR od niemal zawsze korzystał z podobnej techniki.
Niemniej bardzo często backend sprowadzany jest głównie do REST API (lub innego rodzaju API, np. GraphQL), do którego będą wysyłały żądania różne aplikacje. Autoryzacja często przebiega przy użyciu takich rzeczy jak OAuth i/lub JWT, dzięki czemu całość komunikacji można zamknąć w żądania HTTP.
Często istnieje też warstwa tzw. middleendu, czyli takiego backendu przeznaczonego wyłącznie do generowania frontendu. Middleend jest odpowiedzialny za generowanie strony na serwerze oraz za komunikację właśnie z tym "prawdziwym" backendem (czyli API). I, prawdę mówiąc, dzisiaj chyba to podejście jest najpopularniejsze, za sprawą de facto fullstackowych rozwiązań pokroju Next.js (który może być zarówno middleendem, jak i pełnoprawnym backendem).
Można też zrobić wszystko po stronie frontendu i to on będzie bezpośrednio odpytywał API. Wówczas po stronie frontendowej wystarczy superprosty serwerek do wysłania początkowego HTML-a i tyle – cała reszta się dzieje w przeglądarce. Tutaj oczywiście wchodzą problemy z bezpieczeństwem, czyli jak zabezbieczyć dobrze tokeny dostępowe, żeby nie wyciekły – więc do apek z wrażliwymi danymi jakaś forma middleendu de facto musi być.
Ogólnie temat rzeka, ale rozwiązań na rynku jest na tyle dużo, że jakiegokolwiek podejścia byś nie użył, ktoś inny na pewno też go używa – i może nawet jakiś duży gracz.
A może jakoś tworzyć szablony w JS i pobierać np ajaxem dane z API. Tylko w tym przypadku co z odświeżaniem adresu w przeglądarce, cofaniem do poprzedniej strony, itd.
Są API do tego: