Wow I forgot about those. Templating in general sucks, it’s just so hard to create something that makes a program accessible and has safety for user generated content.
Well, I use templating languages and I think they are quite useful. I've used many in my career, probably 10 or more. Now there is another one, which is good to know I guess.
Math (significant math), encoding and hashing being done on the client sounds like a poorly designed application. Same for templating on the server -- which I assume you mean manually compiling templates using a library, and sending the result to a client, perhaps as a property of a JSON object.
I've seen (and still use to a small extent) a templating language like that. The real exciting thing is the documentation! There is none, so you scrape through the existing codebase to find one that is doing the sort of thing you want to do and copy it
Doesn't help that the interpreter for it was not written in a language we use and it is stuck on a particular version due to some bytecode libraries we don't have the source to
I don't think so. I think the purpouse is to offer less: We don't even have built-in helpers or file loading mechanisms or caching. The philosophy is that we just do templating, we do it really well, and the rest is code from your stack. This philosophy has worked with our projects.
Right, my point was that templating was a concern of the UI, yet I wanted to be clear that business logic and data services remain the domain of the application server. Further I try to remove templating from any run-time concern (server or client) by doing all static content templating in a CMS and then publishing it to a web server.
reply