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.
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.
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.
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
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.
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]
29 comments
[ 3.0 ms ] story [ 72.2 ms ] threadYou probably should explain what it is and what problem it solves first.
[1] Not even sure whether to call it a framework or a library.
A framework is something that you use by sprinkling around your code in it.
A library is something you sprinkle around in your code.
A framework calls your code.
This often makes frameworks incompatible, whereas libraries can be used in conjunction.
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.
I'd go for something like this font-wise: https://www.gitbook.com/about
The HN demo is extremely complex for a demo, this woukd benefit from a simple documented example.
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?
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...
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.
Is it? Why not just demonstrate it with a snippet of code -> the output above the fold and let your audience decide?
See https://reactjs.org and https://svelte.dev for examples.
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.
edit: Ah, I just saw this account was created to make this comment. I can draw my own conclusions. Welcome to HN!
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...
https://go-app.dev/
> 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