As a strictly experimental project, i applaud this effort and i hope the author learned a lot about building a library. The web presentation is above average as far as library projects go.
As the library itself, i would't touch this with a 100 foot pole. Serializing logic shatters encapsulation as well as cohesion, both cornerstone object oriented principles. Also, when you serialize logic, you leave yourself handicapped to fix code bugs, as your code bugs are now data bugs by definition. Imagine solving an off-by-one style error in persisted JSON logic. Your choices would be regex (shiver) or a script to parse all json blocks and modify accordingly? Yikes.
As an experiment, this is quite nice. Perhaps too nice. Given the quality of presentation, i feel bad for the shops that decide to adopt this into production usage.
As soon as you begin accepting user data, all your code bugs, even those as simple as forgetting to collect some metadata you might need later, are data bugs. And to the specific point about serializing logic being considered harmful, I'm sure https://www.periscopedata.com/ would beg to differ!
Seriously, though, there's nothing wrong with using this for a presentation layer. Define a group of user-selectable client-side filters in a JSON constants document, which will have a much smaller "error surface" than defining custom filter functions. Just because it looks like JSON doesn't mean it necessarily needs to be serialized.
That said, there are a number of inefficiencies in the implementation. Certainly not production ready, but a great effort.
I agree if we're talking about serialising app logic, but I think this library is for when your data is a ruleset you want to save/execute, some kind of conditional tasker etc.
> Also, when you serialize logic, you leave yourself handicapped to fix code bugs, as your code bugs are now data bugs by definition.
This seems to be an orthogonal architectural problem. If you need to be able to reprocess after changes to logic, chances are that you are storing your original source document somewhere and can retransform if necessary.
As the library itself, i would't touch this with a 100 foot pole. Serializing logic shatters encapsulation as well as cohesion, both cornerstone object oriented principles. Also, when you serialize logic, you leave yourself handicapped to fix code bugs, as your code bugs are now data bugs by definition. Imagine solving an off-by-one style error in persisted JSON logic. Your choices would be regex (shiver) or a script to parse all json blocks and modify accordingly? Yikes.
As an experiment, this is quite nice. Perhaps too nice. Given the quality of presentation, i feel bad for the shops that decide to adopt this into production usage.