JSON is not an acceptable format for user-editable config files. JSON is an extremely bare-bones data serialization format that doesn’t even allow comments

bare minimum, make the config file JSONC instead. even then, the lack of trailing commas is pretty annoying

honestly though, just use TOML. YAML has a pretty maximalist spec that seems a little cursed but even that is better than JSON

@kasdeya .ini files

@kasdeya an argument can be made that a well structured XML file is more accessible to the average user as a config file than whatever the greenhorns vibecode with JSON these days

I hate everything to ever come out of the JavaScript ecosystem

except WebAssembly. that actually seems alright. I just want a way to run it that isn’t through JavaScript

@sanity honestly, I don’t like XML very much at all because I find it hard to read but I would agree - I think it’s much more readable and accessible than JSON

@kasdeya I've really been liking Dioxus. All rust, no js. I've been making https://beta.based.radio with it

@kasdeya in XML it is usually pretty clear where things begin and end. the verbosity is both a weakness and a strength. as a professional software developer, I regularly find myself manually editing JSON and messing up some comma, curly brace or what have you and I'm trained to know what I'm doing. expecting regular users to edit JSON properly is like handing delicate medical equipment to laypeople and expecting them to not eff it up.

@sanity @kasdeya honestly i think there's no reason for any program to not come with a config file editor (which is aware of the config schema and can provide autocomplete/refuse to save an invalid file/provide warnings)

telling people "oh just run this (possibly GUI, possibly CLI, you can make both pretty easily) program and it'll guide you through configuring this" is so much nicer than "edit this fuckass .json/xml/toml/ini file. here's the docs. don't fuck it up"

and once you're using a distinct program for it, it doesn't really matter what the file uses.

@Stellar @kasdeya or their Java equivalent, Properties files

@kasdeya

<?xml version="1.0"?>
<configuration>
  <!-- disable debugging if you are not a developer -->
  <no-debug/>
  <hostname>example.com</hostname>
  <auto-update>stable-release</auto-update>
  <numbering-scheme>numerical</numbering-scheme>

  <!-- you do not need AI slop -->
  <no-llm-integration/>
  <no-nonsense/>
</configuration>

@kasdeya the obvious solution to this is having every possible option be an environment variable and having the config file be a big shell script full of KEY=VAL assignments for each env var

@sanity hm that does make sense tbh. it’s probably way easier to be like “this is <element> so I need to check for a </element>” rather than “there are three curly braces, then a square bracket, then a curly brace, so I need to check for those in that order” lol

@5225225 @sanity omg interesting. yeah honestly I don’t think it would be that hard to make something like this? and someone could even make a library that handles all of the basic UI stuff and is just like “okay tell me what to ask the user and give me a function to validate the user’s inputs for each option” and that would basically be all you need, I think

@kasdeya i still wish asm.js caught on. it feels like a solution that fits the web much better: there's no need to standardize like 30 different extensions just to do what asm.js could already do. no need to polyfill it. no need to enforce a JS control flow compatible assembly language on everyone else. performance was only like 0.5x compared to native with comparatively not many changes to js engines. i just think it was really neat and WASM is just too big and wide.