Scalate: a Scala template engine with four syntaxes

One engine, four template languages

Scalate is a Scala based template engine which supports HAML, Mustache and JSP, Erb and Velocity style syntaxes, and the documentation breaks that down into four concrete dialects. Mustache is described as a Mustache template language for Java and Scala. Jade is the Jade style of the Haml or Scaml template language. Scaml provides a Haml style template language. And Ssp provides a JSP, Erb and Velocity style template language. Each has its own reference page in the documentation. The claim this supports is not that Scalate is good at any one of these, but that you can move between them without changing the engine, and in the specific case of a codebase that inherited a Mustache front end from one era and wants to adopt something more typed in another, that is a real problem to have solved. The topics on the repository are simply scala and template-engine, and the primary language is Scala.

Where the type safety actually comes from

The single most important technical statement in the README is about type checking. In Scaml and SSP all expressions are type safe and checked at edit or compile time, to ensure you do not leave mistakes in your pages. Mustache is different, and the documentation is upfront about the trade-off: it uses dynamic typing and reflection, which is a trade off of hiding code and logic from inside the templates. That sentence is doing a lot of work and it is worth reading carefully, because it describes a design decision rather than an inconsistency. In the typed dialects, a template expression that references a method the model does not have is a compile error. In Mustache, the same mistake is a runtime failure or a silently missing value. The practical consequence is that the choice of dialect is partly a choice about where template errors surface, and the choice of engine is partly a choice about that too.

The module list tells you the real scope

The repository is a multi-module sbt build, and the module names describe the integration surface better than any summary. There is `scalate-core/`, which is the engine itself, and `scalate-util/`, which is the shared utility layer. Then the web integration modules, `scalate-page/`, `scalate-guice/`, `scalate-jaxrs/`, `scalate-jersey/`, `scalate-jsp-converter/`, `scalate-spring-mvc/` and `scalate-jruby/`, covering the JAX-RS side, the Jersey implementation, the Guice dependency injection binding, a converter for JSP style sources, the Spring MVC integration and the JRuby runtime. There are also `scalate-wikitext/`, a Wikitext dialect, and `scalate-test/`, the test support module. Alongside the modules sit `scalate-website/`, which is the documentation site, `project/` for the sbt build definition, `src/` for the sbt plugins, a `build.sbt` at the root and a `version.sbt`. The build also uses Scala Steward through a `.scala-steward.conf` file and scalafmt through a `.scalafmt.conf`, so dependency bumps and formatting are handled by tooling rather than by hand.

Publishing, packaging and the reading of the README

The README is short, and the parts it does cover are the ones you need to make a decision. The build badge points at a GitHub Actions workflow for Scala, and the Maven Central badge names the artifact, `io.github.scalate/scalate-core_3`, which tells you the group id follows the GitHub Packages style rather than a domain based reverse of a URL, and that it is published for Scala 3. The building section links to instructions on the project site rather than repeating them, which is a sign that the build is a multi-module sbt project where a paragraph would do more harm than good. The links section points at the home page, a community page, the documentation and the issue tracker. The project site is at scalate.github.io/scalate, the licence is Apache-2.0 with the text in `license.txt` and a `notice.md` beside it, and the repository is not archived with the last push on 2026-10-19.

What a template engine like this is for

The reason to use a template engine at all, rather than string concatenation in a servlet or a controller, is that the template is a separate artefact that someone who is not the programmer can edit. Scalate supports that in a specific way. The Ssp dialect gives you the JSP, Erb and Velocity shape, so a team with JSP muscle memory can work in it and still get compile time checking on the expressions. The Jade and Scaml dialects give you the Haml shape, with the same checking. Mustache is there for the case where the template author should not see the code at all, which is the trade the documentation names, hiding code and logic from inside the templates at the cost of dynamic typing. If you are coming from Ruby on Rails, the Erb and Velocity styles in Ssp will feel familiar, and if you are coming from PHP or Java EE, the JSP style will. The engine's job is to let a team pick based on what its authors already know and what it wants checked.

Where this is the wrong choice

The limits are mostly about the cost of the abstraction. First, the multi-dialect design is a feature only if you actually have more than one dialect to serve. A team that has settled on one template style gains nothing from the other three, and pays for the abstraction in a larger engine and a larger documentation surface. Second, the compile time checking, which is the strongest argument for the project, is also a constraint. In a typed dialect a template that references a field the model does not have will not compile, which means the model and the template have to be updated together, and a designer working alone on a template cannot preview it until the model exists. Third, the integration surface is broad but each piece is a separate artifact, so the dependency you pull in is not just scalate-core, it is scalate-core plus whichever of the JAX-RS, Jersey, Guice, Spring MVC or JRuby modules your stack needs, and each of those has its own version line to track. Fourth, the Mustache dialect is explicitly the loose one, and a codebase that drifts towards it for convenience loses the type checking that made the rest of the engine worth choosing. And fifth, the project publishes no GitHub releases, so the versioning you track is whatever the artifact coordinates carry on Maven Central, which means reading the changelog file in the repository rather than a release page.

Editorial conclusion

Scalate fits a Scala team that has to keep templates from more than one tradition alive, for example a legacy Mustache front end next to a newer typed one, because the whole point of the project is that the four dialects sit behind one API. It is the wrong choice if you only need one syntax, since a single-dialect library will be simpler, and the wrong choice if compile time checking of templates is not a feature you want, because that check is where the type safety argument comes from. Before you adopt it, read the documentation for the dialect you actually need, and check the module list in the repository, since the integrations are separate artifacts and the one you need may not be the one you assumed. The last push was on 2026-10-19, the repository publishes no GitHub releases, and the licence is Apache-2.0.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. scalate/scalate on GitHub