It is nice for PCs, but requiring Node.js limits its use on servers.
Fx – Terminal JSON Viewer
61–70 of 80 posts
Re: Fx – Terminal JSON Viewer
#62FYI: .wtf top domain is blocked in HaGeZi's The World's Most Abused TLDs: https://raw.githubusercontent.com/hagezi/dns-blocklists/main... Might wanna change to something else.
This is ridiculous. I will not change my domain because of someone’s blocklist.
Re: Fx – Terminal JSON Viewer
#63amazing! Does someone know something like this for yaml? (does not have to be cli)
Re: Fx – Terminal JSON Viewer
#64Hey HN friends! I've taken `fx` back to the drawing board and completely rewritten it from the ground up. Excited to share what's new: 1. *Going Big*: `fx` now gracefully handles even the most massive JSON files. 2. *A New TUI Look*: Dive deep into your data with a revamped terminal interface—now with themes! 3. *Swift Navigation with Dig Fuzzy Search*: Feeling lost in JSON? Just type `.` and navigate with ease. 4. *…
This looks really nice, well done!
I never could get used to jq's syntax so instead I've just been grepping. But this looks to be for jq what htop is to top, which is great for exploring response data.
Re: Fx – Terminal JSON Viewer
#65Something that would be extra awesome would be light markdown support inside fields. This would make it useful for reviewing chatbot conversations.
Re: Fx – Terminal JSON Viewer
#66Hey HN friends! I've taken `fx` back to the drawing board and completely rewritten it from the ground up. Excited to share what's new: 1. *Going Big*: `fx` now gracefully handles even the most massive JSON files. 2. *A New TUI Look*: Dive deep into your data with a revamped terminal interface—now with themes! 3. *Swift Navigation with Dig Fuzzy Search*: Feeling lost in JSON? Just type `.` and navigate with ease. 4. *…
Why not call it Jim? JSON vim
Re: Fx – Terminal JSON Viewer
#67Earlier quoted context omitted.
It's basically https://json5.org/ CUE will happily take your JSON with comments and extra commas, or no commas too (lists still need them), most keys can be unquoted, and it's just a one-liner to get valid json or yaml from it
Jsonnet does too I believe. I wanted to like Cue but it only works with Go and it doesn't actually let you link the schemas you write from the "document" files, which means no automatic schema checking and no IDE support. Giving up two huge benefits of having a schema in the first place.
I'm not sure what you mean about the schema / documents thing. Can you elaborate? I've not had problems "linking" (?) data and schemas. I'd guess the lack of documentation is more to blame here.
CUE is most often used as a CLI, so no Go is needed, that's really for advanced cases. Being Go, you can compile to SO or WASM, so can use it from pretty much any language.
The lack of LSP is being actively worked on right now, I'm hoping they'll have something before the year is out
Re: Fx – Terminal JSON Viewer
#68Earlier quoted context omitted.
Jsonnet does too I believe. I wanted to like Cue but it only works with Go and it doesn't actually let you link the schemas you write from the "document" files, which means no automatic schema checking and no IDE support. Giving up two huge benefits of having a schema in the first place.
I'm not sure what you mean about the schema / documents thing. Can you elaborate? I've not had problems "linking" (?) data and schemas. I'd guess the lack of documentation is more to blame here. CUE is most often used as a CLI, so no Go is needed, that's really for advanced cases. Being Go, you can compile to SO or WASM, so can use it from pretty much any language. The lack of LSP is being actively worked on right no…
In an XML document you can specify the XML schema location with `xsi:schemaLocation`. In a JSON document you can specify the JSON Schema location with `$schema`.
In a Cue document how do you specify the location of the Cue schema? As far as I can tell you can't.
And yes I am aware that the concept of a "document" and a "schema" are basically merged in Cue, but that doesn't mean I don't want to do this.
> CUE is most often used as a CLI, so no Go is needed
Only because that's the only way you can use it.
> Being Go, you can compile to SO or WASM
Compiling to a shared library is awkward because you then need to have the Go toolchain installed. WASM might be an option ... I couldn't find out how Go actually works in WASM though given that it needs a GC and threads, and WASM currently has neither. Do they ship their own WASM GC?
Either way, it's of no practical use since nobody has actually done that. Look at the languages supported by Jsonnet for comparison: https://jsonnet.org/ref/bindings.html
Python, C, Rust (twice), Go (twice), Lua, Node, PHP, Ruby, Haskell.
If I'm loading a config file from Python I don't want to have to mess around with `subprocess.run()` to read it. It's a solvable problem... but today, it's a bit of a turn-off.
Re: Fx – Terminal JSON Viewer
#69visidata anyone?
Re: Fx – Terminal JSON Viewer
#70Earlier quoted context omitted.
I'm not sure what you mean about the schema / documents thing. Can you elaborate? I've not had problems "linking" (?) data and schemas. I'd guess the lack of documentation is more to blame here. CUE is most often used as a CLI, so no Go is needed, that's really for advanced cases. Being Go, you can compile to SO or WASM, so can use it from pretty much any language. The lack of LSP is being actively worked on right no…
In an XML document you can specify the XML schema location with `xsi:schemaLocation`. In a JSON document you can specify the JSON Schema location with `$schema`. In a Cue document how do you specify the location of the Cue schema? As far as I can tell you can't. And yes I am aware that the concept of a "document" and a "schema" are basically merged in Cue, but that doesn't mean I don't want to do this. > CUE is most…
> nobody has actually done that
CUE, running in the browser: https://cuelang.org/play/?id=#cue@export@cue
I see you are not interested in CUE and the benefits it offers, despite being a young language without all the ecosystem yet
We subprocess.run because there are many problems better solved in CUE that make our other code so much simpler. I can't even tell you the 10s of thousands of lines I don't have to write, both python and other config languages require way more verbosity. There are upsides for the downsides to early adoption