# Closure Templates compile one component set for client and server > Closure Templates, also known as Closure Soy, is a client and server side templating system for building reusable HTML and UI elements, with a data model and expression syntax that work in Java or JavaScript, contextual autoescaping and inline translation messages. It suits a large JavaScript front end that wants component templates without a runtime framework, and its open source support is explicitly minimal. **google/closure-templates** — A client- and server-side templating system that helps you dynamically build reusable HTML and UI elements - Repository: https://github.com/google/closure-templates - Stars: 702 · Forks: 199 - Language: Java - License: Apache-2.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/google-closure-templates ## Components rather than one template per page Closure Templates are a client and server side templating system that helps you dynamically build reusable HTML and UI elements, with a simple syntax natural for programmers. The difference from a traditional templating system is stated early and it is the key idea. In a traditional system you create one monolithic template per page, whereas with Closure Templates you think of them as small components that you compose to form your user interface. That composition model is what makes a large application tractable, because each component has its own data and can be reused in more than one place. The templates can be customised to fit an application's needs, and the built-in message support lets you localise the application. The language is not limited to one runtime. Closure Templates are implemented for both JavaScript and Java, so the same template can be used on the server and on the client, with a data model and expression syntax that work for either language, and on the client side the templates are precompiled into efficient JavaScript. ## The stated benefits and what they imply The README lists the reasons to use the system, and reading them tells you what kind of project it suits. Convenience, in that it provides an easy way to build pieces of HTML and helps separate application logic from display. Language neutrality, because you can write one template and share it between client and server code. Client-side speed, from compiling to efficient JavaScript functions for maximum client-side performance. Easy to read, since you can see the structure of the output HTML from the structure of the template code, and messages for translation are inline for extra readability. Designed for programmers, because templates are simply functions that can call each other, with multiple templates allowed in one source file. It is a tool, not a framework, and it works well in any web application environment with any libraries, frameworks or other tools. And it is secure, with contextually autoescaping to reduce the risk of XSS. That last point is the one to examine for your own context, because contextual autoescaping reduces risk rather than eliminating it, and because the escaping model is specific enough that a security review should read how it decides what is safe in each position. ## Support is the headline caveat, not a footnote The support and project status section is the most important paragraph in the README, and any evaluation should start there. Closure Templates is widely used and well maintained internally at Google, but it does not currently have staffing to support the open source release, and the project is therefore mostly a code dump with support described as minimal. For certain issues, like build integration, the maintainers say they are in an especially bad position to offer support. That last clause is the practical one. A templating system is only as good as its integration with your build, and this is the area where the project has explicitly said it will not be able to help you. The support channels offered are the documentation directory in the repository, a closure-templates-discuss mailing list on Google Groups, and filing a bug on GitHub, with the honest caveat that given the support staffing they may not be able to help. The repository is not archived and the last push was on 2026-10-20, so the code is being worked on, but there are no GitHub releases, so you are tracking a branch rather than consuming versions. ## Getting the artifacts and reading the documentation There are two places to get the library and one to read. The release artifacts are on GitHub and on Maven Central, where the artifact is com.google.template:soy, which is the coordinate to use if you are pulling it into a Java build. The documentation lives in the documentation/ directory of the repository, and the getting started section tells you to read it. The repository tree is worth mapping before you start, because it is a multi-language project. There are java/ and javascript/ directories for the two implementations, a python/ directory, a src/ directory, a builddefs/ directory with the build rules, a documentation/ directory, an examples/ directory, a g3doc/ directory, and the Bazel files at the top level including BUILD.bazel, MODULE.bazel, a .bazelversion file and a .bazelci/ directory. The presence of Bazel as the primary build system and a Maven pom.xml and maven_install.json alongside it means the build integration question is not academic, since the project tells you it cannot support that area well. ## The examples show the component and message model in practice The examples directory is small and targeted, and it is where the design becomes concrete. There is a simple.soy, a features.soy, and three delegate examples, delegates0.soy, delegates1.soy and delegates2.soy, which is the mechanism for the claim that templates are simply functions that can call each other. The rest of the examples are translation files rather than templates, with examples_extracted.xlf, examples_translated_en.xlf and examples_translated_x-zz.xlf, which is the XLIFF format and shows both the extracted source messages and a translated variant. That set of three files demonstrates the message support in a way that is easier to grasp than prose, because the extracted file is what the tooling produces from the inline messages in the templates and the translated files are the same messages with content substituted, including a pseudo-locale with a x-zz prefix, which is a common convention for checking that a layout survives a text expansion. The examples README is in the directory as well, and the practical takeaway is that a project adopting this system should expect to work in XLIFF for its translation pipeline. ## Build integrations exist for the common toolchains The README lists the integrations available for getting started with other open source frameworks, and the list is a good map of the ecosystem it fits into. For Node.js there is soynode from Medium, and for Gulp there are gulp-soynode and gulp-soy. For Grunt there is grunt-closure-soy and grunt-soy. For NPM there is the google-closure-templates package, and for Maven the com.google.template:soy artifact. For Yeoman there is a generator called generator-closure-stack, and for Bazel there is the rules_closure repository with its closure_js_template_library rule. The distribution across build tools is the point. Closure Templates predates most of the modern JavaScript toolchain, and the fact that there are maintained integrations for Gulp, Grunt, NPM, Maven, Yeoman and Bazel means a project is not forced to invent its own. The caveat from the support section applies to all of them, though: the project cannot help you when the integration itself is the problem. ## Conclusion Adopt Closure Templates when a large JavaScript and Java codebase wants one set of component templates shared across both sides, with autoescaping and localisation built in rather than bolted on. Do not adopt it expecting an actively supported open source project, because the README describes the release as mostly a code dump with minimal support, and do not adopt it if you need a build integration you can get help with, since the project says it is in an especially bad position there. Verify first that the build tooling you use has a maintained integration, that your security team accepts its escaping model, and that the messaging approach fits how your product does translation. ## FAQ ### What is Closure Templates and what problem does it solve? It is a client and server side templating system for building reusable HTML and UI elements, with a simple syntax natural for programmers. Rather than one monolithic template per page, you write small components that you compose to form the user interface, and the same templates can be used from Java and JavaScript. ### Is Closure Templates still supported as an open source project? Minimally. The README says it is widely used and well maintained internally at Google but does not currently have staffing to support the open source release, so the project is mostly a code dump with minimal support, and for issues like build integration the maintainers say they are in an especially bad position to help. ### How do I get Closure Templates and its documentation? The latest release is on GitHub and on Maven Central under the com.google.template:soy artifact, and the documentation is in the documentation/ directory of the repository. The tree also has java/ and javascript/ directories for the two implementations, a python/ directory, Bazel files at the top level and an examples/ directory. ### Does Closure Templates protect against XSS? It autoescapes contextually to reduce the risk of XSS. Because the escaping decisions depend on where a value appears in the template, a security review should look at how it decides what is safe in each position rather than assuming the whole output is escaped the same way. ## Sources - [google/closure-templates on GitHub](https://github.com/google/closure-templates) - [Issues](https://github.com/google/closure-templates/issues) - [License: Apache-2.0](https://github.com/google/closure-templates/blob/master/LICENSE) - [README](https://github.com/google/closure-templates/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/google-closure-templates