3 ms·

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 o

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.

DocTomoe 1y ago
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 https://www.npmjs.com/package/is-odd
- Phemist 1y ago
  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.
  - johannes1234321 1y ago
    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.
kome 1y ago
> 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.
- epolanski 1y ago
  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.
  - johnisgood 1y ago
    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.
    - nottorp 1y ago
      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.
    - epolanski 1y ago
      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.
      - johnisgood 1y ago
        I said it depends though. You could easily do this or some of it in an nginx config using OpenResty or nginx + Lua extension.
  - 1y ago
ghusto 1y ago
> 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.
aDyslecticCrow 1y ago
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.
- fragmede 1y ago
  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.
lelanthran 1y ago
> 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 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.

DocTomoe 1y ago

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 https://www.npmjs.com/package/is-odd

Phemist 1y ago
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.
- johannes1234321 1y ago
  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.

kome 1y ago

> 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.

epolanski 1y ago
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.
- johnisgood 1y ago
  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.
  - nottorp 1y ago
    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.
  - epolanski 1y ago
    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.
    - johnisgood 1y ago
      I said it depends though. You could easily do this or some of it in an nginx config using OpenResty or nginx + Lua extension.
- 1y ago

ghusto 1y ago

> 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.

aDyslecticCrow 1y ago

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.

fragmede 1y ago
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.

lelanthran 1y ago

> 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 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.