sxml | json5 | |
---|---|---|
2 | 96 | |
5 | 6,336 | |
- | 0.7% | |
3.7 | 0.0 | |
about 2 months ago | 12 days ago | |
TypeScript | JavaScript | |
Mozilla Public License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
sxml
- The KDL Document Language
-
Deno Is Now on MDN
> wrt Java
Not just Java. Python, Ruby, Node etc suffer from the same problem. And I am taking as an end-user here.
I once downloaded something based on one runtime which then proceeded to download another runtime which it needed to run one little script. There are programs out there that have node/npm as a dependency.[1] People are crazy.
> your 3 listed reasons make a very argument for "a normal compiled language"
One of my hobbies involves writing compilers and parsers.[2][3] I have tried a lot of "normal" languages and have stuck to Java (in spite of its excessive verbosity) for work reasons. Some languages I cannot tolerate for aesthetic reasons.
For now, there is no alternative to TypeScript.
> you wrote software 2 ways: shellscripts and Java. You replaced them with...any entirely new interpreted language(JS)
I used to run a mixed-environment (Windows + Unix) and a lot of glue code that drove other software had to be written twice (sh/bash + cmd/bat) before WSL came along. That problem has disappeared.
I also used to write a lot of tools (servers and cli apps) in Java. Some of those I have moved over TypeScript-on-Deno.
> I'm not denigrating JS/deno/node/whatever
I used to look down on JS a decade or so back. My experience with Rhino and now Deno changed that. There is a lot of stuff that I do now which I simply would not do if I have to fire up an entire Java project to do that.
[1] https://archlinux.org/packages/community/x86_64/nodejs/
[2] https://github.com/s-i-e-v-e/ut
[3] https://github.com/s-i-e-v-e/sxml
json5
-
Why, after 6 years, I'm over GraphQL
There are a lot of proponents that some or all of the "JSON5" [1] improvements should be standardized by ECMA as well. Especially because there is a mish-mash of support for such things in some but not all parsers. (Writers are a different matter.) Primarily comments and trailing commas, are huge wish list items and the biggest reasons for all of the other "many" variant parsers (JSONC, etc).
[1] https://json5.org/
-
Using ARG in a Dockerfile – beware the gotcha
That is what you get when people reinvent the wheel and lifetimes/ scopes are implicit. Docker could've used something like JSON5 [0] for their configuration format to make the lifetimes explicit. Another time when easy won over simple. [1]
[0] https://json5.org/
- JSON5 – JSON for Humans
- Why the fuck are we templating YAML? (2019)
-
I pre-released my project "json-responder" written in Rust
JSON5 support
-
topoconfig: enhancing config declarations with graphs
Meanwhile, formats have been evolving (JSON5, YAML), config entry points are constantly changing. These fluctuations, fortunately, were covered by tools like the cosmiconfig.
-
That's a Lot of YAML
I think JSON5 is fairly close to this: https://json5.org
I reckon the only thing it's missing to be truly accessible to non-techies is that string values still need to be quoted, i.e. you can't have:
key: this is my value
(I'm definitely not saying it would be a good idea to allow quotes to be dropped, just that that's the only potential stumbling block I see for non-techies.)
-
XML is better than YAML
I believe that's JSON5.
https://github.com/json5/json5
It's my preferred configuration file format, it fixes all the problems I have with JSON (trailing commas, comments) without turning it into a mess full of gotchas like YAML.
- Fx – Terminal JSON Viewer
- What Is Wrong with TOML?
What are some alternatives?
deno - A modern runtime for JavaScript and TypeScript.
Json.NET - Json.NET is a popular high-performance JSON framework for .NET
kdl4j - KDL Parser for the JVM
hjson-js - Hjson for JavaScript
kdl - the kdl document language specifications
jq - Command-line JSON processor [Moved to: https://github.com/jqlang/jq]
Kaitai Struct - Kaitai Struct: declarative language to generate binary data parsers in C++ / C# / Go / Java / JavaScript / Lua / Nim / Perl / PHP / Python / Ruby
toml - Tom's Obvious, Minimal Language
import-maps - How to control the behavior of JavaScript imports
jsonnet - Jsonnet - The data templating language
ron - Rusty Object Notation
sublime-hjson - Hjson support for Sublime Text