https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • g
    the real grug move would be make+pandoc
  • r
    I think a big advantage of the javascript is it shows current javascript devs the htmx path without being too far off path for them. Makes htmx effective at its job of turning the current ecosystem on its head.
  • g
    clearly we need to write a 0-dep ssg in javascript
  • m
    you can do hugo for pure, ssg and its dead simple. if you are dynamic that's what i'm doing with htmx and its very easy
  • m
    but i'm doing stuff with quicktemplate and gomponents so its all compiled and no reflection
  • r
    It's interesting but ultimately probably just a big distraction. First glance people might be a bit put off from seeing "go" source code in there too, also golang has hardcore amounts of build steps.
  • m
    TIL... hardcore === 
    go mod tidy && go run *.go
    . You must mean something else
  • r
    When I contribute to gitea development, the biggest annoyance by far is the build step.
  • r
    Like, relative to other languages, Go is a freakin fast compile, but it's still super slow iteration time compared to zero build.
  • m
    for my htmx stuff i use https://taskfile.dev/ (which is better than make in every way) and just watch the src and rebuild... its a 10 line thing to do to get auto reload... a few more lines to autocontrol the browser to reload the last page i was working via 
    github.com/go-rod/rod
  • m
    go caches its builds so you are only recompiling wwhat you change. i just clone gitea takes 21 secs first time.... 0.3sec next time... make a change to the cli and its 0.2s. So not sure what you are talking about
  • r
    I'm on a 16 core machine with nvme, it ain't quite that fast to iterate. But anyways.. i'm not here to bash peoples stacks. go is amazing for a lot of things.
  • l
  • l
    Used to? Lucky....
  • m
    i'm on a 7700 with 8gb so nothing fancy. I legitimately don't understand what you are saying. Feel like there can be a lot of FUD here. I feel like something about your setup is just wrong.
  • r
    gitea is a big project man. I don't get sub-second build times.
  • m
    but i do so what is different... ➜ gitea git:(main) ✗ time go build main.go go build main.go 1.06s user 0.22s system 291% cpu 0.441 total
  • l
    This app I was talking about... Build Tools and their deps - 748 MB Local Maven repo - 377 MB 
    node_modules
    for Angular app with customizations (written to replace the Flash version of the same thing, wish I knew about htmx when I made that decision) - 537 MB When I started these were all in the same Git repo as the code; you had to transfer over 5 GB to do a full clone! Those 3 items are now submodules, and the code repo is much easier to deal with.
  • l
    IIRC, Hugo can be run as an executable; you don't need Go installed to run it.
  • r
    Really really off topic but go build main.go doesn't build the whole project, which is why we're seeing an inconsistency. But this is super gitea specific.
  • r
    Once you start touching templates and stuff the build time goes up lots.
  • l
    Re: the whole vendoring vs. pulling thing - it's a trade off (as is everything). Vendored can be pulled locally, and you eliminate supply chain vulnerabilities (unless you introduce them yourself). OTOH, you can end up with stale dependencies with known vulnerabilities, because you're not updating them regularly. (Nobody updates them regularly unless they're in active development.)
  • m
    not doubting you beyond i've been doing go dev for almost a decade and I don't see the issues you are talking about. i don't work with gitea so there must be something there than not normal. My htmx/go longest wait time is on the tailwind cli. (which i'm working on a port for). And that's like 400ms
  • g
    GitHub's code scanners do a really good job of keeping up with this -- almost too good, because I get automated pull requests every few days.
  • l
    Vendored or referenced?
  • r
    yeah fair enough. gitea probably has some unconventional build steps in there-- trying to replace github leaves lots of room for unoptimised things to creep in.
  • g
    I'm currently using Go Modules, so I know GitHub CodeQL and Dependabot work for referenced dependencies. I'd bet they also works for vendored dependencies, but I haven't used them personally.
  • l
    This was a joke (I think) but I have been mentally tooling around with trying to set up a small ecosystem of 0-dep JS projects, and maybe do something goofy like make a github badge that other projects can add to their readme to make a little network effect
  • l
    Having reasonable alternatives to express, a template engine, etc. and setting an expectation that library code has no additional dependencies (where reasonable) would really solve a lot of people's complaints about server-side JS imo
  • m
    zdeps.js
1...104610471048...1146Latest