[grey-area]

Apps whose user interface is fully JS-driven are sometimes called Single Page Applications, and are in my opinion the future.

Can't wait for this trend to be over. In many cases it results in slower performance and it certainly makes rendering performance really uneven as the device is asked to do a lot more work. Plus you have to write half your code in is, the Go is just a glorified wrapper around the db here spitting out JSON.

This is not the future I want.

[zackify]

It definitely is the future. You wouldn't load all the JS at once, you split it up on each page. Combine this with devices getting faster and faster plus server side rendering and there's only the upside of instant page changes when using a service worker to load next pages ahead of time on the client. So you would rather not have faster sites then?

[noir_lord]

You can have a hybrid approach and it's one I've used for 4-5 years.

I bundle library.js (very slowly changing core libraries), bundle.js (common subset amongst the set of files passed) and then page/function-specific.js.

library.js very rarely changes, bundle.js changes less than I thought it would initially and page specific stuff is changed cheaply since the files are typically <2kb.

Since the code that gets worked on the most is page/function specific the entry points any bugs that do creep through are isolated to that page/function and everything else works fine (handy with JS where a bug in your entire site-bundle.js can break the whole application).

I've even split off heavy libraries into bundles that work with library.js so things like ckeditor and datatables can be included and just work without been bundled into the main library (lots of users will never use ckeditor, lots will never use datatables, pretty much only admin/managers will use both).

That way you get the benefits of an SPA (lots of interactivity, json stuff, passing data back and forth conventiently, reusable components, base 'classes' for viewmodels etc) without completely handing off everything to the client and it means you can do routing and such on the client still.

Since all the data that is passed back and forth is just JSON you can also bind the data on the initial page load and pass it down with the page on first load and then immediately bind it with subsequent updates coming in.

It's made it incredibly easy to refactor large applications as well since the backend is 'just' and API, communication is done over simple JSON structures and the end points can be re factored incrementally from one thing to another.

I'm not sure if the pattern has a specific name (I'm sure it does) and I'm certain I didn't originate it, it just seemed like a good fit for the problem domain I'm working in.

Back when I started doing this TypeScript wasn't really a thing and I both didn't trust myself (I wasn't a strong JS programmer) or JS (I didn't trust it for large projects).

[grey-area]

The evidence of actual sites in production disproves your assertion. Look at this site or the d language forum for speed. No need for to make a js frontend, and in many cases no need to load pages incrementally.

You can use plain Ajax and where appropriate while rendering server side. You can do incremental updates in the isolated cases where it is required very easily without moving everything to js on the client.