Good Practices for (larger) Javascript Apps

ideas.md

• use a build process
  • Gulp
  • Grunt
• Lint the shit out of everything
  • CSS
  • Coffeescript
  • Javascript
  • es6
  • HTML
  • Only code with 0 Lint error passes build
• npm install, gulp build
• have a watcher
• backend and frontend are probably not the same thing
  • dont make them share the same codebase
  • Js/CSS/HTML are firt class citizens
  • big ball of mud
  • HTTP is a very well defined interface
  • Dont develop
• use a package manager
  • package your own functionality
  • again npm install, gulp/bower test
  • each package knows how to build it self
  • AMD/require not mandatory, but a good practice
• Use CI
  • The first build is a empty project with 1 passing test
  • One of the first things is to establish CI
  • as easy as addint a .travis.yml
• Documentation
  • Use Sourcecode documentation to explain WHY
  • Where ever possible
  • Editors and minifiers can hide the docs
  • newbies will need them
  • Creating a useful set of docs is part of the build process
  • Writing docs should be a little bit all the time
  • docs never difffer from actual code
    • easy to achieve with small modules
  • Have as much executable specs as possible
    • This can be exven gists that run against the codebase
    • or examples in a wiki
    • put the exwmple code into CI
    • it shows
      • docs are on par with code
      • that stuff actually works
      • docs can be a good integration test

Nice list already! I'd add some things:

• have a readme with setup instructions in your project
• have a coding guide in your project
  • this should explain why your team chose the coding style
• indent consistently
  • .editorconfig and .jscsrc can help here
  • you should probably use the same indentation as the backend devs for easy code sharing and collaboration

And: maybe 1-2 of your points are things worth arguing about:

• "Prevent frontend/backend code sharing"? This depends on the nature of the project. I think you should often have a frontend only project, a pattern lib/living styleguide/prototype, simply to be faster, light-weight, independent, and to always have a reference implementation. But you should have it structured in a way that makes code-sharing a snap. Sometimes there won't be a clear line between frontend and backend, especially with SPAs and isomorphic apps - then you might only need a mock, or you might also have three layers: 1) backend services, 2) middle-end proxy with frontend business logic and 3) visual frontend/design, or something completely different
• "Don't develop"? I don't get this one...