It sounds as though you are already set on making each system a single page application. Is there some reason for this beside it being cool and trendy?
If you go the SPA route, you will need developers who are well versed in whichever JS frameworks you decide to use.
Most applications can be created in the more classic approach, with JS being limited to what is needed for each page. Those pages can still have crazy dynamic controls, but generally the idea is to keep the chaos to a minimum.
The best systems are clean and straightforwards. This lends well towards a classic design approach.
My recommendation would be to not make a SPA, and to just use jQuery and the pile of widgets that utilize it. Your application will end up running faster and using less memory as a result. SPA memory leaks are a *.
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... )
That's some interesting points you are making. Just one question:
> 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.
In html/css are you able to position an element on the page exactly where you want? I am doing at the moment some web development for maths exercises, and I couldn't manage to get the positioning right with pure html/css, so I had to resort to:
$("#my_element").offset({"left":x,"top":y});
The positioning I want is something non trivial because the elements are positioned with respect to each other.
I am just nitpicking here, on overall I think your comment is very informative.
If you go the SPA route, you will need developers who are well versed in whichever JS frameworks you decide to use.
Most applications can be created in the more classic approach, with JS being limited to what is needed for each page. Those pages can still have crazy dynamic controls, but generally the idea is to keep the chaos to a minimum.
The best systems are clean and straightforwards. This lends well towards a classic design approach.
My recommendation would be to not make a SPA, and to just use jQuery and the pile of widgets that utilize it. Your application will end up running faster and using less memory as a result. SPA memory leaks are a *.