Replies: 4 comments 7 replies
-
|
Agreed! "Static website with a smattering of dynamic features" is exactly what I had in mind when creating xtemplate, and "Hugo++" is a great way to describe it. |
Beta Was this translation helpful? Give feedback.
-
|
I still have a nagging idea that maybe xtemplate can be taken a lot farther and used to create app-like experiences (note the database, NATS, SSE features). I started an experiment last year with infogulch/xrss but it was never polished past a tech demo and xtemplate has made some breaking changes since then. I'm sure it "can be done" but the real question is "is it worth it compared to other options"; in particular the "initial development rate" and "long term maintenance" and "level of experience" will be the interesting metrics to look for. My suspicion is that xtemplate can be viable much further into "app" territory than where most people might guess. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah you're absolutely right. And yeah - I'm not really building app functionally, but I've found it does everything I need and more. I've been building a simple comparison site with it for fun and I've been able to do everything that I wanted - really easily.
Datastar works nicely as well using SSE - just doing some simple swaps (there may be a nicer way of doing this but works!) <html>
<title>Some site</title>
<body>
<div id="content">Original</div>
<button data-on-click="@get('/some-url')">Some button</button>
</body>
</html>{{- define "SSE /some-url" }}
{{- $frag := cat "fragments" (.X.Template "some-html" nil) }}
{{- .Flush.SendSSE "datastar-merge-fragments" $frag }}
{{- end }}
{{- define "some-html" -}}
<div id="content">Updated!</div>
{{- end -}}Also getting an admin up and running was simple using just basic auth (site would be over ssl behind caddy so basic auth is likely fine as far as i know) {{ define "basic-auth" }}
{{ if eq (basicAuth .Req) false }}
{{ .Resp.SetStatus 401 }}
{{ .Resp.SetHeader "WWW-Authenticate" `Basic realm="Restricted"` }}
{{ template "/401.html" }}
{{ return }}
{{ end }}
{{ end }}And the function /*
Borrowed from this excellent article
https://www.alexedwards.net/blog/basic-authentication-in-go
*/
func basicAuth(r xtemplate.DotReq) bool {
username, password, ok := r.BasicAuth()
if ok {
// Calculate SHA-256 hashes for the provided and expected
// usernames and passwords.
usernameHash := sha256.Sum256([]byte(username))
passwordHash := sha256.Sum256([]byte(password))
expectedUsernameHash := sha256.Sum256([]byte(os.Getenv("APP_USER")))
expectedPasswordHash := sha256.Sum256([]byte(os.Getenv("APP_USER_PASSWORD")))
// Use the subtle.ConstantTimeCompare() function to check if
// the provided username and password hashes equal the
// expected username and password hashes. ConstantTimeCompare
// will return 1 if the values are equal, or 0 otherwise.
// Importantly, we should to do the work to evaluate both the
// username and password before checking the return values to
// avoid leaking information.
usernameMatch := (subtle.ConstantTimeCompare(usernameHash[:], expectedUsernameHash[:]) == 1)
passwordMatch := (subtle.ConstantTimeCompare(passwordHash[:], expectedPasswordHash[:]) == 1)
// If the username and password are correct, then call
// the next handler in the chain. Make sure to return
// afterwards, so that none of the code below is run.
if usernameMatch && passwordMatch {
return true
}
}
return false
}Another cool thing was the file hashes - your example <link rel="stylesheet" href="/css/pico.css" />
{{- with $hash := .X.StaticFileHash `/css/main.css` }}
<link
rel="stylesheet"
href="/css/main.css?hash={{ $hash }}"
integrity="{{ $hash }}"
/>
{{- end }}This has always been a pain for me building sites over the years! Bottom line, I would say for the sites I build - it's more or less perfect. In terms of the metrics you mention
I've only looked at the SSE stuff quickly - but i can see how there are a whole world of app like possibilities there. Fantastic! What is NATS by the way?? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for all the feedback, I'm glad you're having fun with it!
That's exactly the vibe I was aiming for! 😄 SSE is built as a super lightweight streaming update mechanism. Today you could write a loop in an SSE handler that polls the database every second or whatever for updates, and if the qurey returns anything then render a template and send it to the browser right away without waiting for a reload or some user event. To be fair to this strategy if you have a good index+query design this could probably be surprisingly efficient with sqlite. Besides that maybe Go channels could work too but it seems like it would be a lot of effort to create and manage them, and also it doesn't have any good mechanism for broadcasting messages. Lets take a simple example: the user receives a notification, every tab they have on any device should immediately show the notification count go up. It would be kinda nice for the browser to just wait for events on a live tcp connection (aka SSE), and the server waits on a Go channel, so nobody is busy waiting or polling (heartbeats aside). Then as soon as the notification is broadcasted on this user's channel the server channel wakes up and sends an SSE message, and the browser receives it and adds it to the page right away. So xtemplate has an embedded NATS server for this purpose. NATS is a "message bus" system (like Kafka for example) written in Go. It can go the whole 9 yards and be networked with other servers with durability and millions of messages per second etc, OR you can just use one instance embedded into xtemplate to connect different browser sessions together. Maybe NATS+xtemplate is like the A-10 warthog: NATS is the comically oversized gatling autocannon and xtemplate is the plane bolted onto it 😆. To be honest I'm not exactly sure how best to integrate it. Check out the nats test directory for a fun demo: https://github.com/infogulch/xtemplate/blob/master/test/templates/nats/index.html |
Beta Was this translation helpful? Give feedback.
-
|
Haha, I like the A-10 analogy. Love the demo as well - got it up and running. I'll have to take a look into into NATS and SSE more closely. Just looking at your tests directory. I've often used curl over the years - what a brilliantly simple idea HURL is. I guess for testing xtemplate that's perfect as it (xtemplate) is a caddy module as well - so you can't just test the template functionality in the "normal" go way of somefile_test.go? |
Beta Was this translation helpful? Give feedback.
-
|
Well I'm packaging it three ways actually: as the CLI app, as a Caddy module, and as a docker image. I wanted to ensure that I don't accidentally break one of these and not notice (like the default docker port), so I came up with this scheme to run e2e tests for all three packages at the boundary. This has worked well so far because the purpose of a web server is to respond to http requests and that's actually the best layer to run some of these tests imo (like checking that it serves assets correctly with status codes, hashes, If-None-Match & etags, encodings etc). I agree that the internals could probably use some more normal Go tests. But when I think about adding tests I get a bit of a mental block and I'd rather go implement some more features that are on the list. Maybe I could use some help to get the ball rolling 😅. |
Beta Was this translation helpful? Give feedback.
-
|
You know I bet this could be easier... <link rel="stylesheet" href="/css/pico.css" />
{{- with $hash := .X.StaticFileHash `/css/main.css` }}
<link
rel="stylesheet"
href="/css/main.css?hash={{ $hash }}"
integrity="{{ $hash }}"
/>
{{- end }}...with something like this: <!-- in any file: -->
{{- define "link-stylesheet"}}
{{- with $hash := .X.StaticFileHash . }}
<link rel="stylesheet" href="{{ . }}?hash={{ $hash }}" integrity="{{ $hash }}" />
{{- end}}
{{- end}}
<!-- later... -->
{{template "link-stylesheet" "/css/pico.css"}}
{{template "link-stylesheet" "/css/main.css"}}Edit: Wait no that won't work. I keep forgetting that if you override Ok its a bit messier than I'd want but this actually works now and is more general, though vulnerable if the attribute names are set dynamically. {{- define "link"}}
{{- $dot := .dot}}{{$_ := unset . "dot"}}
{{- $href := .href}}{{$_ := unset . "href" }}
{{- $hash := $dot.X.StaticFileHash $href }}
<link href="{{ $href }}?hash={{ $hash }}" integrity="{{ $hash }}"{{range $k,$v := .}} {{$k | trustAttr}}="{{$v}}"{{end}}/>
{{- end}}
{{- template "link" (dict "dot" . "href" "/assets/reset.css" "rel" "stylesheet")}}
{{- template "link" (dict "dot" . "href" "/assets/print.css" "rel" "stylesheet" "media" "print")}} |
Beta Was this translation helpful? Give feedback.
-
|
NIce. I always feel like I'm flying by the seat of my pants with Go templates, especially using the Sprig template functions. I've not seen unset used before? Outside the scope of this project - but what do you think of Templ or Gomponents for writing html? |
Beta Was this translation helpful? Give feedback.
-
|
I agree with the "seat of your pants" feeling, it would be nice to have a bit of type checking. Sprig functions seem fine, it's just there are a lot of them and they're only moderately documented. I just scanned through the whole list to get an idea of what kinds of things they allow you to do, then look them up again later to get the details. For me the bigger issue is knowing when it's reasonable to try an approach or not. Like this one, looking back at it I'm not even sure I would use this link template, it's probably better to just tank the two extra lines for the cause of simplicity: {{with $hash := .X.StaticFileHash `/css/main.css` }}
<link rel="stylesheet" href="/css/main.css?hash={{ $hash }}" integrity="{{ $hash }}" />
{{end}}A lot of people like Templ and Gomponents, but I feel like they tend to railroad you into the typical "12 factor app" approach with all these extra layers between you and the first party web tech you actually want to use. That said, I don't have a lot of experience with ether. Maybe they're clearly better when you get to a certain scale. The nice thing about xtemplate being targeted at the "rapid application development" niche is that it should be very easy to switch to something else since 80% of your code is just the html you would have written anyway. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah I think you're likely right on Templ and Gomponents - good luck to them though. I think they might solve a certain problem - but re. "12 factor" maybe its just a problem that people have created for themselves. I hear you on type checking - it's probably a bit hairy with larger projects - but again, I think when you weigh that up against the overhead of having to learn and bet the farm on a whole different way of doing things and hoping that it will all still be supported next year - I've been tempted...! I think "rad" is always best - most of the time - you can "stack" things too high imo. |
Beta Was this translation helpful? Give feedback.
-
|
Another thing about the DSL approaches - I Imagine it's much easier to be seduced by the idea of breaking the interface down into component parts that are perfect but just the right size to spend literally hours glueing them all back together with if else / switch etc. HTML should be more like wallpaper! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Lots of people out there have built Hugo sites but invariably hit a snag where they want to add some dynamic content. Xtemplate seems almost perfect for porting static sites that have hit the limits of what you can do with the static model - so you can add forms, tracking etc, all the dynamic bits that sites inevitably end up needing.
I've not attempted it but I would imagine migrating a simpler Hugo site to xtemplate would be fairly straightforward.
Probably not an original idea but I thought it was worth mentioning :)
Beta Was this translation helpful? Give feedback.
All reactions