Why does Wicket avoid using JSP for markup?

JSP mixes Java scriptlets, tag libraries, and HTML directly in the same file, which means a template can't be opened, previewed, or edited by a designer without a JSP-aware engine, and a page's logic ends up scattered between the JSP file and any backing controller code.

Wicket's answer is to keep HTML files as plain, valid HTML with no embedded Java at all — the only framework-specific thing in the markup is the wicket:id attribute, which browsers and design tools simply ignore as an unknown attribute. All logic lives in ordinary Java classes, fully covered by the compiler's type checking, IDE refactoring, and step-through debugging, instead of being spread across JSP expression language and scriptlet fragments that are much harder to test or refactor safely.

The trade-off is that a Wicket page requires two files (Java class and HTML) kept in sync by naming convention, rather than JSP's single file — a deliberate choice favoring separation of concerns and tooling support over file-count convenience.