First of all, thank you for attention!
I'd like to present you HTML render engine concept, that brings frontend-like components experience to the server side with native html/template on steroids. Supports any serving basis (nethttp/Gin/etc), that provides io.Writer for response.

Please, keep in mind that it's work-in-progress, but already used inBrokerOne for some parts of our frontend and already shows good prospects.

Why?

I'm trying to minimize usage of popular SPA/PWA frameworks where it's not needed at all because it adds a lot of complexity and overhead. Nowadays JS ecosystem is overcomplicated and huge. I don't want to separately implement API, API communication layer, bring large runtime, state management engine, VirtualDOM and webpack into project with minimal dynamic frontend behavior.
This project proves posibility to keep most of the logic on the server side.

What problems it solves? Why not plain GoKit?

While developing website's frontend with Go I realised some downsides of such approach:

• With plain html/template your're starting to repeat yourself. It's harder to define reusable parts
• You must to 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 combined.

This engine tries to bring components and async experience to the traditional server side rendering.

Features

• Component approach in mix withhtml/template
• Asynchronous operations
• Component methods, that can be called from client side (Server Side Actions, SSA)
• Different types of components communication (parent, cross)