I use Backbone.js at work for front-end work and have found it to be a very pleasurable framework to work with, however I can’t disagree with this post; there are many areas where you can code yourself into trouble. I think Backbone really shines when you pair with it with an application architecture like Marionette or Chaplin. An application architecture will help you by reducing boilerplate code, zombie killing, event cleanup, and more. Choose Backbone, but pair it well.
An easy to understand introduction to global .gitignores. And for some samples check out this github repo.
This is a great alternative (and the right way of doing it) to adding OS specific files to every project’s .gitignore file. No longer will my coworkers need to roll their eyes at me when I add .DS_Store to our .gitignore in the repo (and maybe I can get them to stop littering the repo with Thumbs.db files too).
The official github help page.
If there’s one thing I’m hearing repeatedly while attending the FrontEnd Masters Workshop Series is that it is much more important to write readable code than to be worried about cute coding tricks or hyper-efficient code. Don’t misunderstand, performance is important - or as Kyle Simpson says, “performant by default” - but not at the expense of maintainable code.
I found myself in a situation where I needed to serve a static site (in reality a Backbone.js webapp) through my running Pow! installation. The solution was extremely easy to find but I thought I’d list it here anyway.
The documentation indicates that your folder structure must include a public folder inside your project folder. This would have conflicted with the directory structure of the application that I’m contributing to, so I simply wrapped my project folder with a company folder, which in turn holds the public folder:
or another way to view that is:
1 2 3 4 5