PHP is actually a pretty good HTML preprocessor language. Not sure why it was blasted from this planet. Maybe because people abused it as a "rest" endpoint or backend, and burned themselves out from using the wrong tool for the job (even as php evolved to be pretty good backend for this too)

A small amount of PHP as a templater for simple raw HTML and JS segments is pretty nice.

Because debugging it is a nightmare. It's really awesome for what it's good at, but inline templating after a certain level of complexity is a recipe for madness. The problem is, projects start off small and un-complex, but by the time it gets too complicated, you're in too deep and porting it something else takes extra time.

I think the emphasis is in 'indiscriminatly'. The goal is not to have absolutely zero dependencies, just don't depend on dependencies that you could reasonably implement yourself.

A classical example might be https://www.npmjs.com/package/is-odd

JavaScript's weak typing and implicit type conversions get in the way of reasonability though:

  >>> '13' % 2
  0
  >>> 'nan' % 2
  NaN
  >>> NaN % 2
  NaN
  >>> null % 2
  0 

this package ensures that you have a sane complement to is-odd, e.g. `!isOdd(someVar)` is always even (in the domain of natural numbers). A naive implementation of is-odd: `(some_var % 2 === 1)`, does not have a sane complement.

Anyway, to include this package as a dependency is indeed overkill. I would most likely opt for vendoring this package into the project (including licenses and acknowledgement), as the code is unlikely to change and is MIT licensed.

The question is: how likely is it that I get the trash input in and do I care about the result if the input is trash? Modulo two works well for a lot of cases where this is needed. (Which probably is size of a container (array) or alternating something in a loop.

> Thus, what's the solution? Some sort of templating? Again, you're bringing on dependencies.

If your "dependency" is yourself because you wrote your own template for your specific needs, is that still a dependency?

I wrote a templating solution for my own repeated sections and I'm so glad. It does exactly what I need, it's simple for me to understand if ever it grows large and I need a refresher, and easily expandable.

> but there's solutions that are hard to ignore such as the need for reusable fragments/components on different pages which already make a cry for dependencies.

honestly ctrl+c, ctrl+v of hand written html. and i'm cool as a cucumber.

Been there, done that. You implement just a header navigation change, now you're copy pasting across 12 different files.

But wait, now you want to add an active state to your navigation links, and you're manually changing the `class="active"` in 12 different files...

I could go on, it doesn't scale beyond triviality, albeit LLMs do help speeding up.

That is why you can include a header.html, nav.html, and footer.html if you so wish! There are many ways to do this. :P Depends on your use case.

If you don't go through two different ORMs - running on separate AWS VMs of course - and then to a third server that has the actual database, it's not professional.

And then you need a dependency to glue them together...And now you want to provide data..And now you want to put content in children.

And you went from a simple nginx extension to again full blown software.

I said it depends though. You could easily do this or some of it in an nginx config using OpenResty or nginx + Lua extension.

  $ man sed

Or for more complex things

  $ vim
    :cfdo

> On one hand I agree, one should approach issues as they come, but there's solutions that are hard to ignore such as the need for reusable fragments/components on different pages which already make a cry for dependencies.

I side-stepped that completely, even on actual production web apps for clients, with this: https://github.com/lelanthran/ZjsComponent

Now, you may argue that that is a dependency, but it doesn't have any of its own, you can make a copy of it, serve it from your primary domain, and you're done.