SSR-first Frontend Library

Keep your Go stack united with the Server Side Components

Get started
In early development, don't use in production!


Components based approach, async operations, component based server side methods and more


Easy to use context feature, define your own handlers with the context setters

Use with Anything

Use any framework as a base for your web project, net/http is not a requirement

Best Of Two Worlds
Server Templates
  • SSR-friendly
  • Complete control
  • Simplicity
  • Speed
JS Frameworks
  • Developer friendly
  • Component-based approach
  • Rich functionality
  • Dynamic behavior

SSR-first, fast, reliable

An HTML render engine concept that brings frontend-like components experience to the server side with native html/template on steroids. Ideal fit for SEO strict projects. Fast, on-demand HTML, minimal JS payload.


Developer friendly

This library was created to solve developer problems first. Use full power of Go, build your parallel development process around components system, deliver your webpages fast! Feel free to use landing page of this library as starter project.


core features

A Better Way to Build Your Frontend


No custom template engines, just use built-in one!

Asynchronous operations

Hassle-free asynchronous methods. It's enough to define a method, that's all!


Use page-level context without worrying about concurrency and mutex

Server Side Actions

Use server defined component methods, instead of including logic in JS payload

Cross-component communication

Trigger actions, defined in different components



The main motivation is to reduce the usage of popular SPA/PWA frameworks where it's not needed because it adds a lot of complexity and overhead. There is no reason to bring significant runtime, VirtualDOM, and Webpack into the project with minimal dynamic frontend behavior. This project proves the possibility of keeping most of the logic on the server's side.

What problems does it solve?

While developing the website's frontend with traditional Go handlers and templates, I discovered some of the downsides of this approach:

  • With plain html/template you're starting to repeat yourself. It's harder to define reusable parts.
  • You must repeat DTO calls for each page, where you're using reusable parts.
  • With Go's routines approach it's hard to make async-like DTO calls in the handlers.
  • For dynamic things, you still need to use JS and client-side DOM modification.
Complexity is much higher when all of them get combined. This engine tries to bring components and async experience to the traditional server-side rendering.


For contributors:

  • Don't replace Go features that exist already
  • Don't do work that's already done
  • Don't force developers to use a specific solution (Gin/Chi/GORM/sqlx/etc). Let them choose
  • Rely on the server to do the rendering, minimum JS specifics, or client-side only behavior
  • KISS



  • I'm not going to compare languages pros & cons, just purpose and ideology
  • Also, I'm not going to take into account existing codebases

Laravel Livewire

Laravel is awesome on my opinion and livewire makes it even more awesome! Nice choise for people who want to have "battries included" framework. Kyoto is not a framework, it's just a small library and tries to solve another kind of problem - components and asynchronous operations organization. Features like context, Server Side Actions, Server Side State, Insights, are just extensions to Core library purpose. Also, Kyoto not delivered with batteries "included", it gives more control to developer.

Differences (Kyoto vs Livewire):

  • Minimalistic over "batteries included"
  • Another approach regarding client-server communication
  • Another purpose

Elixir Phoenix

To be honest, I'm far away from Elixir and Erlang ecosystem generally. If you have some time to tell me more about Phoenix, I'll be very grateful!

Differences (Kyoto vs Phoenix):

  • Need more details

JavaScript Frameworks

The most delicious piece of cake. Please, check "Motivation" part. I'd like to notice, that Kyoto not tries to replace popular PWA/SPA approach, but to reduce it usage where it's not needed. If any of JS Frameworks works for you, so, why not?

Differences (Kyoto vs JS Frameworks):

  • Give more control to developer
  • Reduce amount of dependencies
  • Make SSR and debugging easier

Any other?

Just create an issue or contact with email if you'll find something interseting!

Dry numbers

213 +


14 +


3 +


1 +


Our Sponsors

Frequently-asked questions

We already have ongoing projects. Should we rewrite everything?

No! You can easily integrate library for creating new pages.

Is this library ready for production?

No, we don't recommend to use it in production (even if we are using so).

Seems like SSA feature is slow, is it a bug?

No, you need to check documentation first to explore cons & pros of SSA. Use SSA carefully