If you're a full stack dev, then it might happen that you do all these steps at the same time, so you never work on pure html, but if you're not I imagine this is how you work.

Want a span to show the live content of foo.bar.baz? <span data-source="foo.bar.baz"></span>.

Then the JS is either made by them (depending if they know JS) or by a JS specialist.

Then the programmers integrate the HTML in the "code/templates" (CMS, whatever).

We develop in different web technologies and front-end developers don't learn how to code server side code (either they don't want to, don't have time, whatever).

Depending on the templating engine and programming language and final product (CMS, etc), they can or cannot edit or fix their CSS right in the final code.

Sometimes they need the programmers to tell them where the templates that they want to change are, etc. Imagine a big projects with hundreds of different templates made by a programmer, the front-end dev doesn't necessarily know where to change his stuff and if he's going to cause a problem elsewhere.

If it's a small project, made to be beautiful, they will do the whole design of all the pages. If it's a huge Agile project, they would instead give me a style guide.

Then, I quickly turn everything into reusable HTML blocks and do the CSS (using LESS). If needed, I'll make custom jQuery (or pure Javascript, but that never happens, really) modules for the template. It's very quick. A full page templates takes me about 1 to 2 hours, if it's very, very complex I may take up to 4 hours.

While I'm working on those, the back-end guys are working of making the CMS work correctly. Sometimes, I give them the templates before they program the page, but most of the time I end up attacking the page after them. I then simply use the building blocks they gave me (and turn all the divs they made into the right HTML5 tags).

We use a lot of different CMS and some of the websites have custom backend (no CMS). We develop in both PHP and .Net.

I know PHP, and I'm comfortable developing Drupal websites. However, I don't get a lot of fun making the backend. The only time I would do it if we are working on a one pager or something like that, since it's faster if I do both back and front for project that are not complex.

I prefer working on the front-end. And I do mean front-end development. Not simply mindlessly slicing a PSD into an HTML page or adding content from a Word document.

On another note, you'd be surprised how many people are still doing pure vanilla. Preprocessing isn't usually part of a beginners toolchain, you gotta learn the underlying part first before you start grafting on the preprocessors used in larger projects.

One of the biggest problems with them is that you immediately eliminate a huge portion of the people who are willing to contribute to your code if you select a pre-processor they aren't fond of. It's fine for app internals, but for sharing small[2] open-source[3] components[4] it's not a good idea—whether it's Sass or CoffeeScript or Jade or whatever.

The other problem with CSS pre-processors specifically is that they only work well with the monolithic app mindset. All of your CSS files inside the same `styles` folder, and all of them required by the "top of the monolith" `main.sass` file. Instead, using something like component[5] you get true dependency trees, so you don't have to go monolithic anymore. And trying to get Sass to work across a component-ized codebase is a real pain. Instead we use Myth[6] to "post-process" the built CSS.

Pre-processors are a leaky abstraction that comes back to bite you at random points the way all leaky abstractions do, and the ways are usually hard to foresee and thus hard to argue against when the benefits seems so clear.

[1]: https://segment.io

[2]: https://github.com/segmentio/toggle

[3]: https://github.com/segmentio/sheet

[4]: https://github.com/component/tip

[5]: https://github.com/component/component

[6]: http://myth.io

    components/
        widget-one/
            template.html
            script.js
            style.css
        widget-two/
            template.dust
            script.coffee
            style.styl

    .widget-two {
        .widget-two-control { color: blue; }
    }

If you have an established project, then sure, you probably already have your views setup.

It would be really cool if Brackets could detect that you are working on a partial and inject that back into the page somehow

Me.

My martini untemplate engine is a code generator that inputs HTML and outputs Java.

This creates a one-way flow of work. Designer creates the HTML, I create the backend. When the design changes, the backend (e.g. data binding) breaks during the generation and compile steps. Not in the browser.

Martini isn't ready to demo yet. It will be open source. But documentation and examples take more time that I have right now. Sorry.

After a really bad encounter with Javascript 7 years ago I chose to forego web development completely.

Now I have a web-app project and I discovered with horror that not only Javascript is not dead, but it's even more prevalent than before !

I'm gonna have to suck it up and start learning it, but maybe not to the point of choosing Node.js as my server side technology :-)

I can do the same with the various web dev plugins, but I rather like being able to save the intermediate result and not have to worry about a refresh changing the underlying state of my view.

Templated, as in "this html isn't coming from a rails partial" etc.

For one, everybody who designs the original HTML to be templated. Some start with a PSD and then do a full HTML page, others start directly by doing a full HTML page. Only AFTERWARDS its made into a template.

Second, ever since Enhydra (Java) and TAL (Zope) at least, there have been template engines that use full, plain, HTML code, marked with special attributes (repeat, inject value here etc).

I do, however, do rails with it. This includes everything: ruby, erb, CSS, sass, JavaScript/coffeescript, and even handlebars.

Live development is it's least useful feature (for me), and Brackets should get more credit for the rest of it.