Hacker News Reader

Comment by nzoschke | Hacker News Reader

Love Go + HTMX. I pair it with a-h/templ for a bit more type safety on the template, components and partials.

I just shared my whole toolkit too [1], I call it the "GUS stack" -- Go, Unix, SQLite. Inspired heavily by the exe.dev "GUTS" stack [2] but with HTMX instead of Typescript.

Some other Go components in the kit...

- cockroachdb/errors for errors with stack traces

- templ for type-safe HTML templates (with htmx for reactivity and tailwindcss for CSS)

- fuego for an OpenAPI spec generated from web handlers

- sqlc for type-safe code generated from SQL

- modernc.org/sqlite for a pure Go sqlite library

- goose for SQL and Go migrations

- dbos for durable workflows in SQLite

- rod for Chrome / CDP testing and automation

Feels so productive coding, agentic coding, and building and deploying binaries with this stack.

[1] https://housecat.com/blog/the-gus-stack-go-unix-sqlite

[2] https://exe.dev/docs/guts

View on HN

I'm bit sad that hyperscript[1] doesn't get the love it deserves when discussing HTMX.

Hyperscript fits perfectly in the Go + HTMX stack to do DOM manipulation without having to make a server round trip or having to write a separate JS function.

I get that not many are fan of such declarative programming, but when there's already HTML file we're working with; Hyperscript feels just like an extension of it.

I have been working on a Open Payment Host[2] which handles multiple payment gateways and was able to perform complex DOM manipulation with just Hyperscript.

[1] https://hyperscript.org/

[2] https://openpaymenthost.com/

There's security consequences to allowing inline JS, which hyperscript requires.

How so? Final validation always goes in the server side.

It means that you have to use a less strict Content-Security-Policy, which increases your vulnerability to various client-side JS attacks.

Actually even with a strict CSP i.e. without unsafe-inline, hyperscript will work as it's declared as html attributes. But as the other commenters have pointed out, with proper server validation in place the risk from Hyperscript is not greater than any other JavaScript in the application.

Will it not need unsafe-eval, though? It still creates the potential for HTML injection to lead to execution of untrusted code. Execution of untrusted code is the real issue, regardless of exactly how that code ends up being evaluated and executed. Even if Hyperscript were to have its own interpreter (so that it didn't even need unsafe-eval), you'd still have the same fundamental vulnerability (unless you add nonces, or some such).

>the risk from Hyperscript is not greater than any other JavaScript in the application.

This is not really the case. If all of your client-side code is loaded via <script src="..."> tags from bundles on your server, and you have a CSP that blocks unsafe-eval or unsafe-inline, then you have a pretty good barrier against execution of untrusted code on your page.

AFAIK Hyperscript doesn't require `unsafe-eval`, when the optional features of htmx like `hx-on:*`, `hx-vals js:`, `hx-confirm js:` is used it required the `unsafe-eval` but now there's extension[1] to use even that without compromising on strict CSP through nonce.

[1] https://four.htmx.org/extensions/hx-csp

That’s interesting, thanks. I agree that with all those extra protections enabled, there is no security issue.

The same server that's responsible for sanitizing garbage JS out of user content is also responsible for sending the Content-Security headers. Why would you trust it with one, but not the other? If it's buggy garbage it will also send the wrong headers.

This is a pretty good argument in the case of software written by a small team of experienced engineers. In that scenario, if the engineers don't have the nous to avoid the kinds of HTML injection vulnerabilities that might allow an attacker to inject their own JS code, then, as you say, they are probably also making lots of other mistakes.

A CSP is more valuable in a larger organization, where the codebase is always at risk of being modified by the organization's worst engineer.

Could rebrand to the HUGS stack -- HTMX (or hypertext), Unix, Go, SQLite

I love HUGS a lot too. Currently building a next gen platform using strictly HUGS.

my vote is for GUSH

I'm unfamiliar with these stacks but including "U" / Unix seems odd. I suspect these run completely fine on Linux, Windows or macOS. Its almost like including an "E" in your stack for electricity.

Well, the good old LAMP stack (Linux-Apache-MySQL-PHP - this was the first of these acronyms as far as I'm aware of) included L for Linux so it would make a nicer acronym. Some people changed it to WAMP when running under Windows. But HWGS doesn't roll off the tongue nicely. Maybe HAGS (with "Apple" standing in for MacOS) would work?

Or HOGS? HTMX-OS-Go-Sqlite. While having "OS" in there is kind of redundant, it does make for a nice and general acronym.

GASH?

SHAG!

Back in the days of the LAMP stack, the use of Linux would have been much less obvious and thus warranted the inclusion of the "L" in the acronym. After all, leaving it out might arguably have sounded better - the AMP stack.

Oh my GOSH (GoSqliteHtmx) stack.

I have seen this as the GoTH stack, Go Templ Htmx. Add sqlc to that gor GoTHs or GHosT stack. Love this combo, once you buy into "go generate ./..." as a build step you get so much.

I also add goverter for converting between sqlc models and template objects and return values. Like 50% of the boilerplate is generated and it makes type safety so nice

Lately I'm really liking jet[1] for typesafe SQL. It requires a live DB to generate the code, but I see that as a positive as well, since you are forced to apply migrations before writing code.

[1] https://github.com/go-jet/jet

Huge fan of jet. It lets you just write SQL, but in your Go. I basically can’t imagine using anything else now.

Why is that better than writing plain SQL like in sqlc? My main reason was being able to dynamically construct queries and reuse different bits. Plain SQL statements simply don’t compose at all, and I don’t recall sqlc giving any solution to help with this.

I tried to use templ but it felt more frustrating than ergonomic. Like at that point I'd rather just use react (and I hate react). Just sticking with basic std templates + HTMX sprinkling is good enough for my needs.

On the other end of things, for tiny responsive web apps that don't necessarily even need their own built in database, like e.g. real time API dashboards, I've been using my PAHG template a lot lately [1]. Pico.css, Alpine.js, Htmx, Go. There's no reason one couldn't hook this up to SQLite, of course.

[1] https://github.com/hiAndrewQuinn/pahg-template

you might want to try Blades CSS also, a fully compatible and actively maintained successor to Pico CSS (which was last updated >1 ago)

https://blades.ninja/

https://github.com/anyblades/blades

I was wondering: would you be able to add an RSS feed to housecat blog I can subscribe to?

Reply on news.ycombinator.com