Show HN: JSON.is

http://json.is

by zackbloom • 10 years ago

100 57 10 years ago

json.is

fizzbatter2• 10 years ago

This is cool! I would have loved something like this for Yaml recently as i learned Rust's Cargo.yaml

steveklabnik• 10 years ago

Cargo uses TOML, not YAML. (But yeah, this is really cool, and that would be really cool!)

fizzbatter2• 10 years ago

Ah yes, forgot about that. You are correct

caub• 10 years ago

I thought it would introspect each dependency too

zackbloom5• 10 years ago

That's a good idea! You can find the repo here: https://github.com/eagerio/json.is, you should open an issue.

jmhnilbog2• 10 years ago

I feel like an idiot, but I can't tell what this is and the "About" page isn't helping me.

zackbloom5• 10 years ago

It's an editor for those JSON file formats which shows contextual help as you edit the files, similar to an IDE. It works by parsing the javascript and figuring out where your cursor is relative to the syntax of that particular format.

jmhnilbog2• 10 years ago

I'm not seeing any of that.

swsieber• 10 years ago

It's documenting the structure of json files used in large projects. On of the three, for example, is documenting the package.json file used by npm. It gives an inline editor to view what one looks like.

dimgl• 10 years ago

That contrast is abysmal. Please fix the contrast on the code samples.

zackbloom5• 10 years ago

The buttons aren't actually meant to be read. If you click them, you get to the actual code page which has a much better contrast ratio: http://install.json.is/

leppr2• 10 years ago

Nice presentation, and it would be even better if it could be integrated as a plugin for text editors (vim/emacs/...).

Waiting for a good webpack.config.js one :)

zackbloom5• 10 years ago

Go for it ;) https://github.com/EagerIO/JSON.is/tree/master/coffee/format...

Bromlife• 10 years ago

Webpack config files are not JSON. They are full JavaScript.

leppr2• 10 years ago

I haven't used webpack enough to be certain but AFAIK, like grunt, the config part is basically just JSON. Sure you can build your object dynamically, but it isn't something like gulp where you use functions to configure your project. In the end you're just exporting one big JSON-serializable object.

SamBam2• 10 years ago

Is http://package.json.is/ really better documentation for what package.json should look like than than regular-ol' documentation, https://docs.npmjs.com/files/package.json?

It seems that this format, while a clever idea, is going to have a lot of problems in describing more complex json documents, which may have optional arguments, arguments that are mutually-exclusive, etc etc.

For example, in the package.json example alone, there are several properties that can be either a string or an object, but it would be hard to expose that in this system.

But maybe this isn't supposed to be documentation, in which case I'm just confused about the purpose of this.

Edit: If more information about the available properties were available at each level (i.e. from the top-level, here are all the possible props; from the "contributors" prop, here are the different possibilities) and this could be used to document one's own project-specific JSON, this could be very cool. But the best would be if it had a way to integrate with a proper schema validator.

aeorgnoieang• 10 years ago

Yes, because it could be available while looking at your actual config file (JSON document), and showing you info specific to the element you're looking at, instead of on a separate page and requiring searching for a relevant element.

Why would this be any harder to describe complex JSON documents? Optional arguments don't need to be described if they're not in your specific file – not by something like this anyways. That's what the regular documentation is for, and this could easily link to it too.

Mutually exclusive arguments can easily be linked-to, or, rather, if your file contains one of those arguments then the contextual info can link to any other mutually exclusive arguments.

Why couldn't the context info state that valid values include either a string or an object (of some type and that type linked to in the context info)?

I'm confused about your confusion! It seems like this is a really handy way to show documentation specific to a selected portion of a JSON object for a given format.

SamBam2• 10 years ago

OP described the tool as this: "It's an editor for those JSON file formats which shows contextual help as you edit the files."

Is that what it's supposed to be?

Because what I was saying was lacking was any contextual help that tells you what you could add, vs what's already there.

If I were shown http://package.json.is as "contextual help" to help me author my package.json file, I would have no idea that I could add "author" or "contributor" fields. This only gives documentation for the stuff that is already there.

You could add every property to the original document, but that fails if you have mutually-exclusive properties, because the original document would not be valid.

You could try to add every possible property to the top-level comment, but then the top-level comment needs to be practically as long as the original documentation.

Documentation that is incomplete, and doesn't seem to have a reasonable way to make it complete, doesn't seem useful to me -- and in many ways seems worse than not having it, because the incompletion means I would never even realize I was missing useful documentation. I'd have to have the real documentation open on another page anyway, to make sure I'm not missing stuff.

But again, maybe I'm missing the use-case.

killercup• 10 years ago

Nice, but too bad this is not in JSON Schema (it's a custom bunch of html strings in functions). I would love a more complete JSON Schema for package.json (with custom stuff like browserify or babel config) as VSCode is able to autocomplete JSON files from that.

alexatkeplar• 10 years ago

Exactly - why invent some artisanal Turing-complete thing involving regular expressions and tied to a single proglang when you could achieve the same in a fully declarative, language-agnostic fashion by adding the "description" field into JSON Schemas for the same source documents?

wwwigham• 10 years ago

I'm pretty sure you'd just need to contribute an updated definition to http://schemastore.org/json/ then.

sotojuan• 10 years ago

Would be helpful to add JSON API.

andyfleming2• 10 years ago

Is install.json something new or is it used by an existing platform/toolset?

zackbloom5• 10 years ago

It's used to build Eager Apps (and can be used by anything which needs to install a library in a non-technical-person friendly way): https://eager.io/developer/docs/install-json

andyfleming2• 10 years ago

Oh, nice! I sent you an invite on LinkedIn. Shoot me a message and let's connect!

brilee• 10 years ago

There's this structured data format called XML, and typically you put a XML schema definition at the top (example: <xs:schema xmlns:xs="http://maven.apache.org/xsd/settings-1.0.0.xsd"> for a Maven config file). XML code editors then fetch the XML schema declaration, which contains information like what fields are expected, whether those fields are repeatable, whether they are required, and so on. Java library using XML as configuration will typically have published an XSD.

Fun fact: XML schema declarations are themselves XML documents, and there exists an XSD describing allowable XSDs. https://www.w3.org/2001/XMLSchema.xsd

throwaway2845342• 10 years ago

I'm confident that everyone knows about XML and that you're a worse troll than I am.

Nobody contests XML's capability. It was unpleasant to write and read.

sdegutis• 10 years ago

The raw format may be. But with a good IDE it's pretty easy. Just like, well, most computer languages actually.

nine_k2• 10 years ago

Json forbids comments. It makes writing it much less pleasurable than it might be.

PeCaN• 10 years ago

It's a troll post, but the point stands: JSON is reinventing XML.

XML is ugly, but complicated JSON isn't much better IMO. It has an only slightly less human-unfriendly syntax: Why do I have to use double quotes on keys? Why are there no comments? Then come things like schemas, queries, and transformations: XSD, XPath, and XSLT are very powerful tools. Their implementation sucks, but it's arguably better than people coming up with their own half-documented solution whenever they need something XSD/XPath/XSLT provides.

zaphos• 10 years ago

JSON has JSON Schema, with similar features and some similar editor integrations; see: http://json-schema.org

flukus2• 10 years ago

Now we just need jslt and we've come full circle.

shriphani• 10 years ago

XML is the best way to communicate 20 characters worth of information using 1000.

gkya2• 10 years ago

It's certainly second to any Bootstrap&JQuery based website.

frik• 10 years ago

Quick, 1998 is calling.

nv-vn• 10 years ago

"Old = bad" is not an argument against XML, or any technology for that matter.

erichurkman• 10 years ago

Breaks for me using Safari: TypeError: null is not an object (evaluating 'style.overflow') — works on Chrome.

paulddraper• 10 years ago

Since package.json.is is primarily a code editor, it’s not really well-suited for small screens.
Please check us out on a larger screen. :)
Email yourself a reminder

WTF? You might not know this, but my phone is equipped with advanced pinch-and-zoom technology you may not have seen before.

voiper1• 10 years ago

That's very nice document-panel on the side! If we could get that in sublime or vscode, that would be pretty cool!

Show HN: JSON.is

Related Stories