I like the fact that this exists, but I prefer to use jq. I also would like to know in which situation this is preferable to jq.
Not sure which one is better at this point. Using jq still often feels like trying to decode a code golf contest entry.
11–20 of 76 posts
I like the fact that this exists, but I prefer to use jq. I also would like to know in which situation this is preferable to jq.
Not sure which one is better at this point. Using jq still often feels like trying to decode a code golf contest entry.
Looks cool, but I can't help but think that you're just reproducing what map() and filter() do, without any real benefits?
I work on a similar problem though using a UI based approach, I gave a demo to the Kubernetes SIG App group a while back which be found here: https://www.youtube.com/watch?v=alEzE8MSNaI&t=30m
Btw Ethan, maybe my email is landing in your Spam folder? I've tried reaching out :)
Despite this, many languages aren't great at this! we have tools that work alright on first-order operations but fall apart on higher level things.
Even really simple things like "conditionally include a key" are rarely supported in a way that leads to concise code. How many times have we all written
foo = {...}
if bar:
foo['a'] = x
instead of something like foo = { ... , 'a': x if bar }
and then having bugs because of branches? Tools that solve this sort of problem will be to modern programming what things like the Unix shell was to data mungers in the past.Haskell lenses kinda goes into this stuff, though Haskell itself is a bit hard to use in a lightweight fashion. Clojure has Specter. But still looking for some more stuff to fill this hole, especially in the "transitionally typed" stuff like Typescript or Python + Mypy
XML -> JSON
WSDL -> JSON schema
XPath -> JSON path
XSLT -> JSON template?
SOAP -> Swagger and friends
One or two decades from now there will be too many tools and things to learn about JSON so another generation will reinvent a new "perfect format for everything". And a new cycle will have started.XSLT for JSON?
That's the first thing that came to my mind too. XSLT is very powerful but also incredibly messy because it has to be expressed in XML. Doing the same in JSON seems like it would result in the same problem.
Being expressed in XML does not help, but the language is just bad with implicit data flowing through and very odd constructs, there are XML template languages which I found much more readable than XSLT e.g. I remember my experience with genshi much more fondly than the years I spent with XLST.
I thought I would provide some context on why I wrote this library, and how I'm using this right now. So here it goes:
Other than ST.js, I also work on another open source project called Jasonette (https://www.jasonette.com), which lets you write an entire native iOS/Android app in nothing but JSON markup.
And when you can express the entire app logic--from model to view to controller--in JSON, you can split them up whichever way you want and load them from anywhere (from a file, from cache, from a remote server, or from local memory).
But the biggest benefit of all is: you can load an entire ios/android native app from the server in realtime, just like how web browsers load HTML/JS/CSS in realtime.
When working on Jasonette, implementing model and view was relatively simple. For model it's natural since JSON is all about describing data. For view i just needed to come up with a syntax to describe layouts and all the standard mobile UI components in JSON.
However the biggest challenge was how do i actually describe functions in JSON. Without a function, it's just a mockup and won't really do anything meaningful.
Which brings us to ST.js.
When you think about what a function is, it takes one value and turns it into another. So basically what I needed to do was build something that will take one JSON, and turn it into another JSON, but most importantly I would have to do it using JSON. Basically I needed to implement a finite state machine in purely JSON.
And this is what templates do. So I set out to build a JSON template engine that turns one JSON into another using a template which itself is written in JSON.
What's really cool about this is, since the template is JSON (As far as I know there doesn't exist any prior art that uses JSON as a template, otherwise I would have used it instead), it has all the benefits of the JSON format itself:
1. You can store it anywhere (Most DBMS nowadays support JSON natively)
2. You can send it over the Internet
3. You can compose them easily
4. You can validate them using JSON schema
5. etc.
To use a more specific example, I use ST.js in both Android and iOS versions of Jasonette as the template engine. And a JSON template is absolutely necessary in this case.
For example, if I want to take a piece of device-generated data and render it, I need to be able to somehow parse it client-side (can't send it back to server to re-generate a JSON) http://docs.jasonette.com/templates/#3-device-api-generated-...
This also applies to many cases where the client-side data contains privacy-sensitive data. The only way to dynamically parse something that happens on the client side is by writing the template itself in JSON and sending it over as data.
Anyway, I hope you guys take a look at the examples on the homepage to get a glimpse of what makes ST.js powerful. Each example is almost its own library, except that you don't need a separate library for those purposes since all you're dealing with is JSON.
I think there's a lot of useful unexplored territory in this sort of tool. So much work nowadays is happening in maps/dictionaries/what-have-you, with a lot of work being, essentially, data shape transformation. Despite this, many languages aren't great at this! we have tools that work alright on first-order operations but fall apart on higher level things. Even really simple things like "conditionally include a key"…
foo = {
'a': 1,
'b': 2,
**({
'c': 3,
'd': 4,
} if bar else {}),
}
This adds `c: 3` and `d: 4` into `foo` conditional on `bar`.[1] https://docs.python.org/3/whatsnew/3.5.html#pep-448-addition...
Have you considered reaching out to DevOps folks to consider something like this for complex configurations?...There are related solutions such as jsonnet/ksonette but I think something like this might be preferable. I work on a similar problem though using a UI based approach, I gave a demo to the Kubernetes SIG App group a while back which be found here: https://www.youtube.com/watch?v=alEzE8MSNaI&t=30m Btw Ethan,…
In essence ST.js is a finite state machine implemented purely in JSON. So I can imagine it being used for things I haven't thought of, which is why I open sourced it. Would be really cool.
Please feel free to reach out at ethan.gliechtenstein[at]gmail thanks!