3 ms·
I don't think that's fair since a templating engine could easily avoid the actual with statement but provide same convenience. Optimization should be done in th
by esailija 13y ago
I don't think that's fair since a templating engine could easily avoid the actual with statement but provide same convenience. Optimization should be done in the implementation (which is fully possible here) and not at the cost of API ergonomics.
- jashkenas 13y ago> a templating engine could easily avoid the actual with > statement but provide same convenience I'm afraid that's not possible. If you look at other micro-templating libraries that allow arbitrary JavaScript values, you'll find that there are two options. Either you can support naked variables, and you have to use "with" to bring them into scope ... or you have to prefix all of your variable accesses off a "data" object, which is less ergonomic, but faster. Underscore supports both. If you've got a patch that is able to do otherwise, I'd love to see it ;)
- esailija 13y agoI wasn't aware that the benchmark comparison was about micro-templating, it includes libraries like handlebars. I am sure you realize you can just walk the AST for what identifiers are being used in the template code and forward declare them in the generated code so that reference errors are not caused.
- jashkenas 13y agoIf you allow arbitrary JavaScript, then I'm sure you realize that you can't "just walk the AST" ;) At compile time, you have no idea which identifiers are incoming data values — to be supplied by the caller of the template function — and which identifiers already exist in scope.
- esailija 13y agoLet me put it in code terms. In the following template script: <div>@hello</div> The generated code can be like (not including runtime lib): var ___html = ""; var hello = hasown.call(data, "hello") ? data.hello : ""; ___html += '<div>' + safeString(hello, HTML_GENERIC) + '</div>'; return ___html; Which gives same effect as `with`.