https://ssceng.codes

Documentation Contact
SSC Engine
 
Documentation Contact
SSC Engine
Develop frontend Server Side Components with Go
Try now!

Functional

Component approach, async operations, component server side methods
and more

Customizable

Feel free to use context feature, define own handlers with context
setters

Pure Design

You're free to use any framework as base for your web project, net/
http is not a requirement

Our sponsors
sponsor

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
[demo]

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
[code]

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

    Main motivation is to reduce 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

Dry numbers

63 +

stars

3 +

contributors

2 +

projects

1 +

sponsors

Try now!

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