Page MenuHomePhabricator

[EPIC] Migrate MobileFrontend templates from hogan to inlined mustache templates
Closed, ResolvedPublic


Now that client-side HTML templating has been merged into core ( we need to migrate MobileFrontend to start using it (rather than using the local Hogan library). Most of the MF templates should be migratable with no changes (other than changing the filename extension).

In QuickSurveys and Card extension we have to create a custom compiler called muhogan that loads either mustache or hogan library to compile templates. The templates used are compatible with both languages. Should we upstream hogan and replace mustache with it in core? Should both live in core? Should we use mustache in MF? Should we do something else?

Developer notes

Using JSX and a webpack transpiler seems a modern approach for doing templating. It avoids the need for a template library while solving the problem of readability.

Sign off steps

  • All existing subtasks have been resolved
  • A task has been created to ensure the mediawiki.template.hogan module gets fully removed (Patch is here:
  • The change is documented on the release timeline

Related Objects

Resolved Niedzielski
Resolved Niedzielski

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 26 2015, 8:34 PM

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.

Jdlrobson changed the task status from Open to Stalled.May 1 2015, 6:40 PM
Jdlrobson renamed this task from Migrate MobileFrontend templates from hogan to mustache to [EPIC] Migrate MobileFrontend templates from hogan to mustache.Sep 3 2015, 4:33 PM
Jdlrobson edited projects, added MobileFrontend; removed Readers-Web-Backlog.
Jdlrobson set Security to None.
Jdlrobson moved this task from Backlog to Epics on the MobileFrontend board.Sep 4 2015, 5:51 PM
Jdlrobson triaged this task as Low priority.Sep 8 2015, 12:28 AM
Jdlrobson renamed this task from [EPIC] Migrate MobileFrontend templates from hogan to mustache to [EPIC] Migrate MobileFrontend templates from hogan to mustache / Use template transpiler.Feb 7 2018, 7:26 PM
Jdlrobson changed the task status from Stalled to Open.Feb 22 2018, 10:18 PM
Jdlrobson updated the task description. (Show Details)
Krinkle added a subscriber: Krinkle.EditedAug 23 2018, 5:14 AM

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

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

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

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.

kaldari added a comment.EditedAug 23 2018, 11:17 PM

@Jdlrobson - You can still use mustache/hogan with webpack.

Krinkle added a comment.EditedAug 29 2018, 4:05 AM

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.

Jdlrobson raised the priority of this task from Low to Needs Triage.Aug 30 2018, 1:32 AM

I've been experimenting with vhtml as an alternative ( 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

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

Change 482746 restored by Jdlrobson:
Experiment: Transpiled Hogan templates

Change 482746 abandoned by Jdlrobson:
Experiment: Transpiled Hogan templates

The more I think about this the more seems like a better approach, since the main goal would be managing templates in webpack.

Jdlrobson renamed this task from [EPIC] Migrate MobileFrontend templates from hogan to mustache / Use template transpiler to [EPIC] Migrate MobileFrontend templates from hogan to inlined mustache templates.Apr 1 2019, 10:12 PM
Jdlrobson changed the status of subtask T219845: Swap Hogan for Mustache from Open to Stalled.Apr 2 2019, 12:00 AM
Krinkle removed a subscriber: Krinkle.Apr 15 2019, 9:12 PM
Jdlrobson updated the task description. (Show Details)May 1 2019, 9:53 PM

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

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.

Jdlrobson assigned this task to pmiazga.May 6 2019, 5:05 PM
pmiazga closed this task as Resolved.May 6 2019, 10:00 PM
pmiazga updated the task description. (Show Details)