-
kyoto
Discontinued Golang SSR-first Frontend Library [Moved to: https://github.com/kyoto-framework/kyoto] (by yuriizinets)
Please, check “About” section on https://kyoto.codes I described downsides of traditional approach and problem that I’m trying to solve. It’s not a way to avoid learning of html/template, but a way to solve some common problems
-
InfluxDB
InfluxDB high-performance time series database. Collect, organize, and act on massive volumes of high-resolution data to power real-time intelligent systems.
-
Is this mean to enable something like Hotwire?
-
Okay I understand, but I think the issue isn’t as bad. Have you ever hear of goat counter? It’s a fairly robust go html/template project that gets around some of the issues. There is a bit of custom-ness to it, but that’s software engineering anyways.
-
Hacker News client demo: https://github.com/yuriizinets/kyoto-hn
-
It contradicts to the library main purpose - keep logic on the server side. WASM is cool, but do we really need so complex technology just to render a page? Just imagine, you need to bring the whole language runtime to the client side. Check average WASM payload size. It's huge! And will "micro services" approach you'll need to bring runtime for each "service". Vugu already tried to go that way: https://www.vugu.org . And personally I really like that people trying to bring something new to development. I respect that. But I don't see any ideology and benefits inside of it, except of just using Go for frontend dev. Kyoto was born from project needs to solve specific bunch of problems. I'm trying to keep main project ideology and purpose as a backbone for feature roadmap.
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.