> That said, I'm a little surprised you see no value at all in CSS preprocessors

I find value in CSS preprocessors in a few limited cases:

- auto-prefixing for added browser support. Especially with CSS animations this is one place where automatically generating the browser-specific CSS can be a time-saver

- for expressing design patterns that may be present in CSS in a more succinct, clear way as a way of teaching or demonstrating a pattern to others

- as a master copy to generate CSS that will be edited and maintained by hand. Suppose I built custom WordPress themes for a client I could have a SASS reset and base set of styles and then for each new project generate my CSS file and go from there

> If you're working on a team of developers all contributing CSS to a project, do you find that one CSS file is actually manageable?

I am more of a responsive specialist so I'm usually brought into existing projects where other programmers and designers have managed to get the code into a knot they can't untangle, so I don't change the existing codebase unnecessarily just to condense things, but for the project I author I will usually deliver a global CSS file that includes all layout, typography, form, button, and responsive styles, and then it's common to include an additional stylesheet for each plugin you might be using. If you have a responsive table plugin then it likely has one JS and one CSS file that need to be included and I would link them in as external files instead of inlining them in my global CSS. We then work with it as a team from there and it's been working well for us keeping things more simple.

> Do you not get merge conflicts?

Working this cleaner way has greatly reduced the merge conflicts we used to get when we were fully working within the 'Bootstrap' mindset and using 'classy HTML' and frameworks. Now we write clean markup, we pass over it with JS and enhance it how we need and use CSS and a CSS polyfill that adds element-based responsive queries as well as scoped CSS and the code is pretty terse. Not much there to conflict with :)

> Does it require vast discipline?

Yes! But I'm surprised at how little HTML, CSS, and JS is actually required to build some really cool stuff. On thursday I was experimenting with the web audio API and I made this teeny tiny HTML5 app that I bookmarked on my phone and tablets and was able to play with over the weekend. It only took a few lines of HTML, CSS, and JS to make a fully fuctioning web app - why would I write more than I need to to do the same thing? I can iterate pretty fast when I know how little code is actually required.

http://staticresource.com/synth.html

And that obfuscated blob at the bottom is nothing special, it gets unpacked to become a set of instructions to build the favicon and app icon using a canvas tag and attach it to the document. I encoded it using another teeny tiny HTML5 app I built http://staticresource.com/encode.html

You can view the source code of these by using another tiny tool I built that loads the requested page's source code and displays that instead. This way you can 'view source' even when using your phone or tablet. http://staticresource.com/inspect?/synth.html

If I was trying to use React or Node with Bootstrap and jQuery for every project I tried to build it would be a headache trying to build all these tiny little tools and apps. No wonder people need all this crazy front-end tooling. If you know HTML, CSS, JS, and learn the command line for manipulating files and batch operations, as well as for ow to automate routine tasks you do that's pretty much all you need in your toolbelt.

Whenever I work with teams I adapt to fit their pre-existing style decisions and tools because that's part of what I'm being contracted to do, and I desire to provide the most value while providing the least amount of friction.

Edit: and the significance of being able to build HTML apps so tiny is that you can write them on the devices you use them on! These are entire apps that you can sit down and write in Vim without it being awkward. I wrote this little page to learn how to detect multitouch on my ipad one morning on vacation. It's so simple: http://staticresource.com/touches.html I wouldn't have an easy way to write and test code using libraries on my tablet, but I could write this and test it and I learned a lot. This is huge considering Amazon just relased a decent tablet for $50, we can finally use these devices for creative work building HTML5 apps and stuff is simple enough now that just HTML, CSS, and JS is needed to build things.