Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I use HTMX with Go

alexedwards.net

Post reply on HN
Print view View original

101–110 of 121 posts

Re: How I use HTMX with Go

#101

Post by Abishek_Muthian »

foldr wrote: post #72
germandiago wrote: post #62

Earlier quoted context omitted.

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.

Re: How I use HTMX with Go

#102

Post by foldr »

Abishek_Muthian wrote: post #101
foldr wrote: post #72

Earlier quoted context omitted.

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 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.

Re: How I use HTMX with Go

#103

Post by sgt »

evilduck wrote: post #96
sgt wrote: post #91

Earlier quoted context omitted.

Been building a fairly medium to large sized web app in HTMX these last few months and if done correctly, it can be done fairly cleanly and it's best combined with templates of some kind (e.g. the templating in Golang or in Django).

“If done correctly” applies to about everything though.

Problem is that a lot of people don't want to spend some minimum effort getting some fundamental understanding about the technology they are using. They just want to rush it to build something. It's been like that forever.

Re: How I use HTMX with Go

#104

Post by lenkite »

nchmy wrote: post #22
lazypenguin wrote: post #20

Earlier quoted context omitted.

I also prefer Datastar but the new features coming in HTMX4 closes the gap more. Happy to see the ecosystem converging on good patterns.

But the point is that Datastar only exists because htmx rejected all of those ideas. Now it's becoming a cheap, more complex, less powerful, heavier copy of Datastar. Just use the genuine article.

I would just go all the way to using https://unpoly.com/ if I wanted the full-bang whiz.

Re: How I use HTMX with Go

#105

Post by Abishek_Muthian »

foldr wrote: post #102
Abishek_Muthian wrote: post #101

Earlier quoted context omitted.

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,…

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

Re: How I use HTMX with Go

#106

Post by solatic »

asdfsa32 wrote: post #89
solatic wrote: post #79

Earlier quoted context omitted.

Just curious: the people behind HTMX have a frontend sibling project called Hyperscript, which handles stuff like frontend state: https://hyperscript.org/docs/reactivity/ Did you give it a try?

At that point just use React.

I'm not convinced. Hyperscript's reactivity model is highly greppable, and it keeps the no-build approach to Web frontend interactivity. It's "just enough" in the same way that HTMX is.

React probably scales better for huge engineering divisions, but that isn't who the GOTH stack is aiming for anyway.

Re: How I use HTMX with Go

#107

Post by outlandishCat »

yawaramin wrote: post #35

If you’re using htmx, I highly recommend an HTML generation technique in your backend that lets you easily componentize in the same way as you can with React. Eg, extracting common pieces of HTML markup into functions much like React components. The reason is that htmx requires a certain amount of flexibility in the HTML generated by the backend. Eg, you need to be able to generate a certain piece of HTML markup and…

For my Python backend I'm having success with JinjaX https://jinjax.scaletti.dev/

Re: How I use HTMX with Go

#108

Post by mixmastamyk »

arch1e wrote: post #43

As someone who tried to build a fairly large project with HTMX + Go, I can say it just wasn't there for me. Maybe it will get there eventually, but I'm not convinced. For simple CRUD apps and admin dashboards, HTMX is great. But once you have lots of interconnected components, shared state, and complex interactions, managing everything quickly becomes difficult. I originally chose HTMX because I really didn't enjoy w…

The htmx site is clear about tradeoffs and that it is not suitable for that use case. Though you have to dig for the articles.

Re: How I use HTMX with Go

#109

Post by foldr »

Abishek_Muthian wrote: post #105
foldr wrote: post #102

Earlier quoted context omitted.

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,…

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.

Re: How I use HTMX with Go

#110

Post by PrimalPower »

Am I the only one who dislikes Go specifically for CRUD webapps?

I’ve worked with Go professionally for the past 5 years, and I genuinely like the language. I like the anti-framework philosophy, the simplicity, the resistance to over-abstraction or even worse... bad abstractions, fast builds, the light native binaries, and how easy it is for a team to converge on idiomatic code.

But the moment you’re building a normal product app, even “basic CRUD” is rarely just CRUD. You need a database layer, migrations, auth, validation, maybe an OpenAPI spec, background jobs, admin flows, maybe server-side rendering, maybe GraphQL, etc.

You can end up with a large codebase full of repetitive boilerplate for an app that does not actually do much conceptually.

Maybe some people see a large codebase and feel accomplished, but just because each line of code is readable doesn't mean you know what its doing.

Post reply on HN