All the people suggesting to use JS instead of Jsonnet are completely missing the point.
Jsonnet is a functional lazy evaluated language that supports powerful referential concepts. Unfortunately the website sucks at getting this across.
JS on the other hand is an imperative programming language.
If you say "use JS" you may as well say "use Python", the 2 are equivalent in this context and neither are in the same class as Jsonnet in terms of robustness and simplicity.
I didn't get it until I used it but after using it I don't think I would go back to test templating when it comes to dealing with JSON/things that are equivalent. i.e I would use Jsonnet to create JSON to convert to YAML rather than templating YAML directly.
Same goes for generating objects directly in JS/Python/jq - yes it can be done, yes sometimes you can write a nice DSL but in most cases Jsonnet is going to allow you to write said DSL faster using functions and it's going to be simpler and less prone to errors.
I think databricks recently released an alternative jsonnet compiler/renderer written in Scala that's faster than the standard Google one (including a workaround for the slowness of JVM startup/shutdown) but compatible with it: https://databricks.com/blog/2018/10/12/writing-a-faster-json...
It was discussed on HN though I don't have the link handy.
But sure, if you are okay with a single yaml file, that's certainly simpler.
If you are suggesting using Python is same as using JavaScript, you missed the point too.
In this case, JavaScript's syntax is very similar to Jsonnet. Or at least what is shown in the example can be accomplished in a very similar way. (maybe except anchors, which can be replaced by variables)
JS is a lot closer to Scheme and Lisps than an imperative language. In fact, it used to have a lispy syntax before Brenden Eich was forced to change it to make it more approachable.
As a person who has done every exercise in SICP, that argument is total bullshit.
Let's go through the list of things that the author says Javascript doesn't have:
2. Lexical block scope
JS has lexical function scope, so it would trivial to convert a "lexical javascript" to a "function lexical javascript." I think it's unfortunate that JS doesn't have lexical block scope, but it's trivial to implement through nested function definitions, so I don't think it's a real problem.
3. TCO
This isn't a feature of a language, it's the feature of a compiler. It just so happens that the Scheme spec requires the compiler to have TCO. But if the Scheme spec didn't mention this, would it make a Scheme something different?
4. Continuations
Continuations are very rare in Scheme, or any language for that matter. I think someone would be hard-pressed to argue that it's fundamental to Scheme.
6. S-expressions
There are many extensions to JavaScript, (JSGEN in Allegro, and various other libraries in SBCL), that allows one to write Javascript in S-expression syntax. So maybe while Javascript doesn't use S-expressions, one can very trivially transpile S-exp JS to normal JS.
8. Macros (he probably should have said hygenic macros)
It's pretty easy to implement a hygenic macro system on top of Javascript. In fact, people have already done so, one example is sweet.js.
9. Distaste for mutation
I'm not sure that distaste for something can be part of a language spec. But it's a non-argument: if all JS programmers suddenly had a "distaste for mutation" would it be anymore or less like Scheme? I don't think it matters at all. This point is about culture, not language spec.
So, in conclusion, from the above points, one could trivially write a Javascript to Scheme compiler that would have all the features of Scheme, except maybe call/cc. If this is what you define as Scheme, sure, fine, you win: Javascript isn't Scheme. But for the rest of us, it doesn't really matter and JS is damn close to Scheme from a practical perspective.
Moreover, it wouldn't even be that hard to add call/cc to JS! So I don't think that or any of the author's points are very valid.
JavaScript does have lexical block scope since ES6, with the `let` and `const` statements.
And continuations are implemented by convention in nodeJS (through callbacks)
It even is specified as including TCO, a classic scheme feature, but so far it is implemented only in Safari.
Non mutation also seems to be a trend in web development, again thanks to `const`. The only things that make JavaScript not scheme, then, are syntax and the lack of macros. (Which is kind of a result of the more complex syntax)
I have no dog in this fight but saying JS isn't scheme because it isn't a True Scotsman (plus a bunch a appeal to emotion) doesn't make for a compelling counter-argument.
Jsonnet is a functional lazy evaluated language that supports powerful referential concepts. Unfortunately the website sucks at getting this across.
JS on the other hand is an imperative programming language. If you say "use JS" you may as well say "use Python", the 2 are equivalent in this context and neither are in the same class as Jsonnet in terms of robustness and simplicity.
I didn't get it until I used it but after using it I don't think I would go back to test templating when it comes to dealing with JSON/things that are equivalent. i.e I would use Jsonnet to create JSON to convert to YAML rather than templating YAML directly. Same goes for generating objects directly in JS/Python/jq - yes it can be done, yes sometimes you can write a nice DSL but in most cases Jsonnet is going to allow you to write said DSL faster using functions and it's going to be simpler and less prone to errors.