The things people do to not use web technologies.
How do you think things appear in the browser if they don't use web technologies?
Hologram Works. Sponsor What Comes Next
31–37 of 37 posts
Re: Hologram Works. Sponsor What Comes Next
#32Hologram is a joy to work with. Local first support will take it to the next level. Bart is cooking.
Local-first is simmering! :)
Taking a peek at the repo and the local first data layer issue (https://github.com/bartblast/hologram/issues/940) I get the sense that you aren't (and not planning to) using any off-the-shelf CRDT or the like, am I right in that assumption?
How will conflict resolution be handled? Or is it a last-write-wins type setup? It would be amazing to have this build on top of automerge or something like that! It could compile to and use the automerge js libs in the browser, and deal with automerge through a NIF server side? Ok, not knowing your implementation and plans, I have to confess I am talking a bit out of my arse here...
Re: Hologram Works. Sponsor What Comes Next
#33Earlier quoted context omitted.
Local-first is simmering! :)
Taking a peek at the repo and the local first data layer issue ( https://github.com/bartblast/hologram/issues/940 ) I get the sense that you aren't (and not planning to) using any off-the-shelf CRDT or the like, am I right in that assumption? How will conflict resolution be handled? Or is it a last-write-wins type setup? It would be amazing to have this build on top of automerge or something like that! It could compi…
[dead]
Re: Hologram Works. Sponsor What Comes Next
#34Earlier quoted context omitted.
I'm on the opposite side of this. With LLMs, I no longer feel the need to use crazy frontend frameworks and abstractions. I'm back to building static HTML with minimal JS (and ideally no build step). Instead of using Tauri/Wails for GUI apps, I just use Swift. I no longer try to build everything around my choice of language.
right, you're using the tool for the job. author was reaching for reliability, re: OTP/beam. now we don't know if they actually needed it, but, you're saying the same thing to me
It was the BEAM process/actor model that fit much better for managing agents, and then there was the out-of-the-box live UI with Phoenix/LiveView that was really appealing. I had started the project in Typescript/Node (because that's my company's primary stack choice), but it hit a plateau in reliably managing multiple independent long-lived agent processes (not really what Node is designed for). I could have used an even more boring tech like Go with more robust process management, but Elixir and Phoenix also came with a lot out of the box. It's no surprise that OpenAI's reference project for agent orchestration (https://github.com/openai/symphony) is also written in Elixir.
Re: Hologram Works. Sponsor What Comes Next
#35Earlier quoted context omitted.
right, you're using the tool for the job. author was reaching for reliability, re: OTP/beam. now we don't know if they actually needed it, but, you're saying the same thing to me
i see one person saying it is now cheap to support the new hotness, which previously would have been its own project, and another saying it has become cheap again to do things the boring-yet-reliable way that maybe didn’t used to scale so great.
that's fair. probably i attached more weight to the opening line: "We're in an interesting time where my framework/stack choice is now much less dictated by existing engineer expertise and more about fundamental capabilities in the framework and stack themselves."
assuming author wouldn't choose X _just because_ it is the new hotness
Re: Hologram Works. Sponsor What Comes Next
#36Earlier quoted context omitted.
Local-first is simmering! :)
Taking a peek at the repo and the local first data layer issue ( https://github.com/bartblast/hologram/issues/940 ) I get the sense that you aren't (and not planning to) using any off-the-shelf CRDT or the like, am I right in that assumption? How will conflict resolution be handled? Or is it a last-write-wins type setup? It would be amazing to have this build on top of automerge or something like that! It could compi…
I don't think CRDTs are needed and they come with some significant downsides. Bart's plan has the right idea using server reconciliation.
Re: Hologram Works. Sponsor What Comes Next
#37Earlier quoted context omitted.
Last time I tried it (quite some time ago) it didn't have anything built-in for file uploads: https://github.com/bartblast/hologram/issues/228 I've tried to keep an eye on its development, but I don't think file uploads were mentioned yet (and there's nothing about them in the docs).
There's no easy out-of-the-box way yet. But you can do it today with JS interop as a workaround. For small files: read the file and send the bytes directly in a Hologram command payload. For big files: fetch-POST the file to your own Phoenix endpoint, or directly to S3 with a presigned URL (no extra endpoint needed, since presigning can happen in a regular Hologram command or in the page's initial state), then pass t…
> directly to S3 with a presigned URL
yep, this is what I'm doing except with cloudflare's R2 :)