MediaWiki

Frontend standards group/2014-09-25-Weekly

< Frontend standards group

Agenda

edit

Templating language

edit

RFC quick review...

edit
  • 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

DOM-based / ability to bind properties

edit

Advantages:

edit
  • 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.

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.

Disadvantages

edit

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

  • Supports placeholder values 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

edit
    • 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

edit

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

Roadmap

edit

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

Agenda for next meeting

edit

Status check in

edit
  • Icons
  • Skin System
  • Roadmap


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

Retrieved from "https://www.mediawiki.org/w/index.php?title=Frontend_standards_group/2014-09-25-Weekly&oldid=4012003"