I’m of the opinion that supporting the
eval statement in template languages is a Bad Idea, precisely because it’s such a useful outlet to have. How many of us have been delighted to write a short script in PHP, only to later bemoan the spaghetti code that ultimately results over the lifetime of the project.
Many expressions can be evaluated in here. Now there’s a lot of things you shouldn’t do in here [inside the template’s
evalaffordance]. You should keep this logic to a minimum. Because this is your view and presentation. But there’s really quite a lot of things you can do in there.
Careful planning of architectural constraints is a bit like user interface design. Like user interfaces, development frameworks offer affordances (the commands they support), require learning (tiptoeing around the framework’s particular constraints), and benefit from homogenization.
But when you provide support for
eval, it creates an easy escape hatch that prevents homogenization. If something doesn’t fit into your framework well, rather than fix the problem (or decide it isn’t important), one can just jump through the
This opinion might sound extreme, but I think it is called for when you consider that good framework designers strive to provide guarantees about the behavior and performance of code using their framework. This requires reasoning about code, and reasoning about code requires a declarative view of computation which
eval destroys. It’s the difference between a toolbelt, like
backbone.js and what you might call a Proper Architecture, like