Styling & Front-end Assets

Two books cover this ground, and both predate the current tools. They are useful for the ideas and for the project layouts, but do not copy their set-up.

Both books also use the local profile idea (spring.thymeleaf.cache=false only on a developer machine), which is still valid and is covered under live reload below.

For the same change on the Tailwind side, see the Tailwind upgrade guide page of the Tailwind section.

By default Spring Boot serves files from the classpath directories static, public, resources and META-INF/resources, mapped on /**, through Spring MVC’s resource handler. (In an executable web application the servlet container’s default servlet is not enabled; server.servlet.register-default-servlet turns it on as a fallback.) The three properties that change this are spring.web.resources.static-locations (replaces the list of locations), spring.mvc.static-path-pattern (the URL pattern, default /**) and spring.web.resources.add-mappings (default true; false turns the whole default mapping off). In Thymeleaf you do not write the path by hand: you use a link expression, which prepends the context path and, as the next sections show, can version the file.

Put the files under static:

Source: Spring Boot — Static Content

and link them with th:href and th:src. The plain href is the natural-template fallback: opened as a file the page still finds its stylesheet, and the server replaces it.

Rendered by a controller method that returns assets/page (Boot 4.1.1, no extra properties):

With a context path (a request made to /shelf/assets in the context /shelf), the same template rendered href="/shelf/css/site.css". That is the reason to always write @{/css/site.css} rather than a literal /css/site.css: the literal form breaks when the application is deployed under a context path, and it is never versioned (below).

Source: Using Thymeleaf — Link URLs

The link page of this section (Link URLs) covers the @{...} syntax itself.

A WebJar is a Maven artifact that packages a client-side library under META-INF/resources/webjars/<name>/<version>/. Spring Boot maps /webjars/** to those directories (the pattern can be changed with spring.mvc.webjars-path-pattern), so a library arrives as an ordinary dependency, is pinned by Maven and is served from your own origin. The WebJars site lists the coordinates, and the org.webjars.npm group mirrors npm packages.

Source: WebJars

The Spring Boot 4.1.1 BOM manages webjars-locator-lite (1.1.4 there), so no version is given for it. It does not manage the libraries themselves: give their version, which is the version of the npm package. The htmx.org WebJar is a good example of why to pin it deliberately: the newest one on Maven Central is 4.0.0, the htmx 4 line, which is not the htmx 2 API that the htmx pages of this section teach.

webjars-locator-lite lets the template leave the version out. The path /webjars/htmx.org/dist/htmx.min.js is resolved to the one WebJar that provides htmx.org, so upgrading the library is a change to pom.xml only:

Rendered on Boot 4.1.1 with the locator on the classpath, the links come out with the real version, and the version-less path is also answered when requested directly:

Without webjars-locator-lite the same template renders the path as written, and the version-less request answers 404; the scratch application showed exactly that, so a missing locator is the usual reason for a WebJar link that "worked in the IDE". Spring Boot’s own documentation describes the version-agnostic URLs and the webjars-locator-lite dependency in the same Static Content section quoted above, and the WebJars site has a Spring Boot page.

Source: WebJars — Instructions for Spring Boot

For htmx and Alpine.js as WebJars, versus a CDN with Subresource Integrity, see htmx Fundamentals and Alpine.js & Web Components. Both load their scripts from /webjars/** and mention that the security chain must permit that path.

Browsers can cache a CSS file for a year, but only if a deployment that changes the file also changes its URL. Spring’s resource chain does that by inserting a version into the URL when the template is rendered, and understanding the URL again when the browser asks for it. There are two pieces:

Turn the content strategy on for everything:

Source: Spring Boot — Static Content

The template did not change. This is what it rendered, and what the browser’s follow-up requests got:

Source: Spring Framework — Static Resources

The same run without the two cachecontrol properties answered with Cache-Control: no-cache, no-store, max-age=0, must-revalidate. That header comes from Spring Security’s default response headers when the resource handler sets none, so on an application with Spring Security the cache properties are what make the assets cacheable at all.

A JavaScript module loader that builds URLs in the browser cannot use renamed files. For those, the fixed strategy puts a version in the path instead of the file name, and the two can be combined, with the content strategy on the rest:

Source: Spring Boot — Static Content

A pitfall appears here: the fixed strategy changes the path, so /v12/js/shelf.js is answered 302 to the login page until the security chain permits /v12/** (the content strategy keeps the directory, so /css/** keeps matching). The other pitfalls: a plain href="/css/site.css" without th:href is never rewritten, and the filter only helps links that go through @{...}, because only those reach encodeURL.

Tailwind generates CSS for the utility classes it finds in your files, and nothing else. In v4 you do not tell it where the templates are with a content array; it scans the project, and @source adds or changes the places it looks. The Tailwind section covers the framework itself (see Tailwind CSS, Getting Started and Build and Production); this section covers how to wire it to a Spring Boot and Thymeleaf project. The surrounding HTML and CSS fundamentals are in the HTML & CSS section.

When the project has real JavaScript (TypeScript, Alpine components, Vue islands), Vite is the current bundler, and Tailwind has a first-party plugin for it. The build produces hashed or fixed file names, and the dev server serves the sources with hot updates. Install vite, tailwindcss and @tailwindcss/vite, and configure the output to go to static/dist:

with src/main/frontend/main.js containing import './app.css' and the same app.css as above. npm run build (vite build) printed:

Source: Tailwind CSS — Using Vite

The two entryFileNames/assetFileNames settings give stable names, so the template can link /dist/main.css and let the Spring resource chain add the content hash (on MVC). Vite’s own default is hashed names plus a manifest that a backend reads; its backend integration guide describes that route.

In development you do not build. The Spring template switches to the dev server when a property is set, and the pages then load their CSS and JavaScript from Vite with hot updates:

With app.vite.dev-server=http://localhost:5173 in a local profile (the value comes from configuration, never from the request) the page rendered the two module scripts, and without it the single built stylesheet:

The Vite dev server was started and queried: it served /src/main/frontend/main.js, regenerated the CSS with the new class after a template edit (requested with the ?t= timestamp that its client adds), and pushed {"type":"full-reload"} messages over its WebSocket when page.html changed, which is what the small plugin above sends. Vite’s default server.cors allowed the origin http://localhost:8080 (it answered Access-Control-Allow-Origin: http://localhost:8080) and sent no such header for http://evil.example, so there is no reason to set cors: true.

Two details are easy to miss. Vite’s watcher takes a directory, not a glob: server.watcher.add('src/main/resources/templates/**/*.html') matched nothing in the test, and the directory form worked. And a string literal containing /@vite in the middle of a ${...} in th:src is refused by Thymeleaf 3.1.5 with the restricted-mode message "Instantiation of new objects and access to static classes or parameters is forbidden in this context": th:src="${viteDevServer + '/@vite/client'}" failed that way, while the form above, and th:src="${viteDevServer} + '/@vite/client'", rendered correctly. The same literal in th:title was fine; see Appendix D of the tutorial for the contexts where restricted mode applies.

Source: Vite — Backend Integration

Source: Using Thymeleaf — Appendix D: Expression Restrictions

For the build side, a Vite build is run from Maven or Gradle exactly like the CLI build above, with the script vite build in package.json.

Bootstrap needs no build step to use. The quickest route is the WebJar from the section above, linked with version-less paths; the page of the Bootstrap section on getting started covers the other routes (npm, CDN) and customization covers Sass variables, which do need a build. See Bootstrap for the framework itself.

With the content strategy and the locator active, it rendered:

and both URLs answered 200 with Cache-Control: max-age=31536000, public. Choose Bootstrap or Tailwind for a given page, not both: they style the same elements with different base rules (Tailwind’s preflight resets what Bootstrap’s Reboot sets up), so a page that loads both is hard to reason about.

Source: Bootstrap — Introduction

ttcli is the "Taming Thymeleaf CLI" by the author of both books. It asks a few questions (group and artifact id, Boot version, Thymeleaf or JTE, the live reload set-up and the web dependencies) and creates a Spring Boot project in a sub-directory with the front-end already wired. According to its README it adds the npm scripts and dependencies for the chosen live reload set-up, starter index.html and layout/main.html templates, Tailwind CSS or Bootstrap when selected, the WebJars in the Maven dependencies, and an application-local.properties with template caching disabled. The live reload choices are DevTools (simplest, slowest, no npm unless Tailwind is chosen), npm-based watch scripts, and Vite. The README says to read the generated HELP.md for how to work with the choice. Version 1.13.0 was the latest release when this page was checked (2026-10-05).

Source: ttcli — README

ttcli was not run for this page: it is a downloaded binary, and the commands above are quoted from its README. Use it as a starting point and check the result. In particular, the htmx book shows generated projects with Tailwind 3 configuration, so look at which Tailwind version the generated package.json pins, and move a Tailwind 3 project to v4 with the upgrade guide rather than assuming the generator did.

The DevTools LiveReload server pushed a browser refresh when a resource changed. Spring Boot 4.1.0 deprecated it "with no replacement". The 4.1.1 metadata confirms it: spring.devtools.livereload.enabled (default false) and spring.devtools.livereload.port (default 35729) are both marked deprecated since 4.1.0. The rest of DevTools is not deprecated: automatic restart and the development-time property defaults, which include spring.thymeleaf.cache=false, remain. What you lose is the automatic browser refresh, and the options below replace it or make it unnecessary.