Good questions.

First, when it comes to “frameworks” I’m just not a fan, and templating systems that sit on top of other languages have always struck me as dumb when most “web languages” for the back end already are or have such stuff in place. I prefer PHP with comma delimited single quote echo, using functions or an object wrapping anonymous functions to build my templates… because PHP is — BY ITSELF — a template system. Hence the term “Hypertext preprocessor”. It’s whole job is to glue data to markup.

It’s for that reason I find things like “Smarty” utterly dumbass, replicating functionality BUILT INTO THE EXISTING LANGUAGE!

For simple pages I’ll just make various /templates/default/module.template.php files — where “module” is replaced by the appropriate action like common or blog. Inside them I write “template_” functions such as “template_pageHeader” to output the content accepting as arguments what’s to be shown, and or accessing a common “Config” object. template_pageHeader for example would output everything above and including <main>, whilst template_pageFooter outputs everything from </main> to the end of the document. Those template_ functions calling other template_functions when/where/as appropriate.

If you format using single quotes and comma delimit with echo, the syntax is cleaner than the garbage willy-nilly use of PHP shorttags. Good rule of thumb? One <?php per file!

More complex I make a template object that stores anonymous functions in an associative array, that also has data sources bound to it.

NONE of which should take a competent coder more than 15 minutes to write from scratch, or warrants becoming a “framework”. I’m often shocked how these utterly mind-numbingly stupid systems waste two to four dozen k of code on doing 1k’s flipping job! But sure, it’s “easier” that way.

Of course you’ll hear the lame excuses “code size isn’t a good indication of quality”… when the difference breaks 10:1, you bet your sweet bippy it is! Just more bullshit from people who refuse to either learn, or think, all to justify their blindly copying garbage they don’t even understand.

In node.js I do much the same. Backtick strings — aka “template literals” — have transformed what we can do with JS with far less headaches. Just make functions or objects of functions that plug arguments into template literals and be done with it if all you’re doing is server-side gluing data to markup! Why that’s so “hard” for people and why they think they need bloated halfwitted trash like React is utterly beyond my comprehension!

As to your second question, no. If you have enough CSS to “need” those types of tools, you’re probably writing more CSS than you need. I say that because for the vast majority of websites — and I say this a lot — there is NO reason for more than 48k of CSS in one or two files FOR THE ENTIRE SITE! And that’s me “Mr. Scotting” that figure by 50 to 100%.

In fact, the only reason you tend to see more than that is people unqualified to write a single blasted line of HTML or CSS vomiting up code with no cohesive plan, thought process, more often than not leading them to the mental midgetry that are front-end frameworks.

And really if they’re repeated often, COMBINE YOUR SELECTORS!

.cards,
.gallery {
  display:flex;
  flex-wrap:auto;
  align-items:center;
  justify-content:center;
}

When you have a new section that uses that same style, just add its selector to that list. Funny, when you said “4 properties” this is what came to mind. Flex!

As to your last question, I work with monolithic stylesheets from the start because I would almost never have enough CSS for such post-proceessing to even be worth the effort. Again, there is NO reason to have enough CSS for each media target for such extra steps to pay any benefit.

On the whole people are getting too obsessed with splitting up their CSS into multiple separate files for ZERO legitimate reason, and if anything it makes things HARDER to work with! Why? Because who knows what the **** file what you’re trying to fix is even in without a “non-live” copy where it’s all separate files, or some sort of “mapping” BS to undo post-processing just making everything even more of a PITA.

Worse, it makes it harder to eliminate redundancies and share properties. I’ve yet to see one of these post-processors actually edit-down like values by combinator lists. You combine this pre-processor nonsense with the trash that are front-end frameworks, is it any wonder people vomit up 500k of CSS to do 15k’s job?

That’s really what burns me about this, these massive hard to decipher codebases spreading their girth all over creation, making even the simplest of tasks a monumental undertaking, whilst all the know-nothing cut-rate cultists chant “easier and better for collaboration, easier and better for collaboration,easier and better for collaboration” because they’ve drunk too deeply of the tainted flavor aid; much less not knowing enough about HTML or CSS to even be flapping their damned yaps on the huffing topic!

THEN they wonder why when their work has gone bits-up face-down and a consultant like me is hired to clean up their mess, they’re the ones getting demoted, fired, sued, etc, etc.