Most evaluations of Cascade CMS focus on the editor experience, which is reasonable because content teams use the platform every day. The developer-facing surface is where most of the long-running architectural decisions actually live, though, and it is the part that determines how much custom work an institution commits to over the life of the platform.
This post describes the parts of Cascade that developers care about, written for IT teams evaluating the platform alongside Drupal or WordPress.
Templating: Velocity and XSLT
Cascade's two templating languages are Apache Velocity and XSLT, and they can coexist on the same page. XSLT is well suited to structured content transformations because Cascade represents content internally as XML. Velocity is more procedural and is the language most developers default to for layout work.
The practical implication is that templating in Cascade is closer to a programming language than to a theme system. This is heavier than working with a Drupal theme or a WordPress page builder, and it pays off in environments that need strict separation of content structure from presentation, with template changes that hold up under thousands of inheriting pages.
Server-Side Language Independence
Cascade publishes static files. The production web server can run anything: PHP, Node, .NET, ColdFusion, plain Apache or NGINX serving HTML. This is the architectural difference that makes Cascade compatible with a wide range of Cascade Website Hosting configurations. Institutions are not locked into a runtime by their CMS choice.
For developers, this means application-layer features (form processing, search, dynamic widgets) are built independently of Cascade. The CMS publishes the page; the application layer adds the dynamics. The two systems integrate through APIs, embedded scripts, or server-side includes.
Web Services API
Cascade exposes a SOAP and REST Web Services API that covers asset CRUD, publishing, user and group management, and most administrative actions. This is what allows institutions to script bulk content imports, integrate Cascade with marketing automation platforms, build custom editorial dashboards, and automate publish events from external triggers.
In practice, the API is how Cascade integrates with the rest of the campus stack. We use it routinely to build deployment automation, content migration scripts, and integrations with course catalog and faculty directory systems.
Built-in Code Editor
The Advanced Code Editor inside Cascade supports syntax highlighting, code folding, snippets, and auto-formatting for Velocity, XSLT, HTML, CSS, and JavaScript. Most template work can happen entirely inside Cascade.
For larger teams, we still recommend pairing Cascade with an external code repository through the API or through Cascade's Git integration, because version control discipline does not survive being optional.
Starter Sites and Site Copy
Cascade ships with downloadable starter sites for common higher education patterns: news, faculty directories, course catalogs, social mashups, emergency notifications. These are not finished products, but they are useful as scaffolding that accelerates new builds without committing to a templating approach the institution will later regret.
The Site Copy feature lets developers clone an entire Cascade site (assets, configuration, templates, workflows) in a few clicks. This is how staging environments and project clones get spun up in practice.
Content Form Builder
The Content Form Builder is the drag-and-drop tool for defining structured content types in Cascade. Developers use it to build the data models that non-technical editors then fill in. A well-designed content model is the difference between an institution that scales smoothly across departments and one that ends up with inconsistent freeform pages everywhere.
This is where developer time pays the highest dividends. Spend time on content models early. Editors will live with that work for years.
Performance Visibility
Cascade exposes per-region rendering metrics on every page, which surface slow templates, expensive transformations, and unbounded queries. This is useful for institutions running Cascade at scale, where a single slow region in a high-traffic template can compound across thousands of pages on every full publish.
Rendering metrics are independent of production website performance. Production performance is a function of Cascade Website Hosting infrastructure (CDN, web server, caching), which is operated separately from the CMS.
Frequently Asked Questions
Do Cascade developers need to know XSLT?
XSLT is helpful but not strictly required. Most teams default to Velocity for layout work and use XSLT only for structured content transformations. A working knowledge of both is the comfortable baseline for a senior Cascade developer.
Can Cascade integrate with a Git workflow?
Yes. Cascade includes a Git integration for templates and code assets, and the Web Services API lets teams build custom CI patterns. Most institutions running Cascade at scale have version control wired in.
What language does the production website have to be in?
Anything. Cascade publishes static files, and the production web server can run any stack. The most common configurations we see in higher education are static sites served from S3 + CloudFront, or PHP on EC2 for institutions with form-handling and dynamic widgets.
Is Cascade harder for developers than WordPress or Drupal?
Different, not harder. Cascade requires templating discipline that WordPress and Drupal do not enforce. Once a content model is in place, day-to-day Cascade development is straightforward. The cost is up front, in the architecture phase.