Kyoto – Build Front End with Golang | Hacker News Reader

Kyoto – Build Front End with Golang

kyoto.codes

85 pointsyuriizinets25 comments

If you look at the sample project you can see that this is a way to create nested objects which describe the page you are rendering. [1]

Those objects can contain I/O logic (database calls or http requests) which are used to populate the "component". [2]

This is not a true replacement for Javascript SPA frontends like react or vue which offer much more than rendered HTML. It's more of an opinionated way to organize and populate your HTML templates for plain server-rendered pages.

I am not a huge fan of this format as I prefer regular template partials + inheritance. [3]

1: https://github.com/yuriizinets/kyoto-hn/blob/master/page.sto...

2: https://github.com/yuriizinets/kyoto-hn/blob/master/componen...

3: https://lets-go.alexedwards.net/sample/02.08-html-templating...

I don't quite get how it works or even what it is? The landing page unfortunately does not give me a great understanding. Is this something like Phoenix Liveview?

You probably should explain what it is and what problem it solves first.

That was my thought as well. As someone who has written several web frontends in Go, I want to know what this tool [1] does differently.

[1] Not even sure whether to call it a framework or a library.

what's the distinction between framework and library?

The best one I've heard is something like:

A framework is something that you use by sprinkling around your code in it.

A library is something you sprinkle around in your code.

Your code calls a library.

A framework calls your code.

This often makes frameworks incompatible, whereas libraries can be used in conjunction.

Now that's a proper clipped and precise explanation.

what a concise and excellent explanation (seriously); thanks

I am not a Go developer, but given the prevalence of Go in infrastructure tools I've written Go templates.

My understanding of Go's built-in templating is that it is the bare-minimum templating language worth including with the language. Useful for quick and dirty plain HTML pages for inspecting service states, not for building frontends.

Does this package really intend to use Go templates for your whole frontend? That seems not ideal?

> Does this package really intend to use Go templates for your whole frontend? That seems not ideal?

Yes, based on this page [1] it looks like that is the intension.

I built a user account manager from scratch for a company with 56M users, and utilized Go templates for all the static content and pages that only needed a handful of variables. For more complex pages, Go templates was very cumbersome, so I had to add a JavaScript framework (Vue.js) to implement pages that users were supposed to interact with. I enjoy using Go for command line tools, system background services, and web services, but for complex web development, never again.

After three (3) years working on that project, I would not recommend Go templates for complex web development at all.

[1] https://kyoto.codes/docs/core-features.html#component-lifecy...

I worked on a project using Revel, which uses Go templates. As the pages got more complex, we ran into the same problem. Eventually (most of) that app got replaced by a Go server and React front end.

My takeaway was that it seems to me like Go templates work well for simpler stuff; displaying simple content, debug info, etc. But as soon as you want to edit something you should start thinking about moving to a more appropriate stack.

Go templates are a nice balance of power and simplicity in my experience (Hugo, and a few similar projects). What features do you miss from other templating engines?

They may refer to the definitive shortage of built-in functions. The template engine itself only provides the bare minimum. That's usually not a problem because of template function libraries like https://github.com/Masterminds/sprig

The landing page would really benefit from code samples illustrating the basic concepts and syntaxes.

See https://reactjs.org and https://svelte.dev for examples.

There is a typo under A Better Way to Build Your Frontend.

> Use page-level context without "worring" about concurrency and mutex

Edit: here is a PR to fix that https://github.com/yuriizinets/kyoto/pull/46

It seems that Go-App is much more mature than this project.

https://go-app.dev/

Some stylistic remarks:

1. If you're submitting your own stuff, put "Show HN" in the title to indicate that you're affiliated.

2. The first 50% of the website is just impenetrable marketing copy. I've read it and I have no idea what's going on, even though I'm quite familiar with both Go and frontend development. Maybe replace 50% of the marketing copy with a short example of "here's a problem that's very tough to solve with stdlib, here's how to solve it in 20 lines of code with this tool".

3. More generally speaking: Your project is small, so style your website accordingly. An entire section with "dry numbers" where several of them are single-digit is just bizarre. That space could have been used for a second actual code example.

4. Don’t talk about “frontend” like “more cowbell”

This is personal but my first impression with that font was not pleasant.

I'd go for something like this font-wise: https://www.gitbook.com/about

"Show HN" is its own thing. People don't need to use "Show HN's" when they're posting their own stuff here, and often shouldn't.

alluding to the 2nd point. thought, I was just being deft. I read a lot, but didn't understand a single thing.

Same issue as other commenters, I have no idea what it actually does despite being an experienced Go developer.

The HN demo is extremely complex for a demo, this woukd benefit from a simple documented example.

> Mind Blowing Way to Build Frontend

Is it? Why not just demonstrate it with a snippet of code -> the output above the fold and let your audience decide?

Wow tough crowd here. Nothing wrong with the landing page. It is there to wet your appetite and does that nicely.

The About section (yes, scroll down a little) describes the problem it is trying to solve, and while it could be more clear the problem definition is clear enough.

I always found it unbelievable that in front end development the build environment is more complicated than the application it is used to write. The hours wasted to resolve some obscure problem that has nothing to do with the application I'm trying to write... Why do people put up with that?

This project thinks out of the box to try to solve this problem. Many Kudo's to you for trying. I hope it will be a smashing success.

Please ignore the unconstructive whining here. To those: If you see room for improvement then help out or at least be constructive about it.

Most of it seems like pretty constructive feedback here. Opposite of unconstructive whining. whet your appetite.

edit: Ah, I just saw this account was created to make this comment. I can draw my own conclusions. Welcome to HN!

Reply on news.ycombinator.com