may be a good idea to rely on #5 as Handlebars was smart to rely on this API that is already useful.

specifically:

• if and unless
• with
• lookup
• log
• possibly blockHelperMissing and helperMissing

refer to: http://handlebarsjs.com/builtin_helpers.html

based on research/template.js build a transpiler to match all features shown in research/template/html

need to build this out more but here's the general things to handle:

• broken tags (html spec)
• broken tags (inside two different blocks)
• block missing end

This is not to be confused as supporting the handlebars api (#7), only its template syntax.

Pretty much a silly idea as you'd want to reference the previous templates and use update to get any real performance, but still a possibility if the general speed over handlebars is actually still better.

side notes:

• maybe have build option for minimized templates that don't optimize for on the fly updates for this? (aka no binding support other than initial render)
• this would most likely encourage the incorrect usage of whiskers, if we intend to be high performance this should be scrapped.

currently we'll be morphing the (https://www.npmjs.com/package/lex) library into a stream to maintain this paradigm.

the general rule adding and state API should follow the lex library and continue our wrapper of it.

create either a polyfill or seperate build for backend to render and place data attributes for template binding on the frontend.