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

Hologram Works. Sponsor What Comes Next

hologram.page

Post reply on HN
Print view View original

21–30 of 37 posts

Re: Hologram Works. Sponsor What Comes Next

#21

Post by catchnear4321 »

grimgrin wrote: post #15
turtlebits wrote: post #14

Earlier 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

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.

Re: Hologram Works. Sponsor What Comes Next

#22

Post by troupo »

jamauro wrote: post #20
troupo wrote: post #19

The only thing that's stopping me from trying this currently is file uploads. Otherwise it's a really cool project

It can handle file uploads. What issue are you running into?

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

Re: Hologram Works. Sponsor What Comes Next

#23

Post by bartblast »

taatparya wrote: post #4

Would be great for reviving LiveView Native. Perhaps Dockyard / Brian Carderella might be interested.

Mobile's part of the plan - one Elixir codebase across web, mobile and desktop, with local-first as the groundwork. Covered in the post and roadmap (https://hologram.page/docs/roadmap).

Re: Hologram Works. Sponsor What Comes Next

#24

Post by bartblast »

troupo wrote: post #22
jamauro wrote: post #20

Earlier quoted context omitted.

It can handle file uploads. What issue are you running into?

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 the returned reference to a command for processing.

A proper Hologram-way file upload is planned as part of a high-level forms abstraction, which comes after Local-First support lands.

Re: Hologram Works. Sponsor What Comes Next

#25

Post by bartblast »

hexasquid wrote: post #16

The things people do to not use web technologies.

Hologram author here. It's the opposite, really - the whole thing is built on web technologies. The compiler builds an IR from your Elixir code, analyzes the call graph, and spits out per-page JavaScript bundles. In the browser it's regular JavaScript patching the real DOM, and transport is plain HTTP (POST + Server-Sent Events) - no canvas rendering, no WASM. It uses Web APIs directly, and the goal is to make the whole Web API surface available from Elixir. The only thing being swapped out is the authoring language, same as with TypeScript or Elm.

Re: Hologram Works. Sponsor What Comes Next

#26

Post by bartblast »

bicx wrote: post #3

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. I ended up building an agent orchestrator in Elixir and Phoenix, not because I love working in Elixir/Phoenix (I do, but I just don't write code by hand anymore), but because the BEAM/OTP capabilities genuinely worked more…

[dead]

Re: Hologram Works. Sponsor What Comes Next

#27

Post by bartblast »

turtlebits wrote: post #14
bicx wrote: post #3

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. I ended up building an agent orchestrator in Elixir and Phoenix, not because I love working in Elixir/Phoenix (I do, but I just don't write code by hand anymore), but because the BEAM/OTP capabilities genuinely worked more…

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.

[flagged]

Re: Hologram Works. Sponsor What Comes Next

#28

Post by bartblast »

nightfuryg wrote: post #6
bicx wrote: post #3

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. I ended up building an agent orchestrator in Elixir and Phoenix, not because I love working in Elixir/Phoenix (I do, but I just don't write code by hand anymore), but because the BEAM/OTP capabilities genuinely worked more…

Did you use something like Jido or roll your own out of curiosity?

There's Jido Assembly that uses Hologram under the hood: https://github.com/agentjido/jido_assembly

Re: Hologram Works. Sponsor What Comes Next

#30

Post by Towaway69 »

bicx wrote: post #3

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. I ended up building an agent orchestrator in Elixir and Phoenix, not because I love working in Elixir/Phoenix (I do, but I just don't write code by hand anymore), but because the BEAM/OTP capabilities genuinely worked more…

That sounds like a case of SEO - Suggestion Engine Optimisation. Is that a thing yet? Sounds like the next AI Unicorn.
Post reply on HN