Following from Why we are going to use AngularJs 1.3 on TM ...
On jQuery, my experience (in both developing and reviewing jQuery apps) is that it tends to promote an 'lets just hack it to make it work' kind of development workflow. In jQuert code, there are always tons of DOM manipulations, which will always include (browser specific and other) hacks, and create code with quite a lot of dependencies and lack-of-isolation between components. Basically you shown me an large jQuery app (like the one we developed) and It most likely be an app hard to refactor, hard to maintain and hard to understand what really is going on (ironically the power of jQuery tends to create this stuff, since it is always possible to 'fix something' by adding a bit of jQuery somewhere).
And of course jQuery is also a nightmare from a security point of view, since there are quite a lot of sinks that will transform strings into code.
- no jQuery (as far as I am concert it is a banned API :) )
- Jade for creating html (i.e. no raw html and encoding by default on all variables)
- 95%+ Unit Test coverage
- NodeJs on the server (with one a version of the website created with NO Javascript)
- AngularJS on the client, with full use of Angular components to keep code clean, easy to test and isolated (Controllers, Directives, Services, etc...)
- CoffeeScript on both server and client (to promote good Javascript practices, keep code clean and easy to test)
- Git Flow, with git submodules used to separate the code into different areas of responsibility
- Docker for deployment and testing (with ability to start new instances of the site in seconds (on any branch))
- Slack for team collaboration
- GitHub for Issues (and of course code hosting :) )
I also have to say that I like the maturity and amount of thinking that has gone into AngularJS security. Yes there is a level of moving parts, but they push the development teams to have a really good architecture (which is key to enable all team members to write secure code).
In fact, what I really like about our current development environment/workflow (the one based on Node, CoffeeScript and Jade) is that there are large parts of the code base that at the moment it is REALLY hard to create a security vulnerability.
For example, since we use Jade for the views, I don't have to 'security review' design and UI changes since they are secure by default (and I have a test to check for the on case where un-escape content can be enabled).
Compare this to the normal JSP or jQuery world where any code change is one small mistake away from creating a security issue.
Basically the best way to prevent HTML injections (aka XSS) is to not have any HTML coding at all :)
For example, since we use Jade for the views, I don't have to 'security review' design and UI changes since they are secure by default (and I have a test to check for the on case where un-escape content can be enabled).
Compare this to the normal JSP or jQuery world where any code change is one small mistake away from creating a security issue.
Basically the best way to prevent HTML injections (aka XSS) is to not have any HTML coding at all :)
