Frontend standards group/2014-09-25-Weekly

From MediaWiki.org
Jump to navigation Jump to search

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?

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