> JSON + Variables, Conditionals, Arithmetic, Functions, Imports, Error Propagation

Is this going full circle then? JS -> JSON -> JS.

More seriously and like someone already said, to many brackets and quotes for rapid prototyping.

I think the use cases are more to generate JSON file, for example, to generate config file based on a template.

Yes I am confused by this as well. It's a templating language for javascript objects? Isn't javascript a framework/language to create javascript objects? Other then interface with a few APIs (in browser or node.js) it can't do anything else.

If you’re using Javascript or have an embedded JavaScript runtime sure use that.

The 1st party bindings are for C, Go and Python; so it a cross-language JSON DSL. And making it a strict DSL has significant advantages.

I'm a fan of JSON-e over jsonnet (less complexity/safe with untrusted data, native libraries for Python/JS/Go instead of C++, + valid JSON/YAML on its own): https://taskcluster.github.io/json-e/

This is looking a little closer to what I was looking for.

They seem to be on the verge of inventing lisp.

An LISP with structured data and a data inheritance. Trivially embedded in a host language. Sign me in.

It happens from time to time.

I have threatened to write a Terraform equivalent in Lisp every time Terraform frustrated me, which was often.

Can't help thinking Nix and NixOps.

Still not Lisp.

  {
    person: self.person,
  }

  RUNTIME ERROR: max stack frames exceeded.

  {
    "self": "a",
    b: self.self
  }

  STATIC ERROR, expected token identifier but got self

Looks good.

You just modeled a data structure that would normally take an infinite number of lines of JSON in three lines, so that's kind of neat.

:)

For comparison, reader variables in Common Lisp:

    CL-USER> (setf *print-circle* t)
    T

    CL-USER> '#1=(person . #1#)
    #1=(PERSON . #1#)

We just published a simple IntelliJ-Jsonnet integration, in case anyone else happens to also use those combinations of tools and is frustrated by lack of editor support

https://plugins.jetbrains.com/plugin/10852-jsonnet

Gives you syntax highlighting and basic jump-2-definition, though more advanced features are TODO.

This is the basis for Ksonnet, a Kubernetes helm chart replacement.

I wouldn't call it a helm chart replacement. It's meant to replace directly using YAML files.

You can still helm-ify a ksonnet app.

ksonnet isn't a Helm replacement and in the next release of ksonnet, we'll support Helm packages.

I find Jsonnet incredibly useful to generate JSON while following a structured "don't repeat yourself" paradigm. It's a very good basis for a software application configuration system. It enables me to define a JSON schema which is most suitable for consumption by software while not forcing humans to slog through that in order to author the configuration. Adding some function and structure tooling in a little Jsonnet library helps humans write very expressive documents that can be compiled down to the repetitive and exhaustive JSON level.

This is exactly where I've found it can be helpful as well.

At a prior job we created extremely large, complicated CloudFormation templates in JSON that could have been made much simpler with Jsonnet and the ability to do comprehension and some other tricks to keep it DRY. A coworker ended up writing a bunch of Python scripts to templatize the CF templates (ugh).

At my current job we ended up using Jsonnet as a configuration language for Apache Aurora jobs [1], which was also helpful when trying to make it easy for others to pick it up and create their own jobs from base templates.

That being said, it can be frustrating to get going with and for some cases I do find myself having to trace through things very carefully in order to to figure out exactly what's going on.

[1] https://github.com/benley/aurora-jsonnet

I’m disappointed jsonnet is not a poem.

Just like any JSON is legal JavaScript, I want a functional programming language where any legal Jsonnet is a legal subset of the language. That'd be cool.

I'm not sure but perhaps ReasonML is worth a look at? I don't know if you can specify property names with quotes. Lists are also homogenous but that'd be the case with most functional languages with a static type system.

You could also go to town with reader macros in Lisp or use Racket.

JSON is not actually strictly a subset of JavaScript, surprisingly. Although, in practice, it doesn't really matter, because you wouldn't want to blindly eval JSON data, anyway.

I mention this not to be pedantic, but in case it helps another coder from wasting a couple days chasing a bug like I once had to, when I thought I could template raw JSON into a script file to make some server-side data available as a global var on in the browser.

http://timelessrepo.com/json-isnt-a-javascript-subset

Jsonnet is not new, but it's a missed opportunity as it's a big departure from the JavaScript semantics. It's Standard Library and syntax are unique, which is not a good thing for its purpose. It needs to be a subset of JavaScript, which could later become part of ECMAScript. I understand that its lazy evaluation nature required some of those, but still, I find it often to be much more pain than it should be!

I don't understand that argument at all. Jsonnet generates JSON. Why does it itself need to be in JSON?

XSLT was brilliant except it was extremely verbose and difficult to use due to wanting to be expressed in XML.

XSLT as prior art demonstrates that Jsonnet made the right choice here.

It doesn't have to be JSON in this case, but JavaScript. Anyway, even XSLT has JavaScript support!

Seems I misread your post. I guess I very seldom think of JSON as having anything to do with JavaScript even if that is where it originated..

What's the benefit over a regular templating language ? Can't you do all that with jinja2 ?

Manipulating structured data using a text templating language is best left to masochists.

For example, merging two objects is trivial in jsonnet yet pretty close to impossible in jinja2.

The following would be trivial to build in jinja2:

    {{ merge(foo, bar)|tojson|safe }}

Even something polymorphic to render a template, then merge into a known dict, then output json would be easy. A signature that might look like:

    {{ render_json_dict(foo, "foo.json")|merge(bar)|tojson|safe. }}

Sure, if you render the entire JSON in a single pipeline you can do a merge. But then you only have a single pipeline.

In the last jsonnet template I wrote, I merged a few keys into the top level, merged a few keys into a deeper level, and added some random characters to the end of a string value to make it unique. Trivial in jsonnet.

You could do this multiple times in the same top-level template if you're a masochist. Just use jinja2's set command to setup local variables in the template. You can do awfully complicated logic in jinja2, it's just that almost nobody will pass that garbage in code review. It gets kicked up to the python layer where, being a full data structure and regular code, it is easier to organize, comment, and test.

That seem like a twisted use case though. I never seen anything requiring that. Given the rarity, i would just script it instead of introducing a whole new tech into my stack.

+1, not everything is meant to go through the 11th iteration of the regex-meatgrinder.

Another +1. I was recently contemplating a problem that could be aided by what I was calling strucural templating and almost wrote something like this.

I would love to see a complex, multi-file CloudFormation config expressed in jsonnet.

That’s exactly what we are using jsonnet for at my company. Introducing jsonnet in our CloudFormation work has given great results with almost zero up front cost (compare with other CloudFormation DSLs). This reminds me I should finish writing that blog post about it :)

And it has comments !

Of course not to be confused with https://jasonette.com/

Naming things is the hardest thing...

:)

Reminds me of Marimba's product Castanet (which went with Bongo). Named by the same genius who came up with the name "Java" -- Kim Polese.

https://www.wired.com/1996/11/es-marimba/

http://www.suck.com/netmoguls/96/10/18/front.html

http://www.suck.com/netmoguls/96/10/18/back.html

Kim said: "It was fun naming stuff back then. You could actually get the trademark/website!"

And then there is Json.NET https://www.newtonsoft.com/json

jasonette has always seemed like something that could be amazing

Thought so too until I tried it. Once you get started with it, it quickly becomes clear that it's all built on top of hacks that won't scale past a 1 page app. It's not a bad choice for prototyping, but I'm not convinced that it's any easier than prototyping with a real framework like Flutter.

Too many {} and "" for rapid prototyping for me. I've always considered forking it to use yaml instead.

For me (I believe few others) the {} and "" are ok as they provide a clear and consistent separation of structure and type at a quick glance, but the comma? That should have been avoided as even in JavaScript semicolons are increasingly being abandoned..

> "even in JavaScript semicolons are increasingly being abandoned"

Disagree. In my experience the trend is in the opposite direction: ASI is broadly acknowledged to cause problems, CoffeeScript turned out to be a trainwreck, and popular defaults for linters tend to enforce semicolons.

Here's a question I've been trying to answer:

Q: How can you conveniently and compactly represent, view and edit JSON in spreadsheets, using the grid instead of so much punctuation?

I’ve come up with a simple format and convenient conventions for representing and editing JSON in spreadsheets, without any sigils, tabs, quoting, escaping or trailing comma problems, but with comments, rich formatting, formulas, and leveraging the full power of the spreadsheet.

It's a work in progress, and I have posted a few messages about it on HN. I'm in the process of writing it up now on Medium (but I'll publish it now so you can read it). I welcome any feedback, criticisms and suggestions, please!

https://medium.com/@donhopkins/representing-and-editing-json...

https://news.ycombinator.com/item?id=17309132 https://news.ycombinator.com/item?id=17360071 https://news.ycombinator.com/item?id=17360799 https://news.ycombinator.com/item?id=17360883

Here's an example spreadsheet -- check out the examples in the different sheets (the tabs along the bottom):

https://docs.google.com/spreadsheets/d/1nh8tlnanRaTmY8amABgg...

Here's a sample implementation, that runs in the browser, node.js, as a Google Spreadsheet extension, etc:

https://github.com/SimHacker/UnityJS/blob/master/UnityJS/Ass...

As well as parsing JSON structures out of raw spreadsheet data, that code also returns a tree of scopes that you can use for syntax coloring or error message feedback, because I'm integrating it with Google Sheets (but the parser is independent of the particular spreadsheet, and just operates on 2D array of strings).

It would be nice to develop it into a macro templating engine for JSON (or higher level structures that happen to be represented as JSON). Kind of like Genshi (the XML/Python templating system that I’ve used a whole lot and love for its simplicity).

https://genshi.edgewall.org/

Cool! This should be a top-level "Show HN" post.

Right? One time my boss asked me to do something in JSON but I explained to him I simply couldn’t work with JSON because of the braces and quotes. JSON is practically unusable.

Good lord, wait until someone shows you computers. All the ones and zeros. A real mess we all can agree.

I'd prefer to use .js for configs.

This is why other people are suggesting that this is close to a reimplementation of Lisp - what you want by using a .js for your config is the right to use any kind of dynamic definition that suits your needs down the line, and have the application consume that config through some standard function call(s). When lists are code are lists, it's easy to make anything infinitely dynamic.

Wanna get crazy, here's a PHP .INI configuration system. =) https://github.com/ellisgl/GeekLab-INIConf

Can somebody please explain what the difference is to jq and similar tools?