Thread:Talk:Requests for comment/HTML templating library/KnockoutProposal/General thoughts


 * 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.