The basic structure of the page should be simple div based layout enhanced with CSS. Any data that must be rendered in JS ( such as dynamic tables ) can be done by outputting the data in JSON format into the page, and then calling the JS to construct the table. This is faster than adding a calling to a JSON resource to get the data for the table. It allows data and page structure to be sent to the frontend all at once.
The rendered html code can itself be created using a backend HTML templating system. There are many available. If you want to go hog wild with JS you could use NodeJS on the backend too; although it isn't well suited to unit testing imo. Important thing here is to ensure developers don't put HTML output into the middle of code. Options and rendered values should be passed into a hash of some sort that is passed into template rendering. Templates can embed templates etc... Might be acceptable to render SSI includes into your files for some purposes.
Note that JS related to each page should be contained within a single JS file, rather then embedded on the page, so that it can be cached by the browser. ( good cache expiration rules should be used in production so that the JS does in fact get cached for a while )
Toolbars / popups / etc can all be done via straight JS, but you should use some template language in order to create them, rather than manually making JS calls to create each node.
If at all possible, page layout should be reused on multiple pages, so that overall containing style can potentially be changed later separately from the complex add in JS functionality.
An icon sprite grid should be used for all icons rather than using individual icons.
Among other reasons for using different pages instead of SPA:
1. Can use real URLs for different reachable places in the system, and those can be bookmarked.
2. No additional hackery is needed to be able to reach the same state besides URL
3. You can unit test individual pages for functionality
4. People can concurrently edit different pages without needing to alter the same files.
In the backend, a routing engine should be used that directs calls to different modules depending on where you are in the system. Generally it is easiest to have them be in different files so that you can alter them independently. ( avoid merge conflicts... )