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 *.

> It sounds as though you are already set on making each system a single page application.

No, not really.

> My recommendation would be to not make a SPA, and to just use jQuery and the pile of widgets that utilize it.

So hand crafted html? Or would you render html server side? How?

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.

Angular 1.x won't magically stop working when Angular 2.0 is released. The upgrade path from 1.x to 2.0 is not available/clear/whatever but that doesn't mean that 1.x isn't the best choice right now.

> Angular 1.x won't magically stop working when Angular 2.0 is released.

But it will soon become older and older and with the info we have now it seems there won't ever be a way to port the code to 2.x. So that would make it a bad choice for a new project with a lifespan of 5/6 years.

It is way to early to say there isn't a way to port to 2.0. 2.0 doesn't even exist.

Again, the code will not stop working magically just because your code is 5/6 years old.

> It is way to early to say there isn't a way to port to 2.0. 2.0 doesn't even exist.

That is not what I sad. What I sad is that with the info we have now it seems there won't ever be a way to port the code to 2.x.

The code of 2.x we saw is completely different from 1.x.

> Again, the code will not stop working magically just because your code is 5/6 years old.

You are right, but "the problem is future proofing. What happens when Facebook releases its Oculus Rift browser and I'm still stuck on Angular 1.2 because of my IE8 support, but only 2.0 exploits the Rift properly? What happens when candidates for jobs stop knowing how to use 1.x? What happens when I have to give this technology to non-FEDs who find themselves confused by the conflicting documentation and version-less community code? (e.g. stack overflow snippets that require 2.x but do not say so)? I've seen these problems with other frameworks outside the front end space (e.g. Spring)."¹

I have been there as well, and I don't want to get there again. At least not willingly.

¹http://www.breck-mckye.com/blog/2014/12/the-state-of-javascr...

It seems like you're fairly uncertain of the JS landscape. Just because of that I say you should use straight up jQuery. jQuery + widgets is rock solid.

I would never commit to a framework like Angular/React without understanding what SPAs are, their tradeoffs, their alternatives, and their limitations.

It also happens that jQuery probably fits your use case the best. React/Angular are rather monolithic (and yes, I do understand that React only dictates the view layer, but still), and are actually probably less outsourceable.

I know this isn't a direct answer but I'm working on a new framework(that isn't ready yet) but I would love to hear your thoughts and see what you're excited by. Couldn't find your email mine is cammarata.nick@gmail.com.

I'd recommend going with something even older and more outdated and with better support: Java and Freemarker. Java was released 20 years ago and Freemarker 15 years ago. I'd give them another 30+ years of reliable use.

Angular is a JS framework, React is more of a UI tool. Why not use both?