[gliechtenstein]

Hi, my name is Ethan. I'm the creator.

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.

[eccenux]

The project is interesting... But I don't understand your point about JSON vs JS.

1. You can store JS anywhere (all DBMS support text).

2. You can send it over the Internet... Like everything else nowadays.

3. You can compose JS easily.

4. You can validate JS using linters.

5. etc.

Besides... Aren't you only disguising functions in strings? You can eval strings anyway.

[mholmes680]

This is cool, nice job. And thanks for open sourcing the Jasonette code.

I've done something similar to ST out of the same frustrations at work, but my use case was way more specific, and you took it way farther with better execution.

[fiatjaf]

So Jasonette functions are just about transforming the model, all in a reactive way? Like view->events->transform model->view?

[gliechtenstein]

It can transform anything that's written in JSON, which means both model and view and anything else.

One of the use cases for ST.js in Jasonette is dynamic client-side rendering, where it takes dynamic data and renders it against the template, after which it becomes native components.

Another use case is implementing actual functional programming. This one is not as straight-forward since it involves maintaining another separate state machine for function call stack. But this is also achieved using ST templates. Here's a blog post that talks about it in detail http://blog.jasonette.com/2017/02/15/functional-programming-... but it's a bit involved.

Also Jasonette has something called mixins, which you probably can guess based on its name. It lets you mix in JSON objects into another, so that you can make the app modular. That's also achieved internally using ST.

Overall, I believe even I'm just scratching the surface of what this can do, which is why I decided to take some time to clean things up and prepare and open it up as its own repo, because I think there's tons of other things that can be done by taking advantage of the fact that all that's happening is:

JSON A + JSON B = JSON C

Hope this makes sense!

[dualogy]

> Another use case is implementing actual functional programming

I remember our chat 8 months earlier on Reddit about this: https://www.reddit.com/r/functionalprogramming/comments/5ufm...

Yeah. You're still aiming for "functional programs encoded as (essentially) s-expressions but written in JS-Object-Notation (JSON) instead of LISPy parens". And that's still fine if you see that as a major leap forward. Not sure about the audience, those who want to "functionally program a mobile quasi-native APP that can self-update from a server" and know what the "functionally program" part means, wouldn't they reach for JS via React Native? Same selling points implicit already. Is it for those who never programmed but are expected to declaratively express functional idioms in your JSON notation without needing to install all sorts of dev tools and SDKs? Not entirely implausible at all I guess. Curious to see who will end up as your target audience. =)