Now, I take a different, smarter approach. I separate the frontend from the backend. Separate code, separate projects. Why?
One downside to having your entire project tucked neatly into one of today’s monster frameworks like Rails, Django, or MVC, is that it can be very difficult for a frontend developer to work on the project.
While it might be simple for a seasoned Ruby dev to setup rvm, gem install all of the ruby dependencies, deal with native extensions and cross platform issues. These things are probably not what your frontend developer is best suited for.
In most cases, your typical frontend and backend developer are very different. A frontend developer needs to have more focus on the user experience and design, whereas a backend needs to be more focused on architecture and performance.
Or to put it another way. Your frontend developer is probably an uber-hipster who would keel over and die without his mac and latte, while your backend developer is probably more like one of Richard Stallman’s original neckbeard disciples.
A better architecture
It’s also much simpler on the frontend developers, since they can start their work without having to worry about “bugs in the build system” or other server side problems.
It also promotes making the frontend a real first class application and ensuring that it’s truly robust. Hopefully, the frontend developer is now encouraged to code for the inevitable scenario when the backend goes down.
What a better user experience to say, “Hey, we’re having some issues with the server right now, try back later” or even better “The search service appears to be having issues at the moment, but you can still view your profile and current projects.”
In general, I think the separation approach also promotes the use of realtime single page applications on the frontend. In my opinion, this offer the best user experience and design architecture for modern web applications.