Just a note: we don't need to do anything and we shouldn't rush into anything. Technically by using hogan we are already using mustache since hogan is a subset of mustache.

Most importantly to consider before rushing to do this - Hogan is 3.4k JS and Mustache 8.835 kb

From what I understood we can load the front-end hogan templates in php with the mustache compiler without any problems, right? So this should probably be registering that hogan-extension-but-mustache-compiler for mobile frontend and keep using hogan for the frontend if it makes more sense because mobile.

In T127268#2499852, @Jdlrobson wrote:

The mobile site never migrated to Mustache due to a lack of motivation for 2 reasons [..]

2. Mustache is still substantially bigger than Hogan ( 3.4k).

Actually, Hogan is heavier on the network than Mustache, not the other way around.

• mediawiki.template.mustache – 3.2KB
• mediawiki.template.hogan – 3.7KB

Maybe Mustache was originally larger in 2015 (the comment T94086#1163105 suggest that). But it hasn't been larger since at least 2016 when I first compared the two. I thought I mentioned that before, but couldn't find it, so here it is.

In any event, the difference is negligible – not a deciding factor from a performance perspective.

I expect we will move away from templates altogether in mobile as we adopt webpack. Watch this space.

@Jdlrobson - You can still use mustache/hogan with webpack. https://www.npmjs.com/package/mustache-loader.

In T94086#4526922, @Jdlrobson wrote:

I expect we will move away from templates altogether in mobile as we adopt webpack.

I assume this means ES6 template strings. I'm happy to see a whole module (e.g. mustache.js) disappear from the stack without needing a replacement. That's cool, and as good as it can gets in terms of optimisation.

But, I do worry. In my opinion this isn't a win relating to Webpack or ES6, because we replaced the Mustache HTML templates with JavaScript string concatenation. String concatenation isn't new. It's possible with ES5 today. In fact, that's what most core modules and extension modules actually do already (Mustache wasn't widely adoption). And Popups' Webpack naturally also compiles the ES6 template strings to ES5 string concatenation.

If string concatenation is all we need, that's great actually. But, it would result in losses for MobileFrontend in some areas:

• Security. HTML templates have the benefit of security by default. Placeholders are considered textual unless otherwise specified.
• Review and Test automation. HTML templates are maintained in separate files that can be reviewed and automatically verified by CI for correctness (balanced hierarchy of elements).
• Structure. Separating JavaScript code from HTML.
• Re-use. The templates can be re-used between server-side interfaces and client-side interfaces, which avoids added maintenance cost of maintaining two versions of the same thing, and the bugs that result from that.
• Misc Mustache features (loops, partials, etc.).

String concatenation provides none of the above. (By default.)

On the other hand, despite the above benefits that Mustache HTML templates provides today, the status quo is that MediaWiki core and extensions don't actually use Mustache (which the exception of MobileFrontend and Flow). So if we do deprecate it, we wouldn't really lose much. But I thought MobileFrontend was leading in this direction.

Does that mean we're going to deprecate mw.template and Mustache.js in MediaWiki? I'd rather not maintain it as part of ResourceLoader if it isn't used.

Sorry to be slow to reply here. No definite decisions yet but we've talked about using Preact with jsx which would negate our need for templates.

We've also talked about importing mustache templates in js and thus compiling with webpack to compiled functions which would limit our need to use mw.template.

I think mw.template is still useful and mustache is still important for code that needs to work server/client side.

Will expand more when we have that conversation. We are at least 3-4 months away from that conversation.

I've been experimenting with vhtml as an alternative (https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/482387/) and I'm pretty happy with what I'm seeing there. Also on a plus note, it can be adopted with 0 bytes of additional code (and eventually with the removal of Hogan we would save code. The only thing that could prove tricky with vhtml is the lack of support for raw HTML.

Change 482746 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Experiment: Transpiled Hogan templates

https://gerrit.wikimedia.org/r/482746

I also experimented today with using mustache-loader per @kaldari suggestion -T94086#4528627 - it seems that this route requires upgrading Hogan to version 3 first (T205129) - however does provide a clear path just like vhtml to templates with 0 bytes of additional code.

Change 482746 abandoned by Jdlrobson:
Experiment: Transpiled Hogan templates

https://gerrit.wikimedia.org/r/482746

Change 482746 restored by Jdlrobson:
Experiment: Transpiled Hogan templates

https://gerrit.wikimedia.org/r/482746

Change 482746 abandoned by Jdlrobson:
Experiment: Transpiled Hogan templates

Reason:
The more I think about this the more https://gerrit.wikimedia.org/r/485090 seems like a better approach, since the main goal would be managing templates in webpack.

https://gerrit.wikimedia.org/r/482746

Looks like it's not ready for sign off, still blocked on T210866: Consolidate server and client templates and on rEMFR29b3629d8b96: 💥 Breaking change: Remove mediawiki.template.hogan

I misunderstood that task (still don't understand it) and thought it was a duplicate so this doesn't block sign off.

@Jdlrobson what about rEMFR29b3629d8b96: 💥 Breaking change: Remove mediawiki.template.hogan ? It's marked as WIP.

Because of caching implications we should hold off merging the breaking change for at least 1 week, preferably 2. We can still sign off without this.. we just neef to remember to clean up after ourselves and track that change separately.