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.
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/
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
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.
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.
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!
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.
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.
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 :)
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.
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.
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!
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).
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.
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.
Is this going full circle then? JS -> JSON -> JS.
More seriously and like someone already said, to many brackets and quotes for rapid prototyping.
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 have threatened to write a Terraform equivalent in Lisp every time Terraform frustrated me, which was often.
For comparison, reader variables in Common Lisp:
https://plugins.jetbrains.com/plugin/10852-jsonnet
Gives you syntax highlighting and basic jump-2-definition, though more advanced features are TODO.
You can still helm-ify a ksonnet app.
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
You could also go to town with reader macros in Lisp or use Racket.
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
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.
For example, merging two objects is trivial in jsonnet yet pretty close to impossible in jinja2.
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.
Naming things is the hardest thing...
:)
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!"
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.
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/