Urso @urso@bear.community

@Jordan I'm not against it!

the "glue-code" was to be aware of the turbo-frame header on the request. If present, then we only render the frame needed for the request and ignore the rest of the html surrounding it. Since I'm stitching together a number of libraries on Clojure, this one was on me... but I saw some libraries for Python environments that do the same

Phoenix has something similar, but it works over websockets. Hotwire just intercepts regular http requests, which I prefer

Update on the JS front-end thingy:

I think the rails folks did something fun: hotwire works pretty well in giving the impression of an SPA but with server-side rendering

Since I'm using a clojure stack I had to write some code just so I had to render less than needed when a turbo-frame request shows up, but it wasn't strictly necessary. Most interesting aspect of it is that I was able to develop like an OG web app (productivity up, complexity down) and then plug it later in an afternoon

Long story short, I scrapped everything. Going with good old server side rendering. Should it need an SPA, it can be added later. I feel so much productive now

So I spent some time this morning, yet again, going through the motions of a react stack, then Vue. Both felt too big, the amount of code I'd write was far bigger than the perceived benefits

Then there's (wrapped) webpack, the test stack, bundling and minifying, sometimes transpilation... Half of these tools will be replaced in two years or so. Some already are outdated, but I wanted to cut off time by going to tools I'm already familiar with

@celestial_monarch maybe, for example, Mastodon's logged ui is one of the examples where an SPA fits. I think hotwire and Phoenix's live view convinced me that reacts "solution space" is smaller than it seems

@celestial_monarch I'm more of a back end kind of dude, and a good number of data validations on the front end should also be done redundantly on the backend anyway. I've submitted logic-breaking forms many times just by tweaking js and checking whether the server is doing what it is supposed to

@robdaemon I've worked in many places where senior engineers make smart libraries on top of react (itself already a fairly complex piece). I could never justify the extra layer for the so called "features"

@celestial_monarch oh my God, for a really small (functionality wise) page, I'd much rather deal with server side rendering and some optional js to enhance things here and there. It is much less code, hands down, and I'm less prone to breakage or backwards incompatible changes down the line

And with most browsers, just vanilla js is already fine

@shello @celestial_monarch I don't think it's much the functional paradigms, but the haskell heritage. By my experience, it makes grasping functional concepts a bit harder depending on the individual

@shello @celestial_monarch also the burden of the next developer having to maintain it. I always have this in mind when choosing technologies.

And I do think Elm is a bit difficult to grasp for the average developer lmao

@celestial_monarch I don't think anyone is at fault here.

Maybe I'm just bitter. But I'm almost, almost sure 90% of projects using react and other shit on top didn't really need its complexity to begin with

@banjo because I swear, if I have to fight another webpack or flavor of the day build system again, along with the myriad of complexity around react (and the others!), I'll die soon

@banjo backend is clojure, so hot wire (turbo frames, I think?) seems a bit more ready to use off the shelf. Promising, but I'm not committing to it yet

For what I need, it is almost perfect. It's either that or good old server side code with sprinkles of js here and there

@shello @celestial_monarch I don't do languages that transpile to js, mainly because of awkward experiences with other languages (clojure script, mainly)

I like haskell but I'd rather not have to learn another language to develop a top heavy frontend that in principle doesn't need that much complexity

@banjo I'm actually considering hot wire (from the rails folks), which I hear is the same thing. Allows me to develop server side rendered and then later cheat out with it