Frontend & Backend: Gotta Keep’em Separated

I used to start my web applications by throwing all of my code into one big project.  So I’d have html, css, javascript and all the backend code together in one monolithic directory.

Now, I take a different, smarter approach.  I separate the frontend from the backend. Separate code, separate projects.  Why?

Different Skillz

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

What if the entire backend of your project is simply an API?  That sure makes things easier and simpler on your backend developers.  Now, they don’t have to worry at all about html, css, or javascript.

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.


About Brad Carleton

Brad is a rockin' fun JavaScript coder who enjoys building cool stuff and long walks on the beach. As the Founder/CTO at TechPines, he has worked with large companies and startups to build cutting-edge applications based on HTML5 and Node.js. He is the creator of, a realtime HTML5 framework, and is the author of Embracing Disruption: A Cloud Revolution Manifesto.
This entry was posted in backend, frontend, web applications and tagged , . Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • hey, i resent that hipster comment! i love my macbook, but thats it! :P
    But I love this article. This has been my mantra recently since I started my new job and its working out really well! “Any” API on the “backend” then I use node to talk to the api, and whatever flavors I want on the “frontend”. All ties together nicely with a bow and easy as pie!

  • gleb Chermennov

    Nice picture :)
    I came to that conclusion myself about 2 years ago – it’s much easier to work that way, especially if you have designers on your team who don’t know a thing about a backend

  • Tyrone Michael Avnit

    I used to believe this until I realized how much slower it is to have your API render your client as opposed to having your server render a portion of your app. This is a brilliant article that changed my mind. I do believe the above will work for SPA’s, but general websites, I still think the old approach is better.

  • Alper

    Agreed. That’s pretty fly (for a web guy)

  • gilligan_MH

    I thought the smart people already realized separating your team horizontally instead of vertically is a bad idea?

    • Marcin Pewiński

      Elaborate pls after 3 years have passed ;)

      • gilligan_MH

        Wow, I was arrogant back then. Essentially, instead of having one dev do backend and one do front end, either dev on the same team will do both at different times, focusing on the product/project as a whole.

        • Marcin Pewiński

          Do they mess with front or back-end both in the same time? Is it even possible?

          • gilligan_MH

            If the team owns both the front end and back end then yes. It’s possible le. The team I was recently on had pairs that would change both front end and back end within one user story frequently.

  • San Diego Software

    Don’t fully agree with this, the right tools for the project applies to structure and architecture too. Also, what if the entire team is full stack, though full stack guys that are worthy of really digging into the front end are not super common, we do exist. And in this day and age, what front end guy can’t work on the APIs, Models and Database once in a while. Seeing the entire picture, building the domain knowledge, and see the business rules, goals and data all helps in the overall goal of understanding what a company is trying to accomplish. Just being able to get the data with a new API call you need because the back end guys aren’t around is a good reason for a front end guy to be full stack enough and visa versa for a back end guy that needs to do a quick fix on a front end bug and check it in.

    • techpines

      Keep it classy, san diego…

      I agree with you. I know that there are full stack guys out there, myself included, that can sling code up and down the stack.

      I was advocating separation more from an architecture standpoint instead of a strictly human resource standpoint. Although, the mental gymnastics that it takes to labor over every pixel on the page, while simultaneously making sure your database queries are indexed and performant is probably the reason why my right eye twitches when it gets cold.

  • Julian Cassin

    What is strange of late is the separation of roles for front end and back end. To do either one of these you will likely need to have more than one skill. Let’s say of some of the following skills: Architecture, Graphic Design, SQL, OOP, HTML, CSS, PHP, JavaScript, Java, … I have seldom met someone with a single skill, therefore, it’s just as valid to have a group of people covering both the front end and back end if the project works better that way. Unless you are building really basic websites, then it’s likely you will need as much skill in the front end as the back end, sometimes the same shared skillset, sometimes different. See as an example… the Front End (which doesn’t really rely on a specific backend technology) does require more than a graphic artist. My recommendation, if you are responsible for the running of a project, use the skills of the people you have as a whole or in a way thats most efficient – don’t segregate them without just cause.

  • Paul

    “Your frontend developer is probably an uber-hipster who would keel over and die without his mac and latte” if thats the case whats the designer/UX guy like?? :-)

    • Marcin Pewiński

      They’re elves.

  • I am a full-stack dev, facing a decision right now: to separate or not separate front/back ends? A distinct repository for each? I’ve googled about and found this article. But I’m still in doubt.

    • Eido Askayo

      I’m facing this dilemma too, do you have any conclusion?

  • Fredrik

    I found this to be a real revelation when I realized that I could keep the back-end completely separate from the front-end!

    I also think that the debate around server-side vs. client-side rendered apps doesn’t necessarily spill over into this question either. The back-end can remain an API that, as far as project structure go, is separate from the front-end, without the front-end being strictly prohibited from executing anything on the server. The number of libraries and frameworks that allow for this kind of isomorphic JS execution is growing, too, really excited about where this will take us architecturally.

  • I think that a separation is also needed on the front-end between UX designer and coder. The UX designer likely uses an electric shaver, but the coder likely uses a blade IMO.