Hacker News Reader

Comment by epolanski | Hacker News Reader

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.

Even admitting one wants to go with bare bone web components authoring and maintaining them is expensive, requires lit or something.

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

View on HN

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.

Reply on news.ycombinator.com