3 ms·

I've gotta agree with you here. If you are a professional developer and are still writing non-templated html, I'd be surprised. I think it's crazy that all thes

• ryan-allen 13y ago
  I'm sure it wouldn't be a stretch to write an extension for Brackets that allows you to handle templates more effectively. 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.
  • ianstormtaylor 13y ago
    We've actually stopped using all pre-processor for everything we do for Segment.io[1] as well, and we're not beginners. 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 https://segment.io [2]: https://github.com/segmentio/toggle https://github.com/segmentio/toggle [3]: https://github.com/segmentio/sheet https://github.com/segmentio/sheet [4]: https://github.com/component/tip https://github.com/component/tip [5]: https://github.com/component/component https://github.com/component/component [6]: http://myth.io http://myth.io
    • myhf 13y ago
      Preprocessors aren't incompatible with components. I usually structure my frontend code like components/ widget-one/ template.html script.js style.css widget-two/ template.dust script.coffee style.styl And then the style file for a component is completely scoped to that component's main class: .widget-two { .widget-two-control { color: blue; } } The build script can handle each component separately and stitch the results together. Just because SASS/compass encourages a monolithic style doesn't mean it's necessary.
      • ianstormtaylor 13y ago
        Yeah, the problem comes in when you want to share pre-processor variables between your components.
• mogosselin 13y ago
  On big projects I work on, front-end developers start from the PSD and do the HTML first (they just do some templates, not the whole site obviously). 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.
  • Raphmedia 13y ago
    Front-end developer here. Yes, that is what I do. We have some really talented developers who design some awesome images of what the websites should like. (Hopefully as a photoshop file. Or at least, something that let me get exact measures and layers.) 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.
• imdsm 13y ago
  Who would think it? That someone would do something differently to us? That some people out there, on the internet, have different workflows than us.