Forest @forestjohnson@pixie.town

@f0x https://nixos.wiki/wiki/NixOS_on_ARM

There are already quite some community supported SBCs 👀

@f0x thats the really messed up thing about it 💀

@f0x all of this could have been avoided if docker / docker-compose had supported a standard, API-driven way to add a file into a container before running it

@f0x Yeah for mine I did a [stupid hack](https://git.sequentialread.com/forest/threshold/src/branch/multi-tenant/main_client.go#L242-L258)

JSON, YAML, TOML, all can have the same problem but its a lot more normative to warn or even error on unknown properties for those because they have a well defined namespace -- just 1 file.

@f0x I wish this kind of logging behavior would be more commonplace but everyone seems to think is weird or there's something wrong with it 🙁

@f0x In theory it could, but most software doesn't.

If we can coax the software to print its configuration file to the log on startup, at least it will indirectly let you know, because the configuration value in question will be missing. If it always prints the config on startup by default, this can even happen before we considered that the configuration part wasn't working.

In theory if the environment variable is prefixed, it might be possible to directly warn about unknown environment variables and/or low
levenshtein distance between the env var's name and a known configuration variable name.

I bet folks have been scared to implement this kind of logic for env-var-based config because of how the environment variables are often all thrown into the same global namespace, so there's a possibility of collisions with other programs running on the same machine.

The warning message for the unknown env var(s) would have to warn you that "this warning itself might be spurious" 🙃 that classic aged 30-40 years old technology flavor

@gschwepp

I do web apps in general, front end and back end. I only worked with server side JS one time, and that was at my old job with React and express / node.js

I'm confused about what you are saying:

> JS does not really keep up with the tech stack that the backend people work with

I don't know what you mean specifically.

google translate says:

ich schäme mich, dass ich kein deutsch kann, weil es einfacher wäre zu kommunizieren, aber leider bin ich nur ein "podunk" amerikaner, ich spreche nur eine sprache😳

@gschwepp

> I think the point made by gabe is that only serverside JS is allowing some improvements and additions.
> And it is not intended to work with different path.

Yes, but I think its important to acknowledge that there is a reason for this: We are stuck with JS or something that compiles to JS when we want to interact with the DOM or other browser APIs. I feel like that should be treated as a given.

So if you want to do that DOM interaction on the server using the same code that you use in the browser, of course you need to run JS and a DOM implementation on your server!

Whenever someone expresses disgust or frustration with something, I feel compelled to try to "fix it" to understand why it's a problem and try to create a solution.

However sometimes the world just is frustrating, the human condition is frustrating, its not something that we can "fix" (well, maybe some religions disagree but whatever)

I feel like this is one of those times. If you want to run your browser code on the server, you have to run your browser code on the server! It seems clear cut to me. I don't think it's that way because of some intentional effort to create a web monoculture. I think it's just a natural consequence of the evolution of common practices in web design.

Obviously I'm missing something here, and it's probably related to why you would want to run your browser code on the server in the first place.

To optimize for clients with slower CPUs? To support users who have disabled JS?

Ultimately I don't think its really necessary most of the time. How many sites both require JS to render the page AND have to work in browsers that have JS disabled? It seems paradoxical.

@gschwepp

Is it more problematic than the site not loading at all for folks who have disabled javascript or manage it with a whitelist?

Or more problematic than maintaining a polyglot web application with noscript versions of everything and progressive enhancement versions of everything, with the entire app spanning something like 6 or 7 different languages?

I don't think its about making frontends "shiny". Not everyone has the luxury of designing sites that are JS-free by default. Server side JS is just one possible avenue we can pursue in search of a universal web platform that works for everyone. Code once, deploy to every internet connected device. That was the idea, at least... Honestly it's kinda amazing it still works at all, considering how much legacy the web stuff has accumulated over the years.

@f0x the "putt it" bourgeois ?? or maybe puttputt bourgeois 😆