tech stack decision

[Dishpit]

howdy! so obv we've got some choices to make here regarding the tech stack. i've got a few things in mind, but wanna get early iterative feedback wherever possible

here's what i've got:

• listener server
  • hosted server code binary, running a git server to handle git operations (commits, pushes, fetches, etc)
  • the server should also run an API layer to mediate between the frontend and the git repo; this is where the listener comes in - it receives API calls from the frontend and translates them into git commands
  • i'm thinking something like Go or Rust. node could work, but javascript /:
• frontend
  • this will interact w the API on the listener server to fetch posts, submit new posts, and update content
  • for realtime updates such as seeing new comments, i think either websockets or server-sent events instead of frequent API polling
  • probably gonna go with react or nextjs here since it's pretty common, gives us a very wide contributor net. i wanna use rails but i'm not as comfortable with it as i'd like to be, so defaulting to a js-based system here.
  • that being said, could go completely unhinged and use C for the frontend (might as well use it for the backend too, just for shiggles; it IS a damn good language, afterall)
• database
  • while git handles the posts and comments, we need a good relational db
    • stores vital user information (email, hashed password, profile data, etc)
    • links users to their git commits
    • manages permissions and roles (who can edit/comment on what, etc)
  • i like postgres. might selfhost supabase just for the ease of use + integration, and their docs are GOOD. also more to the C argument, postgres was built in C. so full C stack???

i think that's all i've got for now. so that brings us to the actual question

because this idea is so novel, do we want to go for a full novel approach and do The Based Thing™️ by building gitsoc entirely in C? or do we want to be boring and standard with go/js?

[VoxelPrismatic]

Either way you go, HTMX will help significantly. I prefer Go, because the namespace can stay clean with structs and interface reciever functions, and I don't directly have to deal with memory, but I'd be happy to use C too.

[Dishpit]

admittedly i haven't touched htmx yet, as it's always seemed to be something of a fad (at least from my outside perspective); how's the dev experience with it on a scale from Shopify's Liquid to [insert actual good language here]?

not that the fad aspect matters all that much if i'm considering C for the frontend lol

[VoxelPrismatic]

I've never touched Shopify Liquid, but HTMX is absolutely worth the hype. It's literally 4 attributes that do 99% of the work

hx-get - endpoint URL. also:

• hx-patch
• hx-put
• hx-post
• hx-delete

hx-target - CSS selector of the element to target

hx-trigger - When the endpoint should be called

hx-swap - innerHTML or outerHTML

And the server only ever replies with HTML. No need to parse client side or server side JSON.

[VoxelPrismatic]

<div id="target">
    <div if="content">Content</div>

    <button hx-get="/page/2"
        hx-target="#target"
        hx-trigger="click"
        hx-swap="outerHTML"
        >
        Next page
    </button>
</div>

[NGSpace]

Please, I beg of you, not node or any type of JavaScript on the backend.

[Dishpit]

duly noted; node (or any other JS variant) won't be considered for the backend

[NGSpace]

Since I'm unhinged enough to risk getting perma banned from this repo: I'd suggest Java Swing/AWT on the frontend.

[Dishpit]

this is unbelievably cursed

i like it

(unfortunately i'm not familiar enough w java for this to be viable; @ronnie-rios is, but i'm sure he'd prefer to avoid touching java w a 40 foot pole if at all possible)

[NGSpace]

I'm good with Java, I'm hoping you'd select a language I know since it will make it easier for me to contribute.

[Dishpit]

honestly it's a good enough excuse for me to take the time to learn java properly (assuming we use it for the backend here, and go for something more standard on the frontend)

is it performant these days? i've always been under the impression that it's fairly slow, but i could very well be wrong

also: we could build out a few different server variants for testing and comparison. i've got a simple one in C currently in main- it's not the best but it works

[NGSpace]

Java is fairly efficient for the convenience benefit, it gets a bad wrap because of legacy code which gives devs the impression that it's badly designed or slow but when used correctly it can be fairly readable and fast.

[NGSpace]

If performance ever becomes a serious issue then we could switch from the regular OpenJDK to GraalVM.

[a-catgirl-dev]

assembly backend.

[NGSpace]

agreed, full assembly backend.