<p>We used to do what you are doing, for a good many years - it was especially helpful when we didn't know what CMS we were going to use yet, or when we had a front end specialist (hello) who would send the files off to the back end specialist for implementation.</p>

<p>However, with Craft, we've found that the front-end people can use it well enough to not need a 'back end specialist', so we find ourselves no longer doing site builds as front-end assets first. It's just faster and easier to build the HTML/CSS/JS from inside the Craft templates.</p>

<p>We also used to (and still do for larger projects) build a completely non-styled "blueprint" of the website. The objective was to ensure that the site structure was correct - here's an example: <a href="http://example.bp.myvcsite.com/" rel="nofollow noreferrer">http://example.bp.myvcsite.com/</a></p>

<p>That was/is part of our whole approach where we split things into blueprint; visuals; static build; CMS integration: <a href="http://example.myvcsite.com/" rel="nofollow noreferrer">http://example.myvcsite.com/</a></p>

CC BY-SA 3.0
2016-12-01T15:11:46.100Z
2016-12-01T15:11:46.100Z
Matt Wilcox
<p>Tobias: I don't think there's a "right" answer for everyone.</p>

<p>What I do find is that Craft "gets out the way" a lot more. Craft's file structure and Twig templates aren't that far away from just static HTML. </p>

<p>You can actually throw an <code>index.html</code> file inside Craft's <code>templates</code> folder and Craft will serve it just fine. All the stuff you need to grab from the database just won't pull in. Then when you're ready to break out the <code>header</code> and <code>footer</code> into the <code>_layout</code> template and hit the CMS, it's ready for you.</p>

<p>Unlike other CMS, for example WordPress, where it expects a theme to work in a certain way and live in a certain folder structure, Craft is a bit more flexible in this respect.  (In WP land can change these defaults of course and use something like Timber but that's getting off track.)</p>

<p>We try to get a lot of the content roughed in as early as possible because it can dictate design decisions. A lot of designers work backwards and make content fit the layout. I find Craft fits our "content first" methodology a bit better.</p>

<p>We still produce static comps, get design approval and then build from those but a lot of people design in the browser because they find it faster and can show off a responsive design better. I'd argue Craft is no better or worse in this respect. I tend to switch from "design mode" to "programming" mode; when a design I created is set, then I figure out how to make it work, oftentimes incorporating the content we setup with the client at the same time. In this way, we are able to show the client a more "complete" website. At that point, we're just tweaking image and copy.</p>

CC BY-SA 3.0
2016-12-02T23:01:01.287Z
2016-12-02T23:01:01.287Z
RitterKnight
<p>Interesting question. I think one answer depends on the speed of fidelity, ie that point at which you need to show something to a client AND how much fidelity they need ( ie in terms of completed visual design). I'm still finding the sweet spot and doing it both ways depending upon project time and budget.</p>

<p>I do think there is a lot of merit for building it in html/css within craft as it enables resources like js and sass, images etc to be more ready to go.</p>

CC BY-SA 3.0
2016-12-06T00:36:25.993Z
2016-12-06T00:36:25.993Z
joomkit
<p>I hope this question does not sound to banal:
I am currently switching to Craft CMS and I am used to build my HTML/CSS/JS templates as static pages with dummy content. </p>

<p>This (seemingly?) has 3 advantages for me:</p>

<ol>
<li>I have an early, clickable prototype, presentable to the client
before I have to touch any CMS</li>
<li>I am not forced to insert real content via the CMS yet </li>
<li>It gives me a very clean Git Repository for the frontend without any
CMS dependencies yet</li>
</ol>

<p>The disadvantage is of course that I have to manually split my static pages up later to work with Craft CMS (or any other CMS) templating logic.</p>

<p>Thus I was wondering how you approach templating, especially with Craft: Whether you start directly building your frontend from scratch in Craft’s Templates folder or if you start independently, and do the splitting of files every time as a necessary step …</p>

<p>Any suggestions?</p>

<templating><workflow>
Best Practice for Templating-Workflow, coming from static HTML
# Best Practice for Templating-Workflow, coming from static HTML

(Asked by: username_0 on 2016-12-01)

I hope this question does not sound to banal:
I am currently switching to Craft CMS and I am used to build my HTML/CSS/JS templates as static pages with dummy content.

This (seemingly?) has 3 advantages for me:

1. I have an early, clickable prototype, presentable to the client
   before I have to touch any CMS
2. I am not forced to insert real content via the CMS yet
3. It gives me a very clean Git Repository for the frontend without any
   CMS dependencies yet

The disadvantage is of course that I have to manually split my static pages up later to work with Craft CMS (or any other CMS) templating logic.

Thus I was wondering how you approach templating, especially with Craft: Whether you start directly building your frontend from scratch in Craft’s Templates folder or if you start independently, and do the splitting of files every time as a necessary step …

Any suggestions?

**Tags:** templating, workflow

---

## 3 answers

### Answer by username_1 on 2016-12-01. Score: 4 | Accepted answer

We used to do what you are doing, for a good many years - it was especially helpful when we didn't know what CMS we were going to use yet, or when we had a front end specialist (hello) who would send the files off to the back end specialist for implementation.

However, with Craft, we've found that the front-end people can use it well enough to not need a 'back end specialist', so we find ourselves no longer doing site builds as front-end assets first. It's just faster and easier to build the HTML/CSS/JS from inside the Craft templates.

We also used to (and still do for larger projects) build a completely non-styled "blueprint" of the website. The objective was to ensure that the site structure was correct - here's an example: <http://example.bp.myvcsite.com/>

That was/is part of our whole approach where we split things into blueprint; visuals; static build; CMS integration: <http://example.myvcsite.com/>


---

### Answer by username_2 on 2016-12-02. Score: 3

Tobias: I don't think there's a "right" answer for everyone.

What I do find is that Craft "gets out the way" a lot more. Craft's file structure and Twig templates aren't that far away from just static HTML.

You can actually throw an `index.html` file inside Craft's `templates` folder and Craft will serve it just fine. All the stuff you need to grab from the database just won't pull in. Then when you're ready to break out the `header` and `footer` into the `_layout` template and hit the CMS, it's ready for you.

Unlike other CMS, for example WordPress, where it expects a theme to work in a certain way and live in a certain folder structure, Craft is a bit more flexible in this respect. (In WP land can change these defaults of course and use something like Timber but that's getting off track.)

We try to get a lot of the content roughed in as early as possible because it can dictate design decisions. A lot of designers work backwards and make content fit the layout. I find Craft fits our "content first" methodology a bit better.

We still produce static comps, get design approval and then build from those but a lot of people design in the browser because they find it faster and can show off a responsive design better. I'd argue Craft is no better or worse in this respect. I tend to switch from "design mode" to "programming" mode; when a design I created is set, then I figure out how to make it work, oftentimes incorporating the content we setup with the client at the same time. In this way, we are able to show the client a more "complete" website. At that point, we're just tweaking image and copy.


---

### Answer by username_3 on 2016-12-06. Score: 2

Interesting question. I think one answer depends on the speed of fidelity, ie that point at which you need to show something to a client AND how much fidelity they need ( ie in terms of completed visual design). I'm still finding the sweet spot and doing it both ways depending upon project time and budget.

I do think there is a lot of merit for building it in html/css within craft as it enables resources like js and sass, images etc to be more ready to go.


---

