⚙️ Concept of Golang HTML render engine with frontend components and dynamic behavior

Overview

An 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 in response.

Disclaimer 1

Under heavy development, not stable (!!!)

Disclaimer 2

I'm not Golang "rockstar", and code may be not so good quality as you may expect. If you see any problems in the project - feel free to open new Issue.

TOC

Why?

I am trying to minimize the usage of popular SPA/PWA frameworks where it's not needed because it adds a lot of complexity and overhead. I don't want 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? Why not using plain GoKit?

While developing the website's frontend with Go, 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

  • 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, no JS specifics or client-side only behavior

Features

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

Quick start (simple page)

Basic page (based on Gin)

package main

import(
    "html/template"

    "github.com/gin-gonic/gin"
    "github.com/yuriizinets/go-ssc"
)

// PageIndex is an implementation of ssc.Page interface
type PageIndex struct{}

// Template is a required page method. It tells about template configuration
func (*PageIndex) Template() *template.Template {
    // Template body is located in index.html
    // <html>
    //   <body>The most basic example</body>
    // </html>
    tmpl, _ := template.New("index.html").ParseGlob("*.html")
    return tmpl
}

func main() {
    g := gin.Default()

    g.GET("/", func(c *gin.Context) {
        ssc.RenderPage(c.Writer, &PageIndex{})
    })

    g.Run("localhost:25025")
}

Basic concepts

Each page or component is represented by its own structure. For implementing specific functionality, you can use structure's methods with a predefined declaration (f.e. Init(p ssc.Page)). You need to follow declaration rules to match the interfaces required (you can find all interfaces in types.go).
Before implementing any method, you need to understand the rendering lifecycle.

Lifecycle

Each page's lifecycle is hidden under the render function and follows this steps:

  • Defining shared variables (waitgroup, errors channel)
  • Triggering the page's Init() to initialize and register components
  • Running all component's Async() functions in separate goroutines
  • Waiting untill all asynchronous operations are completed
  • Calling AfterAsync() for each component
  • Cleaning up registered components (not needed more for internal usage)
  • Getting page's template and render

Even though methods like Init() or Async() can handle your business logic like forms processing, please, try to avoid that. Keep your app's business logic inside tje handlers, and use this library only for page rendering.

Pages

To implement a page, you need to declare its structure with Template() *template.Template method. This is the only requirements. Also, each page has these optional methods:

  • Init() - used to initialize page, f.e. components registering or providing default values
  • Meta() ssc.Meta - used to provide advanced page meta, like title, description, hreflangs, etc.

Example of page

Reference page is here. Check demo for full review.

package main

import (
    "html/template"

    "github.com/yuriizinets/go-ssc"
)

type PageIndex struct {
    ComponentHttpbinUUID   ssc.Component
}

func (*PageIndex) Template() *template.Template {
    return template.Must(template.New("page.index.html").Funcs(funcmap()).ParseGlob("*.html"))
}

func (p *PageIndex) Init() {
    p.ComponentHttpbinUUID = ssc.RegC(p, &ComponentHttpbinUUID{})
}

func (*PageIndex) Meta() ssc.Meta {
    return ssc.Meta{
        Title: "SSC Example",
    }
}
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    {{ meta . }}
    {{ dynamics }}
    <link href="https://unpkg.com/tailwindcss@^2/dist/tailwind.min.css" rel="stylesheet">
</head>
<body>
    <h1 class="mt-4 text-5xl text-center">Go SSC Demo Page</h1>
    <div class="pt-16"></div>
    <h2 class="text-3xl text-center">Httpbin UUID</h2>
    <p class="text-center">UUID, fetched on the server side, asynchronously, from httpbin.org</p>
    <div class="mt-2 text-center">
        {{ template "ComponentHttpbinUUID" .ComponentHttpbinUUID }}
    </div>
</body>
</html>

Components

To implement a component, you just need to declare its structure. There are no requirements for declaring a component. Also, each component has these optional methods:

  • Init(p ssc.Page) - used to initialize component, f.e. nested components registering or providing default values
  • Async() error - method is called asynchronously with goroutines and processed concurrently during lifecycle. You can use it for fetching information from DB or API
  • AfterAsync() - method is called after all finishing all async operations
  • Actions() ActionsMap - used for providing SSA. Check Server Side Actions for details

Component example

Reference component is here. Check demo for full review.

Example of a component that fetches and displays UUID response from httpbin.org

package main

import (
    "io/ioutil"
    "net/http"

    "github.com/yuriizinets/go-ssc"
)

type ComponentHttpbinUUID struct {
    UUID string
}

// Async method is handled by library under the hood
// Each async method is called asynchronously with goroutines and processed concurrently
func (c *ComponentHttpbinUUID) Async() error {
    resp, err := http.Get("http://httpbin.org/uuid")
    if err != nil {
        return err
    }
    defer resp.Body.Close()
    data, err := ioutil.ReadAll(resp.Body)
    if err != nil {
        return err
    }
    c.UUID = string(data)
    return nil
}

For component usage you can check example of page.

Server Side Actions

Server Side Actions (SSA) - a way to execute logic on the server side and update component's DOM. You don't need to define any custom JS to update and redraw your component, your template will be reused for this. This feature works with thin JS layer, so, you'll need to include {{ dynamics }} row in your page. Also, you'll need to register endpoint handler (ssc.SSAHandler) with prefix /SSA/ for Actions to work. As an example for built-in net/http, you need to attach handler in that way mux.HandleFunc("/SSA/", ssc.SSAHandler)

SSA Example

Reference component is here. Check demo for full review.

Example of Action

package main

import "github.com/yuriizinets/go-ssc"

type ComponentCounter struct {
    Count int
}

func (c *ComponentCounter) Actions() ssc.ActionsMap {
    return ssc.ActionsMap{
        "Increment": func(args ...interface{}) {
            c.Count++
        },
    }
}
{{ define "ComponentCounter" }}
<div {{ componentattrs . }} class="border shadow rounded p-4">
    <div class="text-2xl font-semibold">Counter Demo</div>
    <div class="py-2 w-full flex flex-col items-center">
        <div class="text-2xl">{{ .Count }}</div>
        <button onclick="{{ action `Increment` }}" class="mt-2 bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded w-32">Increment</button>
    </div>
</div>
{{ end }}
Comments
  • Prototype: Multi-stage component UI update on Action

    Prototype: Multi-stage component UI update on Action

    Explore possibility to use server-sent events to deliver multiple UI updates.
    Logic must to be similar to "flush" functionality of ORM frameworks, something like kyoto.SSAFlush(p)

    Required knowledge:

    • SSE API (https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events)
    • SSA lifecycle theory and code (https://kyoto.codes/extended-features.html#ssa-lifecycle and https://github.com/yuriizinets/kyoto/blob/master/ext.ssa.go)
    • SSA communication layer code (https://github.com/yuriizinets/kyoto/blob/master/payload/src/dynamics.ts)

    Issue might be pretty hard to implement for people unfamiliar with project, but very interesting for those who want to explore project codebase.

    enhancement 
    opened by yuriizinets 20
  • Prototype of functional way to define pages/components

    Prototype of functional way to define pages/components

    Current working prototype looks like this:

    ...
    
    func PageIndex(b *kyoto.Builder) {
    	b.Template(func() *template.Template {
    		return template.Must(template.New("page.index.html").ParseGlob("*.html"))
    	})
    	b.Init(func() {
    		b.State.Set("Title", "Kyoto in a functional way")
    		b.Component("UUID1", ComponentUUID)
    		b.Component("UUID2", ComponentUUID)
    	})
    }
    
    func ComponentUUID(b *kyoto.Builder) {
    	b.Async(func() error {
    		// Execute request
    		resp, err := http.Get("http://httpbin.org/uuid")
    		if err != nil {
    			return err
    		}
    		// Defer closing of response body
    		defer resp.Body.Close()
    		// Decode response
    		data := map[string]string{}
    		json.NewDecoder(resp.Body).Decode(&data)
    		// Set state
    		b.State.Set("UUID", data["uuid"])
    		// Return
    		return nil
    	})
    }
    
    enhancement 
    opened by yuriizinets 7
  • Component actions not being executed

    Component actions not being executed

    I have an action which I've defined on a component. The component code looks like this:

    package components
    
    import (
    	"log"
    	"net/http"
    
    	"github.com/gin-gonic/gin"
    	"github.com/yuriizinets/go-ssc"
    
    	"github.com/kodah/blog/controller"
    	"github.com/kodah/blog/service"
    )
    
    type SignIn struct {
    	Context  *gin.Context
    	Username string
    	Password string
    	Errors   []string
    }
    
    func (c *SignIn) Actions() ssc.ActionsMap {
    	return ssc.ActionsMap{
    		"DoSignIn": func(args ...interface{}) {
    			var configService service.ConfigService = service.ConfigurationService("")
    			if configService.Error() != nil {
    				log.Printf("Error while connecting to DB service. error=%s", configService.Error())
    				c.Errors = append(c.Errors, "Internal server error")
    
    				return
    			}
    
    			log.Printf("Triggered sign in")
    
    			var dbService service.DBService = service.SQLiteDBService("")
    			if dbService.Error() != nil {
    				log.Printf("Error while connecting to DB service. error=%s", dbService.Error())
    				c.Errors = append(c.Errors, "Internal server error")
    
    				return
    			}
    
    			var loginService service.LoginService = service.DynamicLoginService(dbService)
    			var jwtService service.JWTService = service.JWTAuthService()
    			var loginController controller.LoginController = controller.LoginHandler(loginService, jwtService)
    
    			c.Context.Set("Username", c.Username)
    			c.Context.Set("Password", c.Password)
    
    			session := service.NewSessionService(c.Context, false)
    			token := loginController.Login(c.Context)
    
    			session.Set("token", token)
    
    			err := session.Save()
    			if err != nil {
    				log.Printf("Error while saving session. error=%s", err)
    			}
    
    			log.Printf("Login successful. user=%s", c.Username)
    
    			c.Context.Redirect(http.StatusFound, "/")
    		},
    	}
    }
    

    The template:

    {{ define "SignIn" }}
    <div {{ componentattrs . }}>
        <h1 class="title is-4">Sign in</h1>
        <p id="errorFeedback" class="help has-text-danger is-hidden">
            {{ .Username }} {{ .Password }}
        </p>
        <div class="field">
            <div class="control">
                <input class="input is-medium" value="{{ .Username }}" oninput="{{ bind `Username` }}" type="text" placeholder="username">
            </div>
        </div>
    
        <div class="field">
            <div class="control">
                <input class="input is-medium" value="{{ .Password }}" oninput="{{ bind `Password` }}" type="password" placeholder="password">
            </div>
        </div>
        <button onclick="{{ action `DoSignIn` `{}` }}" class="button is-block is-primary is-fullwidth is-medium">Submit</button>
        <br />
        <small><em>Be nice to the auth system.</em></small>
    </div>
    {{ end }}
    

    and is included like this:

                    <div class="column sign-in has-text-centered">
                        {{ template "SignIn" .SignInComponent }}
                    </div>
    

    Where the component inclusion looks like this:

    package frontend
    
    import (
    	"html/template"
    
    	"github.com/gin-gonic/gin"
    	"github.com/yuriizinets/go-ssc"
    
    	"github.com/kodah/blog/frontend/components"
    )
    
    type PageSignIn struct {
    	ctx             *gin.Context
    	SignInComponent ssc.Component
    }
    
    func (p *PageSignIn) Template() *template.Template {
    	return template.Must(template.New("page.signin.html").Funcs(ssc.Funcs()).ParseGlob("frontend/new_templates/*/*.html"))
    }
    
    func (p *PageSignIn) Init() {
    	p.SignInComponent = ssc.RegC(p, &components.SignIn{
    		Context: p.ctx,
    	})
    
    	return
    }
    
    func (*PageSignIn) Meta() ssc.Meta {
    	return ssc.Meta{
    		Title:       "Test kodah's blog",
    		Description: "Test description",
    		Canonical:   "",
    		Hreflangs:   nil,
    		Additional:  nil,
    	}
    }
    

    When I run the DoSignIn action it is not executed though;

        <button onclick="{{ action `DoSignIn` `{}` }}" class="button is-block is-primary is-fullwidth is-medium">Submit</button>
    

    I realize there's not a lot of documentation but I went off of the examples and this seems right.

    question 
    opened by kodah 7
  • Using ParseFS and embed.FS

    Using ParseFS and embed.FS

    I've been trying to figure out a pattern to use embed.FS and template.ParseFS for delivering the HTML files

    Do you have any examples for this? I've been struggling with a couple of different errors and including the Funcs with the parsed templates

    template: \"templates/pages.home.html\" is an incomplete or empty template

    	//go:embed templates
    	Templates embed.FS
    
    	return template.Must(
    		template.New("templates/pages.home.html").Funcs(kyoto.TFuncMap()).ParseFS(assets.Templates, "templates/pages.home.html"),
    	)
    
    question 
    opened by aranw 6
  • Up-to-date on Using the UIKit

    Up-to-date on Using the UIKit

    Hi guys,

    First of all, just wanted to take a moment and express my gratitude to your guys for making Kyoto a reality. It's awesome and really makes a lot sense for gophers to build out frontends on the fly. That said, I was wondering if you guys had any updated docs on using the UIKit. So far all the docs and demo projects I've come across were on an older version of the codebase and the apis have changed quite a bit since then. Would love some guidance here. Thanks in advance.

    Best, Jay

    opened by jim380 3
  • It is not possible to use `render.Custom` per component

    It is not possible to use `render.Custom` per component

    Each render.Custom call overrides global context. With this approach it wouldn't be possible to define custom rendering on a component level.
    As an option, we can store this in the state as internal, helpers.ComponentSerialize will remove it on state serialization.

    bug good first issue 
    opened by yuriizinets 3
  • Better Actions protocol implementation

    Better Actions protocol implementation

    Current approach is far from ideal. State and arguments are passed in SSE query, response must to be base64 encoded to avoid newlines issue (which increases the size of the response).

    Websockets cannot be considered:

    • They don't scale well (in case of keeping connection alive all the time)
    • Sometimes it requires special configuration of networking, especially on big projects
    • In some countries/hotels/public places you can see ports/protocols whitelisting, which immediately kills this approach
    enhancement good first issue 
    opened by yuriizinets 3
  • Support `tinygo` compiler

    Support `tinygo` compiler

    tinygo may provide a lot of benefits to the project, like compiling to smaller wasm payload and using in places where payload size is critical. I also consider as an option using kyoto for creating frontend, rendered on the Edge Network (f.e. Cloudflare Workers). Workers have a lot of limitations and tinygo may satisfy them.

    enhancement hardcore 
    opened by yuriizinets 3
  • Passing Go packages to Pages/Components

    Passing Go packages to Pages/Components

    Been playing around with Kyoto and really liking the pattern once I managed to get my head around it

    But now I'm starting to wonder what are the best practices for passing Go packages to Pages/Components seen as the handlers create a new instance of the page on each page load it's not possible to pass in a dependency inside the Page/Component structs

    One way I've managed to do this is passing it into the Context but I don't really want to fill up my context with lots of dependencies but I feel like there must be a nicer way of doing this that is more scalable?

    question 
    opened by aranw 3
  • Question - set cookie on response to SSA call

    Question - set cookie on response to SSA call

    How is it possible to access the request context from a call to a Server-Side Action. Say, for instance you want to set a cookie in the response to an SSA call.

    In the example demo app for the form submission example (email validator) you have the following:

    type ComponentDemoEmailValidator struct {
    	Email   string
    	Message string
    	Color   string
    }
    
    func (c *ComponentDemoEmailValidator) Actions() ssc.ActionMap {
    	return ssc.ActionMap{
    		"Submit": func(args ...interface{}) {
    			if emailregex.MatchString(c.Email) {
    				c.Message = "Provided email is valid"
    				c.Color = "green"
    			} else {
    				c.Message = "Provided email is not valid"
    				c.Color = "red"
    			}
    		},
    	}
    }
    

    I am aware you can create an "Init" method function to access the request context i.e.

    func (c *ComponentDemoEmailValidator) Init(p ssc.Page) {
        c.Page = p
        r := ssc.GetContext(p, "internal:r").(*http.Request)
        rw := ssc.GetContext(p, "internal:rw").(http.ResponseWriter)
    }
    

    But how do you access the request/response context from within the "Actions()" method so that you can, for example, set a cookie in the response. Is this possible?

    question 
    opened by c-nv-s 3
  • Interaction with complex state across different adapters is uncomfortable

    Interaction with complex state across different adapters is uncomfortable

    In the struct mode it's much easier to initialize nested components and interact with them in next lifecycle steps. In case of func mode (which is default now) we need to interact with kyoto.Store instance, which is OK for simple state, but interaction with nested components is awful. You need to understand how Core.Component works and use explicit type casting.

    Needs to figure out, how to simplify work with components.

    architecture 
    opened by yuriizinets 2
Releases(v1.0.2)
  • v1.0.2(Jun 28, 2022)

  • v1.0.1(Jun 27, 2022)

  • v1.0.0(Jun 26, 2022)

    A first major release of kyoto, v1.0.0. We went through a huge architecture changes multiple times and took some hard decisions in development process. Please note, it’s a breaking release. It’s not similar to anything published in 0.x versions.

    Key concept of the new architecture comparing to struct based components - asynchronous functions as a component, based on generics and zen.Future. As far as overall concept is not documented yet, I’d recommend checking code sources for now. It’s well documented and structured.

    There is no sense to provide a change list because everything was changed drastically, so I’d like to recommend checking our documentation on https://pkg.go.dev/github.com/kyoto-framework/kyoto. 

As a part of our optimizations, we are moving our documentation directly into the code. Documentation will be automatically generated by pkg.go.dev, which would significantly ease the overall development process.

    I have to apologize for drastically changing architecture right before 1.0. This decision should have been made before the release because stable version imposes many restrictions on such movements. Sticking with not-so-good approach for compatibility with 0.x (which did not promise to stay stable anyway) is quite a bad idea. Work on minor libraries refactor, like uikit, will start right from this moment.

    If you find yourself in a bad situation because of these changes, please, let me know. I can help with adapting to this change, as our team will be doing the same. You can find contacts right in the README.

    Source code(tar.gz)
    Source code(zip)
  • v0.3.2(May 4, 2022)

  • v0.3.1(May 4, 2022)

  • v0.3.0(Apr 14, 2022)

    This is the last release before 1.0 will be released. It was created as a transfer point between old and new architecture. Complete notes about changes will be posted with 1.0 release.

    Source code(tar.gz)
    Source code(zip)
  • v0.2.0(Dec 25, 2021)

    I am pleased to present a second release of this library! We are moving slowly, but every step is quite important. It proves this "concept" is no longer just a concept. Let's take a closer look at the changes this release brings!

    Features

    • Multi-stage UI update on action (related issue https://github.com/kyoto-framework/kyoto/issues/62). Awesome feature, proposed by @bketelsen that allows to push multiple UI updates during single action call. Useful thing to show current status/step of a long-running action. Documentation.
    • ssa:oncall.display control attribute (related issue https://github.com/kyoto-framework/kyoto/issues/56). Changes display parameter during action call, at the end of an action the layout will be restored. Documentation
    • ssa:onload trigger attribute (related issue https://github.com/kyoto-framework/kyoto/issues/63). Provides a way to trigger an action on page load. This may be useful for components' lazy loading. Documentation
    • ssa:poll + ssa:poll.interval trigger attributes (related issue https://github.com/kyoto-framework/kyoto/issues/18). Provides a way to trigger an action periodically. Useful for components that have to be updated over time (f.e. charts, stats, etc.). Documentation
    • ssa:onintersect trigger attribute (related issue https://github.com/kyoto-framework/kyoto/issues/36). Provides a way to trigger an action on element intersection. Documentation
    • ssa:render.mode control attribute (related issue https://github.com/kyoto-framework/kyoto/issues/70). Determines which mode to use for dynamic DOM updating. Currently, 2 modes are supported: "morphdom" and "replace". Documentation
    • ssa.morph.ignore and ssa.morph.ignore.this control attributes (related issue #https://github.com/kyoto-framework/kyoto/issues/43). Ignore elements morphing (with or without children). Documentation is not ready yet
    • The possibility of using custom render method (related issue https://github.com/kyoto-framework/kyoto/issues/42). It's an important step to eliminate obligatory using of html/template and give more control to developers. Documentation
    • Support ndjson (newline delimited json) output format for Insights feature (related issue https://github.com/kyoto-framework/kyoto/issues/49). Documentation is not ready yet.
    • Option for changing SSA endpoint (related issue https://github.com/kyoto-framework/kyoto/issues/84). Documentation is not ready yet.
    • Option for changing async error behavior (related issue https://github.com/kyoto-framework/kyoto/issues/77). Documentation is not ready yet

    Deprecated

    Nothing in this release :) But old deprecated functions from 0.1 are cleaned up.

    Future plans

    • Video tutorials and articles. It's not enough to have a documentation as far as it's not providing step-by-step usage guide, also some people better understand information with audio/video content.
    • More attention to minor things, like UI Kit and starter project.
    • Refactor rendering lifecycle architecture (related issue https://github.com/kyoto-framework/kyoto/issues/93). Lifecycle is pretty similar to pipeline, so job execution system (https://github.com/kyoto-framework/scheduler) perfectly fits for this purpose.
    • Functional way to define pages and components (related issue https://github.com/kyoto-framework/kyoto/issues/94).
    • Server side state (related issue https://github.com/kyoto-framework/kyoto/issues/28).
    • Support tinygo compiler (related issue https://github.com/kyoto-framework/kyoto/issues/80). An important step on the road to Edge Workers.
    • Cover project with tests (related issue https://github.com/kyoto-framework/kyoto/issues/53).

    Final words

    I would like to mention and say thanks to this people:

    • @RowdyHcs for active participation in project development
    • @bketelsen for providing ssa:poll pull request, minor improvements and idea of multi-stage UI update
    • @OpenSauce for detailed documentation review for grammar mistakes
    • @inthepanchine for ndjson insights output
    • ... and other people can be found here
    Source code(tar.gz)
    Source code(zip)
  • v0.1.4(Dec 8, 2021)

  • v0.1.3(Dec 2, 2021)

  • v0.1.2(Nov 28, 2021)

  • v0.1.1(Nov 26, 2021)

  • v0.1.0(Nov 1, 2021)

    First alpha release is here!
    It was a log way from concept to actual implementation, and we are happy what we got now. Now we want to make first alpha release to fix current state and set of features before providing more changes. 0.2 version will bring some changes, some of them may be breaking, so 0.1 version is a "stable" release for people who already using this library.

    Overall status

    This table represents the current state of things in the library

    | Feature | Status | Description | |-------------------|-------------|-------------------------------------------------| | Page rendering | Stable | Server side rendering with components lifecycle | | Built-in handler | Stable | High-level page handler for net/http | | Context | Stable | Global page-level context | | SSA | Unstable | Page dynamic behavior with Server Side Actions | | Insights | Unstable | Rendering and lifecycle timings | | Meta builder | Unstable(!) | Simple way to build page meta | | Server Side State | Planned | Save state on the server side instead of client |

    Future plans

    In the 0.2 we are going to:

    • Improve contribution experience. Now, it's pretty hard to find good issues for external contributors
    • Standardize SSA attributes naming rules
    • Introduce to SSA more features like loading state
    • Get rid of obligatory using html/template, provide an ability to choose own render engine
    • Provide component interface to support Render method, where developer can define own way to render component

    Deprecated

    We changed some references during developer to be more understandable, but also we created aliases to be backward compatible. We are going to remove them in 0.2.
    Also, we found some things that we created are overcomplicated, so we created easier to use analogs. Old functions are still in the codebase, but will be removed on 0.2.

    • kyoto.Funcs - use kyoto.TFuncMap instead
    • kyoto.PageHandlerFactory - use opinionated kyoto.PageHandler or create own generic handler
    • kyoto.SSAHandlerFactory - use opinionated kyoto.SSAHandler or create own SSA handler

    Final words

    I'd like to thank all the people who supported the project with contributions, or even used the library for own projects!
    But as a gentle reminder, please, avoid using this in production for now :)

    Source code(tar.gz)
    Source code(zip)
Owner
Yurii Zinets
Software Engineer
Yurii Zinets
Material Design Components for use with Vecty in the most minimalistic fashion.

mdc Material Design Components for use with Vecty in the most minimalistic, dead simple fashion. Currently on MDC version 13.0.0. Based on the good wo

Patricio Whittingslow 2 Mar 6, 2022
Go Lang Web Assembly bindings for DOM, HTML etc

WebAPI Go Language Web Assembly bindings for DOM, HTML etc WARNING: The current API is in very early state and should be consider to be expremental. T

Go Web API 131 Dec 28, 2022
This library provides WebAssembly capability for goja Javascript engine

This module provides WebAssembly functions into goja javascript engine.

YC-L 1 Jan 10, 2022
Golang-WASM provides a simple idiomatic, and comprehensive API and bindings for working with WebAssembly for Go and JavaScript developers

A bridge and bindings for JS DOM API with Go WebAssembly. Written by Team Ortix - Hamza Ali and Chan Wen Xu. GOOS=js GOARCH=wasm go get -u github.com/

TeamOrtix 93 Dec 22, 2022
Aes for go and java; build go fo wasm and use wasm parse java response.

aes_go_wasm_java aes for go and java; build go fo wasm and use wasm parse java response. vscode setting config settings.json { "go.toolsEnvVars":

忆年 0 Dec 14, 2021
WebAssembly for Proxies (Golang host implementation)

WebAssembly for Proxies (GoLang host implementation) The GoLang implementation for proxy-wasm, enabling developer to run proxy-wasm extensions in Go.

MOSN 38 Dec 29, 2022
A WASM Filter for Envoy Proxy written in Golang

envoy-proxy-wasm-filter-golang A WASM Filter for Envoy Proxy written in Golang Build tinygo build -o optimized.wasm -scheduler=none -target=wasi ./mai

Emre Savcı 10 Nov 6, 2022
Istio wasm api demo with golang

istio-wasm-api-demo 1. Setup the latest Istio Setup k8s cluster: e.g. kind create cluster --name test Download the latest Istioctl from the GitHub rel

Takeshi Yoneda 6 Nov 1, 2022
DOM library for Go and WASM

Go DOM binding (and more) for WebAssembly This library provides a Go API for different Web APIs for WebAssembly target. It's in an active development,

Denys Smirnov 469 Dec 23, 2022
Go compiler for small places. Microcontrollers, WebAssembly, and command-line tools. Based on LLVM.

TinyGo - Go compiler for small places TinyGo is a Go compiler intended for use in small places such as microcontrollers, WebAssembly (Wasm), and comma

TinyGo 12.1k Dec 30, 2022
WebAssembly interop between Go and JS values.

vert Package vert provides WebAssembly interop between Go and JS values. Install GOOS=js GOARCH=wasm go get github.com/norunners/vert Examples Hello W

null 83 Dec 28, 2022
Fast face detection, pupil/eyes localization and facial landmark points detection library in pure Go.

Pigo is a pure Go face detection, pupil/eyes localization and facial landmark points detection library based on Pixel Intensity Comparison-based Objec

Endre Simo 3.9k Dec 24, 2022
A package to build progressive web apps with Go programming language and WebAssembly.

Go-app is a package for building progressive web apps (PWA) with the Go programming language (Golang) and WebAssembly (Wasm). Shaping a UI is done by

Maxence Charriere 6.7k Dec 30, 2022
A package to build progressive web apps with Go programming language and WebAssembly.

Go-app is a package for building progressive web apps (PWA) with the Go programming language (Golang) and WebAssembly (Wasm). Shaping a UI is done by

Maxence Charriere 6.7k Jan 2, 2023
Bed and Breakfast web app written in Go

BOOKINGS AND RESERVATIONS This repository contains the files for my RareBnB application RareBnB is an "AirBnB" style clone providing a user the abilit

null 0 Jan 11, 2022
⚙️ Concept of Golang HTML render engine with frontend components and dynamic behavior

SSC Engine An HTML render engine concept that brings frontend-like components experience to the server side with native html/template on steroids. Sup

Yurii Zinets 543 Nov 25, 2022
Composable HTML components in Golang

daz Composable HTML components in Golang Daz is a "functional" alternative to using templates, and allows for nested components/lists Also enables tem

Steve Lacy 192 Oct 3, 2022
Frongo is a Golang package to create HTML/CSS components using only the Go language.

Frongo Frongo is a Go tool to make HTML/CSS document out of Golang code. It was designed with readability and usability in mind, so HTML objects are c

Rewan_ 21 Jul 29, 2021
Seatsserver - Combined frontend and backend to serve HTML versions of seats

seatsserver Combined frontend and backend to serve HTML versions of github.com/s

Jeff Palm 0 Jan 28, 2022
The Dual-Stack Dynamic DNS client, the world's first dynamic DNS client built for IPv6.

dsddns DsDDNS is the Dual-Stack Dynamic DNS client. A dynamic DNS client keeps your DNS records in sync with the IP addresses associated with your hom

Ryan Young 15 Sep 27, 2022