Hi everyone,
We've been talking about the HTML templating RFC since the Architecture Summit in January. And in the Mobile quarterly review the other day, they said - see https://commons.wikimedia.org/w/index.php?title=File%3AMobile_Web_%26_App_Qu... - that they would love a decision soon. So it seems like we ought to figure it out so it can get off the RfC docket. :-)
https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/...
I think this is what's up: Many developers like the work that Matt and Gabriel have been doing on Knockoff, but we're currently lacking all of the pieces necessary to make a final call. Some folks were testing it out and need to report back to the list with their verdicts. In the meantime, some developers (such as the Mobile and Flow teams) have short-term needs that can't wait up for Knockoff to become a complete solution, and so are working out interim standardizations outside of this mailing list so that they can move forward while Knockoff work continues. (Not sure what all of them are.)
Is this about right? Should I be saying Knockoff or Knockout? Can I put the RfC decision meeting on the calendar for next week? :-)
Sumana Harihareswara Senior Technical Writer Wikimedia Foundation
On Jun 3, 2014 2:56 PM, "Sumana Harihareswara" sumanah@wikimedia.org wrote:
Some folks were testing [Knockoff] out and need to report back to the list with their verdicts.
Who? Tell us more!
In the meantime, some developers (such as the Mobile and Flow teams) have short-term needs that can't wait up for Knockoff to become a complete solution, and so are working out interim standardizations outside of this mailing list so that they can move forward while Knockoff work continues. (Not sure what all of them are.)
MobileFrontend has been using Hogan JS templating since January 2013.
Flow recently chose handlebars JS templating because it has a working fast PHP re-implementation (lightncandy) to support no-JavaScript clients.
For client-side templating you need ResourceLoader to supply the templates to the client. Jon Robson has developed the Mantle extension[1] that implements * a ResourceLoaderTemplateModule that does this * JS functions that abstract getting a template, compiling and caching it, and rendering it * specific implementations of these functions for the handlebars and hogan JS libraries.
MobileFrontend and Flow will start using this shared code in production in the next few weeks or so.
In order for Flow to share templates between front-end JS and server PHP, Flow has had to write helper functions in both JS and PHP[2]. Some like message i18n, human-friendly timestamps, escaping, etc. are more generic than others.
These experiences in generalized JS template support and developing helper functions across JS and PHP could inform Knockoff development. So far the Flow team is doing well with handlebars/lightncandy templating but we're not advocating it over Knockout/Knockoff. The reactive model-view updating of Knockout (in JavaScript) is an attractive additional feature missing from Hogan and handlebars templating; again, Flow couldn't wait.
Should I be saying Knockoff or Knockout? From the RFC page, Gabriel WIcke & Matthew Walker's "Knockoff"
templates are KnockoutJS compatible. AIUI, GW&MW have a JS compiler that compiles them into GW&MW's "Knockoff - Tassembly" intermediate representation, and their goal is to to render templates in the latter format from both PHP and JavaScript. In JavaScript you'd still load the Knockout JS for its reactive model-view updates.
Hope this helps. No slight intended to any others working on GW&MW MW KO code :)
[1] https://www.mediawiki.org/wiki/Extension:Mantle#Templates [2] https://www.mediawiki.org/wiki/Flow/Architecture/Templating
-- =S Page WikiMedia Features engineer
In the meantime, some developers (such as the Mobile and Flow teams) have short-term needs that can't wait up for Knockoff to become a complete solution, and so are working out interim standardizations outside of this mailing list so that they can move forward while Knockoff work continues.
The first iteration of the implementation has actually been complete for a while now, see Matt's mail here on April 14 [0]. There's a JS implementation of the KnockOff compiler [1] and JS [2] and PHP [3] implementations of the TAssembly runtime.
We are waiting for feedback before starting the second iteration. At least the mobile team had plans for giving it a spin, but I have not heard about that since.
For client-side templating you need ResourceLoader to supply the templates to the client. Jon Robson has developed the Mantle extension[1] that implements
- a ResourceLoaderTemplateModule that does this
- JS functions that abstract getting a template, compiling and caching
it, and rendering it
- specific implementations of these functions for the handlebars and
hogan JS libraries.
MobileFrontend and Flow will start using this shared code in production in the next few weeks or so.
In order for Flow to share templates between front-end JS and server PHP, Flow has had to write helper functions in both JS and PHP[2]. Some like message i18n, human-friendly timestamps, escaping, etc. are more generic than others.
These experiences in generalized JS template support and developing helper functions across JS and PHP could inform Knockoff development.
Yes, large parts of this infrastructure will be useful with Knockoff / TAssembly as well.
Should I be saying Knockoff or Knockout?
From the RFC page, Gabriel WIcke & Matthew Walker's "Knockoff" templates are KnockoutJS compatible. AIUI, GW&MW have a JS compiler that compiles them into GW&MW's "Knockoff - Tassembly" intermediate representation, and their goal is to to render templates in the latter format from both PHP and JavaScript.
KnockOff is the KnockOut template to TAssembly compiler, while TAssembly is the JSON-based intermediate format with runtimes in JS & PHP.
In JavaScript you'd still load the Knockout JS for its reactive model-view updates.
This is possible due to the shared template syntax, but not necessary. If reactivity is not needed & performance / size is a priority then using the TAssembly runtime might make more sense. It's a lot smaller & faster.
KnockOff & TAssembly are a part of the longer-term vision of moving to HTML as our primary content representation. I have started to draft a high-level overview at [4]. We (the new service team [5]) plan to explore this further in collaboration with the Parsoid team.
Gabriel
[0]: http://lists.wikimedia.org/pipermail/wikitech-l/2014-April/075995.html [1]: https://github.com/gwicke/knockoff [2]: https://github.com/gwicke/tassembly [3]: https://github.com/mattofak/knockoff [4]: https://www.mediawiki.org/wiki/HTML_content_templating [5]: https://www.mediawiki.org/wiki/Wikimedia_Engineering/Service_and_REST_API_te...
Ryan Kaldari recently wrote and said it was OK for me to forward:
"The Mobile web team finally dedicated some time to investigating Gabriel's Knockoff-Tassembly templating system. Specifically, I was tasked with answering the questions at https://trello.com/c/lYfyzs8A/6-spike-explore-knockoff-templating.
The results of my investigation are at: https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/... "
Sumana Harihareswara Senior Technical Writer Wikimedia Foundation
On Wed, Jun 4, 2014 at 6:46 PM, Gabriel Wicke gwicke@wikimedia.org wrote:
In the meantime, some developers (such as the Mobile and Flow teams) have short-term needs that can't wait up for Knockoff to become a complete solution, and so are working out interim standardizations outside of this mailing list so that they can move forward while Knockoff work continues.
The first iteration of the implementation has actually been complete for a while now, see Matt's mail here on April 14 [0]. There's a JS implementation of the KnockOff compiler [1] and JS [2] and PHP [3] implementations of the TAssembly runtime.
We are waiting for feedback before starting the second iteration. At least the mobile team had plans for giving it a spin, but I have not heard about that since.
For client-side templating you need ResourceLoader to supply the templates to the client. Jon Robson has developed the Mantle extension[1] that implements
- a ResourceLoaderTemplateModule that does this
- JS functions that abstract getting a template, compiling and caching
it, and rendering it
- specific implementations of these functions for the handlebars and
hogan JS libraries.
MobileFrontend and Flow will start using this shared code in production in the next few weeks or so.
In order for Flow to share templates between front-end JS and server PHP, Flow has had to write helper functions in both JS and PHP[2]. Some like message i18n, human-friendly timestamps, escaping, etc. are more generic than others.
These experiences in generalized JS template support and developing helper functions across JS and PHP could inform Knockoff development.
Yes, large parts of this infrastructure will be useful with Knockoff / TAssembly as well.
Should I be saying Knockoff or Knockout?
From the RFC page, Gabriel WIcke & Matthew Walker's "Knockoff" templates are KnockoutJS compatible. AIUI, GW&MW have a JS compiler that compiles them into GW&MW's "Knockoff - Tassembly" intermediate representation, and their goal is to to render templates in the latter format from both PHP and JavaScript.
KnockOff is the KnockOut template to TAssembly compiler, while TAssembly is the JSON-based intermediate format with runtimes in JS & PHP.
In JavaScript you'd still load the Knockout JS for its reactive model-view updates.
This is possible due to the shared template syntax, but not necessary. If reactivity is not needed & performance / size is a priority then using the TAssembly runtime might make more sense. It's a lot smaller & faster.
KnockOff & TAssembly are a part of the longer-term vision of moving to HTML as our primary content representation. I have started to draft a high-level overview at [4]. We (the new service team [5]) plan to explore this further in collaboration with the Parsoid team.
Gabriel
[5]:
https://www.mediawiki.org/wiki/Wikimedia_Engineering/Service_and_REST_API_te...
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org