
Jsonnet – A data templating language - galfarragem
https://jsonnet.org/
======
kuroikyu
> 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.

~~~
penagwin
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.

~~~
lttlrck
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.

------
wryun
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/](https://taskcluster.github.io/json-e/)

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

------
ris
They seem to be on the verge of inventing lisp.

~~~
rbanffy
It happens from time to time.

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

~~~
ris
Can't help thinking Nix and NixOps.

~~~
rbanffy
Still not Lisp.

------
junke

      {
        person: self.person,
      }
    
      RUNTIME ERROR: max stack frames exceeded.
    
      {
        "self": "a",
        b: self.self
      }
    
      STATIC ERROR, expected token identifier but got self
    
    

Looks good.

~~~
Apes
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.

~~~
junke
:)

For comparison, reader variables in Common Lisp:

    
    
        CL-USER> (setf *print-circle* t)
        T
    
        CL-USER> '#1=(person . #1#)
        #1=(PERSON . #1#)

------
lihaoyi
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](https://plugins.jetbrains.com/plugin/10852-jsonnet)

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

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

~~~
pests
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.

------
frumiousirc
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.

~~~
ksmith14
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](https://github.com/benley/aurora-jsonnet)

------
jurassic
I’m disappointed jsonnet is not a poem.

------
kasajian
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.

~~~
jwdunne
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.

------
nikolay
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!

~~~
dagss
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.

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

~~~
dagss
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..

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

~~~
bryanlarsen
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.

~~~
emidln
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. }}

~~~
bryanlarsen
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.

~~~
emidln
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.

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

~~~
andreabedini
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 :)

------
ttoinou
And it has comments !

------
isuckatcoding
Of course not to be confused with
[https://jasonette.com/](https://jasonette.com/)

Naming things is the hardest thing...

:)

~~~
ckluis
jasonette has always seemed like something that could be amazing

~~~
nv-vn
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.

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

~~~
murukesh_s
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..

~~~
chrisweekly
> "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.

------
Rygu
I'd prefer to use .js for configs.

~~~
jackfraser
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.

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

