i am developing a new alternative to this kotlin impl: the xml nrs
"nO bUt xMl iS hArD tO rEaD" stfu
xml nrs has several advantages:
nrs_mod is dead long live xml parsers and predictable behavior (these duplicate titles lmfaooooo)
better autocomplete (imagine having to turn on a lsp/ide that eats half of your ram just to rank some entries :skull: :skull: :skull:, and redhat vscode xml support is actually really good if you've got the schema)
no kotlin => no gradle, no slow ci, no java requirement, no slow compilation (imagine changing a singular string make the thing recompile for 20s 💀 💀 💀) , etc.
"bUt tHeN iT wOnT bE aS fLeXiBlE aS kOtLiN" ye i guess
but the feature that it doesn't support is not used bruh, the system have "definable macros", nested entries and contains (like in the kotlin thing), script elements allow for programmatically modify entries/impacts/relations/... (similar to these closure in kt but works in js/ts), etc.
since it's easier to modify the data, some issues can be resolved: #392, #97 and especially #96 :LETSGO:
"nOt aS gOoD aS tHe bIrD's cOdE oPtImIzAtIoN sYsTeM tHo" XDDDDDDDDDDDDD LMFAOOOOOOOOOOOOOOO :bird: :bird: :bird: 👄 👄 :lips:
pogchamp nrs 3.0 xddd
i am developing a new alternative to this kotlin impl: the xml nrs
"nO bUt xMl iS hArD tO rEaD" stfu
xml nrs has several advantages:
"bUt tHeN iT wOnT bE aS fLeXiBlE aS kOtLiN" ye i guess but the feature that it doesn't support is not used bruh, the system have "definable macros", nested entries and contains (like in the kotlin thing), script elements allow for programmatically modify entries/impacts/relations/... (similar to these closure in kt but works in js/ts), etc.
since it's easier to modify the data, some issues can be resolved: #392, #97 and especially #96 :LETSGO:
"nOt aS gOoD aS tHe bIrD's cOdE oPtImIzAtIoN sYsTeM tHo" XDDDDDDDDDDDDD LMFAOOOOOOOOOOOOOOO :bird: :bird: :bird: 👄 👄 :lips: