Topic on Talk:Requests for comment/HTML templating library/Knockoff - Tassembly

1. (Size) 16 KiB compressed is understatement, because RL does not do strong minification. In practise if we load it through RL the size is going to be a bit higher because of that.
2. (Fork?) It looks like you are planning to do fairly extensive changes as opposed to just using KnockOut.js directly. It is unclear to me how this will be maintained, what changes need to be made to KnockOut.js itself and what is just our own additions.
3. (Complexity) KnockOut.js syntax looks very complex. I understand that we do not want to use string-based templating systems, but that doesn't mean we need to choose a one that embeds a full programming language inside it. (In any case I will have a lot of porting work to do)
4. (???) I do not understand section MediaWiki messages in JSON IR at all. It seems to assume a certain goal that the implementors want to achieve which is not written down.
5. (Integration) I disagree with the statement Knockout.JS is immediately ready to be used as a reactive templating library on the client. I've used Mustache on my own, but without RL integration it is quite painful. In this proposal the actual MediaWiki RL integration seems to be collapsed into one bullet: template delivery via ResourceLoader. I would like to see more content how the actual integration will look. Will there be a key 'templates' in RL modules? What are the naming conventions and file extension for templates? How about i18n integration (see my other thread)? Compare with https://gerrit.wikimedia.org/r/111250 . And how about client side? How will I add a template on the page after it has been loaded by RL?
6. (Integration2) And going even further (out of scope for this RFC probably), templates are going to need data, for example via the WebAPI. There should be some way that RL modules can request data delivered from API modules without extra round-trip. It might also be possible that we want to do it in an other way, to create data providers that are easy to use in PHP but also provide automatic RL or WebAPI wrapping to accomplish the data delivery to client side.

Quick note about including templates *dynamically* and having them start updating right away. Here's an example of a custom binding to do that:

https://github.com/wikimedia/limn/blob/master/src/util/knockout/subview-binding.co

This post was posted by Milimetric (WMF), but signed as DAndreescu.

Some replies:

1. Possibly, although I'd imagine it to be possible to check in a pre-minified version if we want.
2. For client-side rendering the main task is hooking up messages etc. We can also syntactically restrict what is allowed in expressions (for sanity and compatibility with server-side templates), but that is really optional. Stock KnockoutJS can be used as-is (and is already used by analytics), although I agree that RL integration is very desirable for MW.
3. Basically see 2), either by convention or by enforcing it in the KnockoutJS expression compiler (a simple regexp).
4. I think we touched on this in the discussion. We can basically compile messages to the JSON IR and then execute it using the same runtime.
5. KnockoutJS templates can be dynamically added in the model (as a reference to a DOM node) or as an id in the page DOM. The details of the RL integration are not yet set in stone. We will definitely look closely at what has been done in that area so far (thanks for the links!) and will solicit input.
6. We actually thought about data sources a bit, with the option to pull data asynchronously vs. statically determining the data that is going to be needed at compile time and pre-loading it. The problem with statically determining data sources is that you need to be conservative about which branches are taken, so you might end up more data than actually needed. On the server we'll probably do this as an async / parallel pull similar to the way Parsoid works internally. On the client the expense depends on whether the content is pre-rendered (and only needs to be updated later) or not.