How to Separate Frontend and Backend in Django

If you look at the Model-Template-View triads, each distinct component and any intermediary component in between can be tested separately. Say you have a Foo model and need to add controllers for CRUD behavior in a simple and straightforward manner:

1. You unit test the Foo model to assert that the business logic is implemented.
2. You unit test FooForm to assert form.is_valid() is returning expected results for the inputs your tests supply directly.
3. You only need to assert that the class-based CRUD views are working with the Foo model and FooForm respectively.

In general, there's no extensive frontend testing happening in Django projects, especially those that utilize class-based views and unit test the views directly, you won't see any assertContains/assertNotContains tests at all, although the LiveServerTestCase is going to change that a bit, at least when it comes to asserting behavior for project's that aren't already writing JavaScript tests in one of the testing frameworks.

It's as if you have your backend hat on when your writing unit tests. If you want to add a success message to the CUD views, you'd assert that a success-level message has been added to the list of user's messages after a successful request, but you won't care whether that message is a part of the response or not. Similarly, we test that the context is populated with the correct Foo objects for a request, but we don't care if and how they're displayed.

And this is where Lettuce comes into play, especially if you want to test your application's behavior from a user's perspective. It's appropriate to work with the content of a response object and to ignore the underlying implementations that produced the response. Here you won't care whether or not there is a success-level message associated with a user, you'll just want to make sure it's there in the response and you won't care whether the appropriate Foo objects are in the context, you'll want to assert that their content is present in the response.

The Django docs never mentioned that a person who doesn't know what HTML/JS/CSS is about can use it. Separation of concerns is done also in the backend, where the actual action(the views) are separated from the database layer or the URL-routing logic - That allows for loose-coupling. It never means you can write views without ever understanding your models. Similarly(well, not that similarly), you do need to have an understanding of HTML/CSS to get basic web pages up. You may or may not want to learn some JS, but I think with HTML5, it is more or less essential to know some JavaScript.

No sane web-developer is going to advise to to use a WYSIWYG editor like DreamWeaver. Write HTML by hand. You may, however, use things like HTML5 Bolierplate to get your project started fast.

Google AppEngine is a PaaS that you can use to deploy your application. It will provide among other things, the Python runtime, a high-replication datastore etc. - but it will not take care of generating your front-end.

If you're going to hire someone to take care of the front-end, that person would anyway have to know how to use Django tags, as really(if you follow the MVC - or MTV pattern closely), they define the blurred line between "static" and "dynamic" web-pages. Even if you choose to hire a frontend-developer, I suggest you grasp the basics of HTML and CSS(at least so much that you know how it works and how are you going to serve the CSS static files). It will only help you in the long run.

Not all people have good design skills, and design is undoubtedly best left to skilled people, but when it comes to actually serving pages with that design, it is all HTML and CSS. So you may hire a person who doubles up(most do) as a front-end designer and a front-end developer. But I suggest you to not remain completely unaware of front-end technologies.