Each project keeps one job.

No GoConga package imports StrideJS as a required runtime dependency. No StrideJS application needs GoConga on the server.

Stride directives pass through normal GoConga templates.

<section id="campaign-editor" s-cloak>
    <input s-model="campaign.name">
    <button s-click="save">Save</button>
</section>

GoConga treats the s-* attributes as ordinary HTML attributes. Server-side template rendering does not need to understand or rewrite them.

Browser behavior remains in a separate JavaScript file.

import Stride from 'https://cdn.stridejs.com/v1/stride.min.js';

Stride.create('#campaign-editor', {
    state: {
        campaign: { name: '' }
    },
    methods: {
        async save() {
            // browser-side behavior stays here
        }
    }
});

This keeps server code free of DOM behavior and keeps markup free of embedded application JavaScript.

Server state can be exposed without executable inline code.

GoConga's jsonState helper renders bounded, HTML-safe JSON into a non-executable application/json block. StrideJS or any other browser code can read and parse that state without embedding executable JavaScript in the template.

{{jsonState "campaign-state" .Campaign}}

Fragment rendering avoids unnecessary JSON APIs.

A Go handler can render a named HTML fragment from the same view used for the full page. StrideJS can request that fragment through its fetch pipeline and replace only the relevant browser content.

The fragment feature remains general-purpose. Vanilla fetch, HTMX, or another client can consume the exact same response.

Integration does not blur the security boundary.

Authorization stays on the Go server. Browser directives are presentation and interaction helpers, not permission checks. GoConga preserves contextual escaping and can expose CSP/nonces and integrity metadata without giving browser code authority over protected server operations.