https://kyoto.codes Documentation Contact kyoto Documentation Contact Mind Blowing Way to Build Frontend Keep your Go stack united with the Server Side Components go get github.com/yuriizinets/kyoto Get started ! In early development, don't use in production! Functional Components based approach, async operations, component based server side methods and more Customizable 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. Check Cons & Pros content-image 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. Check Documentation content-image Our Sponsors sponsor core features A Better Way to Build Your Frontend html/template 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! Context Use page-level context without worring 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 About Motivation 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. Zen 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 [statistics] Dry numbers 170 + Stars 12 + Forks 3 + Contributors 1 + Sponsors Check GitHub Frequently-asked questions We already have ongoing projects. Should we rewrite everything? No! Just simply define handlers, and use this 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 Documentation Contact (c) 2021-present. Created by Yurii Zinets