Frontend standards group/2014-09-25-Weekly

= Agenda =

Templating language

 * Review RFC (https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library and subpages)
 * open questions on dynamicalization of statically-generated template output?
 * (does this relate to oojs ui server-side generation?)

RFC quick review...

 * mustache?hogan?which do we use?
 * pretty much everybody's saying mustache/handlebars (keep it simple)
 * what's the difference with hogan? (a reimplementation)
 * TODO: figure out what differences if any for the recommendation


 * lightncandy -- handlebars PHP implementation
 * very fast
 * flexible, works with logic in templates
 * recommended by shahyar

Flow examples: * https://github.com/wikimedia/mediawiki-extensions-Flow/blob/master/handlebars/flow_block_topic_edit_title.handlebars * https://github.com/wikimedia/mediawiki-extensions-Flow/blob/master/handlebars/flow_anon_warning.handlebars

Advantages:
Roan: Testing. One can lint templates. Gabriel: There's DOM-based libs that parse mustache/handlebars-like syntax even. <- this could be very interesting for later Precompilation server-side can improve sever-side (memcached?) and front-end (resourceloader) execution.
 * Security. Significantly improve ability to enforce and review security.
 * Performance of addition/updates (not initial render): Improves front-end re-rendering/update performance 1) a template lib can render minimally, more finetuned than manually selecting/updating ever could, plus no selector overhead. 2) a template lib can combine reflows, whereas a widget abstraction would not realistically do this.
 * Non-intrusive. It's a silent non-intrusive feature. Doesn't make it harder for developers day-to-day. Manually selecting still works if you want to or have to.
 * proof of concept DOM / tassembly compiler for handlebars syntax: https://github.com/gwicke/TemplatePerf/tree/master/handlebars-htmljs-node

Disadvantages
What are the advantages of picking a library that wouldn't support DOM/bind properties?


 * Supports placeholder that produce invalid HTML.

Brion's recomendation is to move forward with handlebars and keep watch over dom based template libraries for the future. Brion will take this recomendation to the arch comittee
 * coding guidelines -- beware of helper functions (or even disallow them ;) (they're in use in flow but need cleanup)
 * helpers must be registered explicitly. recommend locking down and not doing too many yet.
 * (note theyd have to be implemented separately for JS and PHP)

Server-side OOUI

 * How to bind the generated HTML to the JavaScript objects.
 * (shared html templates that are recognised, KnockoutJS-like bind detection without rerendering the DOM)
 * Need to reconstitute live objects from static HTML as well as when building from scratch
 * Config array could be added as data attribute; walk the DOM tree to find parent/mixin parameters
 * Note that things can be added in JS (progressive enhancement)
 * -> Trevor going to test with using the same 'enliven' path after either construction method

Actions
Brion to take our input to next RFC meeting on Wed. Trevor to experiment with revival of HTML to JavaScript object.

= Roadmap = https://www.mediawiki.org/wiki/Frontend_standards_group/Roadmap

Status check in

 * Icons
 * Skin System
 * Roadmap

[1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library#Performance