Good afternoon,

I was reviewing the Mustache support for Spring Boot and I notice that the transitive dependency for the starter:

    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-mustache</artifactId>
    </dependency>

Is this project: https://github.com/samskivert/jmustache

But reviewing the documentation from Mustache: https://mustache.github.io/

I noticed that the official Java implementation is: https://github.com/spullara/mustache.java

Maybe Spring for Spring Boot 3.0 could consider to use the official dependency.

What is your opinion?

Reference:

  • https://spring.io/blog/2016/11/21/the-joy-of-mustache-server-side-templates-for-the-jvm

Many thanks in advance

Juan Antonio

Comment From: philwebb

We haven't really had any issues with https://github.com/samskivert/jmustache so I'm not sure we should switch just for the sake of it. Are there specific features in https://github.com/spullara/mustache.java that you want to use?

I'll flag this for team discussion to see what other folks think.

Comment From: wilkinsona

FWIW, both projects are "official" in that they're listed on https://mustache.github.io. JMustache was added in October 2010 and mustache.java was added in June 2010. JMustache is listed under Android but the reason for that is unclear.

Comment From: jabrena

Good morning @philwebb & @wilkinsona,

The motivation of this issue is about showing the evolution of the main transitive dependency for spring-boot-starter-mustache. Maybe in 2015-2016 in the design phase of the Spring Boot Starter both libraries could have a similar activity and relevance but now in 2022, both libraries doesn´t have the same pace and this is the point. Said that, I am not saying that jmustache doesn't cover the goals of the Spring Boot Starter but it is fact that mustache.java has more relevance than jmustache in the context of Mustache community itself and maybe dependency review could be a periodical activity in the maintenance operations of the different Spring Boot Starters: https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#using.build-systems.starters

I share few links about contributions:

  • http://ghv.artzub.com/#repo=jmustache&climit=500&user=samskivert
  • https://github.com/samskivert/jmustache/graphs/code-frequency
  • http://ghv.artzub.com/#repo=mustache.java&climit=500&user=spullara
  • https://github.com/spullara/mustache.java/graphs/code-frequency

@philwebb if you like, I will review more in detail both libraries to identify differences and understand why mustache.java is more popular (1.7k stars) vs jmustache (0.7k stars)

  • Where is the github location for the spring-boot-starter-mustache?

Juan Antonio

Comment From: wilkinsona

The code for the auto-configuration is part of spring-boot-autoconfigure and can be found here. The starter itself is just build system metadata. Its source can be found here.

Comment From: vpavic

JMustache is listed under Android but the reason for that is unclear.

Possibly because is uses Java 7 as a baseline, vs mustache.java that requires Java 8.

Comment From: jabrena

Hi @wilkinsona many thanks for the links, I will put focus on this package:

  • https://github.com/spring-projects/spring-boot/tree/main/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/mustache

At library level, I will review both libraries in isolation in coming weeks

@vpavic thanks for the observation, I didn´t enter in that detail.

Comment From: bclozel

Moving from one to the other is a breaking change as we're exposing the library types with our configuration. We should carefully consider this as we might make the 3.0 upgrade harder for a part of our community - the added value must definitely outweigh the migration pain.

Comment From: jabrena

Totally agree with you @bclozel, but at least to know the alternatives and efforts around it.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: jabrena

Hi,

I am working in the analysis but I will need more time. I try collaborating in my spare time :)

Juan Antonio

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-projects-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

Comment From: ben3000

Mustache.java implements template inheritance, while JMustache does not. For me, this is a great reason to consider using Mustache.java.

The Joy of Mustache article went to some lengths to build inheritance support using the JMustache-based starter, but that is no longer relevant now that the Mustache spec has template inheritance (and Mustache.java has implemented it).

Comment From: wilkinsona

This could either be done alongside the existing auto-configuration for JMustache or as a replacement.

Comment From: dagnelies

just my 2 cents:

  • jmustache appears to be used by way more projects (pulled as dependency) than mustache.java
  • mustache.java appears to have a slightly larger community (which is weird considering previous point)
  • The docs are currently clearly better for jmustache
  • IMHO jmustache has a more comfortable API than mustache.java
  • template inheritance is an optional feature in the specs, a controvertial one at that, so it does not convince me as justification
  • "swapping the engine" is likely to break things because jmustache also has several custom extensions

So in the end, I'm currently not in favor of such a change. Providing both is also likely to increase confusion and fragmentation, so I'm not really fond of it. My two cents. I'm not affiliated with either.

Comment From: vpavic

Perhaps worth noting here is that another Mustache templating engine for Java, jstachio (that is also type-safe and statically compiled), is gaining popularity and maintains its own support for Spring (including Spring Boot starter).

Given the already fragmented market of Mustache templating engines for Java, perhaps Spring Boot reference manual could include a sentence or two to also mention other options and steer users towards researching before deciding on Mustache templating engine that fits their projects the best?

Comment From: ben3000

I'm leaning towards jstachio after using it in an application I'm developing. Both jmustache and mustache.java appear stable, but not much development is occurring on them.

I don't find template inheritance controversial; I find it a requirement for any templating tool I adopt, but obviously, others may differ, and that's fine.

Comment From: agentgt

Hi guys. I'm the author of JStachio. I would love JStachio as the default mustache implementation for Spring Boot but I think JMustache should remain the default. The only exception is for Spring Boot Native applications to default to it but I am not sure if there is some selection mechanism that detects that.

JStachio requires more build setup than JMustache that I think would impede on the instant gratification of boot.

They can easily switch to JStachio later.

I will let @dsyer chime in if he agrees or not.

I strongly agree with @dagnelies comments. I do not recommend Mustache.java at this time. While JStachio is backward compatible with JMustache, Mustache.java is not mainly because it does not handle whitespace consistently, and does not have -first, -last, its lambdas API is not compatible (no stack access) and it also is much harder for users to learn as it not as well documented.

Mustache.java is a great implementation I just don't think given the above and how JMustache was used/promoted by @dsyer in the original The Joy of Mustache: Server Side Templates for the JVM that it is the right library to default to.

Finally I plan on updating JMustache to add template inheritance and make it mostly v1.3 complaint with as minimal code changes as possible.

Comment From: dsyer

I also think template inheritance is important- it just wasn’t available when we started this journey. Now that it is, I would be very excited to see it in JMustache (and it’s probably a great way for JStachio to build a user base by being more compatible because switching is not so easy until that happens).

If someone published a library providing mustache.java autoconfiguration for Spring Boot I guess it might be interesting to try. There’s no reason IMO to do that in Spring Boot, given the long history of JMustache, until it gets some usage.

Comment From: ben3000

Thanks @agentgt and @dsyer; I think updating JMustache to add template inheritance is the best solution given the relative approachability of JMustache over JStachio for users new to Boot (and annotation processors).

Comment From: agentgt

@ben3000 , @dsyer @dagnelies et al:

JMustache hopefully very soon will have inheritance and with the exception of dynamic names is Mustache v1.3 compliant.

I have tried to make sure not to break API but currently the code is compiled for JDK 9 which given most usage of the library is probably Spring Boot I think is probably OK.

@samskivert has been super gracious accepting my (often broken) PRs 😄

Comment From: agentgt

While checking JMustache performance to check if my inheritance work hurt it appears JMustache is very fast for a reflection based template engine.

One could argue another possible reason to stay with JMustache over Mustache.java is it appears to be faster than Mustache.java:

Benchmark             Mode  Cnt        Score       Error  Units
JMustache.benchmark  thrpt    3   452515.927 ± 15011.846  ops/s
Mustache.benchmark   thrpt    3   439038.481 ± 13115.726  ops/s
JStachio.benchmark   thrpt    3  1123496.944 ± 28827.781  ops/s

https://github.com/agentgt/template-benchmark (JMustache is snapshot so the build is broken).

So JMustache is probably given Mustache.java results the fastest reflection based template engine at the moment! (caveat based on my benchmarking and my machine etc etc).

Comment From: agentgt

@ben3000 @dsyer and others:

JMustache 1.16 has been released and supports inheritance!

It does not support v1.3 optional dynamic names yet. I will probably add a version of that for partials but not for regular variables I consider it slightly dangerous. JStachio will only support dynamic partial names and not variables (it is not finished but is planned). From my understanding very few implementations support dynamic names as variables and very few even know about it. Mustache.java I believe supports dynamic partials and I think names.

I will continue to help support JMustache going forward so I think it is not risky to stick with it. Furthermore I plan on improving the documentation of JMustache as well as transition guides for those that want to use compiled templates via JStachio.

For the above reasons for me that it is enough to close this issue.

Comment From: wilkinsona

Thanks, all, and @agentgt in particular. Given the new capabilities in JMustache 1.16 I don't expect us to add auto-configuration for mustache.java in the foreseeable future. We'll upgrade to the latest JMustache release in due course.

Comment From: paolopan83

Mustache.java is musch easier to use and has more features, this is really a pity

Comment From: agentgt

@paolopan83

Mustache.java is musch easier to use and has more features, this is really a pity

What particular features are you missing from JMustache that Mustache.java has?

Technically JMustache (and JStachio) has lambda support with access to the context stack. Mustache.java does not (well last I checked) but does have support for named partial variables. (aka {{> *someTemplateNameString }}).