yeah, how in the world are we ever gona update a binary in 2025... is this really still an issue? webdevs try to make GUI software in a browser for one reason; they can only code in web languages. Basically, if all you know is a hammer, everything looks like a nail
re: "What are they exactly? Youve already mentioned distribution, but what else?"
Here are the key advantages of web clients beyond distribution:
Instant updates - Push a new version and every user gets it immediately. No app store approval process, no waiting for users to update, no supporting multiple versions in the wild.
Universal accessibility - Works on any device with a browser. Your grandmother's old Windows laptop, your coworker's Chromebook, someone's phone - all access the same application without platform-specific builds.
Zero installation friction - Users can try your application instantly by clicking a link. No download, install, permissions, or disk space considerations.
Sandboxed security model - Browsers provide built-in security isolation. Users trust clicking web links more than downloading and running executables.
Seamless integration - Easy linking, sharing, bookmarking. Users can send a direct link to a specific state of your application.
Lower development/maintenance overhead - One codebase, one deployment pipeline, one set of bugs to fix. Compare that to maintaining separate iOS, Android, Windows, Mac, and Linux builds.
Built-in networking - HTTP/WebSocket APIs are first-class citizens. No need to bundle networking libraries or worry about firewall configurations.
That said, native absolutely wins on performance, system integration, and offline capabilities. It's genuinely about picking the right tool. For Hologram specifically, we're trying to get you closer to native performance while keeping these web deployment advantages - best of both worlds for certain use cases.
You are ignoring all of the advantages of writing a web client. Are you really saying that distributing a native app for every platform is better than writing something that uses the browser?
Well, distribution is the killer feature. More, it's inherent property of the platform (web).
Web devs are in full control of their whole stack (excluding the browser where you occasionally need to account for incompatibilities), have to maintain only one version of the app (no upgrade needed on client-side), are not constrained by the platform owner's policies (app store tax).
Yes, it's more limited than native technologies in other ways, so it's not an answer for every problem.
> have to maintain only one version of the app (no upgrade needed on client-side)
Except what happens when it doesnt run the same on Firefox as it does on Chrome? Or what about when Edge is run on Win7 and youre app doesnt render correctly? Yes you only code one version of an app, but you are still obliged to consider the underlying platform - which is exactly compile once, run anywhere is it? its more like compile once but make sure you test it on all the different browser/OS combos before you do.
Distribution aside, its more likely you only know web languages and THATs why youre coding your project on the web stack. Pick the best tool for the job
I appreciate the perspective, but I think you're mischaracterizing what Hologram is about. We're not web developers who "can only code in web languages" - we're Elixir developers who've deliberately chosen Elixir for its technical merits (fault tolerance, Actor model, pattern matching, etc.) and want to leverage that investment across our entire stack.
Your hammer/nail analogy actually supports the case for Hologram: if Elixir is genuinely a superior tool for building systems, why shouldn't we extend that tool to work client-side too?
Native development absolutely has its place, and for many use cases it's the right choice. But there are legitimate scenarios where you want the reach and deployment characteristics of the web platform combined with client-side performance. That's exactly what Hologram provides - it transpiles your Elixir UI code to JavaScript that runs in the browser, giving you instant interactions without server roundtrips while keeping the language and paradigms you prefer.
Binary distribution isn't technically hard in 2025, you're right. But "not technically hard" isn't the same as "optimal for every use case." Sometimes you genuinely want instant deployment, universal accessibility, and the ability to update your application without user intervention. Different tools for different jobs.
I'd actually love to hear what you think about Hologram's transpilation approach specifically - writing Elixir UI code that gets converted to JavaScript for client-side execution. Does that change the equation at all from your perspective?
Where does this Elixir lang rate in terms of performance against say Rust or Go? I noticed its run through a vm but also recommends itself for embedded?
Mail causes me to procrastinate so much, and I have no idea why. I use icloud everything, so I wanted my mail there as well, but after 12-13 months I switched back to FastMail because their UX is subtly better suited to quickly sorting through mail for me. And fwiw I'm afaik not using any FastMail features that Mail doesn't have.
I don't mean this in the way that Client A > Client B, but I have spent a fair amount of thought on this, and I have not been aple to pinpoint exactly what characteristics makes the difference for me, which I find to be interesting in itself.
My goal is always to have an empty inbox. So, emails that require some sort of action from my part but are not urgent I will snooze them (Gmail feature) to a later time. Email that's like "ok thanks for letting me know" and that's the end of that interaction, I will delete. Other stuff that requires more immediate attention I'll let it hang in the inbox for at most a few days and then try to act on them.
I noticed that letting mails linger in sight in my inbox is energy draining or causes me to procrastinate.
Last week I searched for an email in Mail.app. It was right there on the screen and it couldn’t find it. It also fails to display or even list some attachments.
This is unacceptable to me. Yet I keep using it because I dislike Gmail’s web interface and my Vim imap setup is not really usable yet and probably never will be.
Outlook has the same searching issue. I often have to resort to manually eyeballing through my email archives to find what I'm looking for. Very annoying indeed.
I've used many, many different clients over the last few decades (yes, including Linux `mail`). I have to use Outlook at work, and I have to use my providers' web clients on my Windows gaming PC, but on all my other devices I use Mail.app.
I just... don't ever use all the features of the other clients, or don't like some of the behavior they have, or any of that. For a long time I would get excited about new email clients and try them out right away, but no more.
I dunno if it's just that I'm getting old, or if I just don't care as much, or both, or something else.
I use many features of Thunderbird. And it works fine with outlook, even including calendaring, with the Owl plugin. It is a paid plugin, but it makes life much better.
Indeed, I'm additionally using https://mimestream.com for company Gmail as the Gmail support in Mail.app is sometimes a bit lacking (Labels etc.), but it's also a good way to keep private and work emails separated.
I feel you. I now just use email in my web browser via the respective providers recommended website, aka mail.google.com, microsoft.office365.exchange.email or whatever it is they are calling it these days.
I just wish that Mail.app would have a seamless ingegration with Calendar.app like Microsoft already provides with Outlook. Also the label system feels very outdated compared to Outlook.
I'd argue that the risk of your own instance being inaccessible for whatever reason is significantly higher than GitHub or GitLab having a full outage.
Polish (personal) computing industry definitely had a great – and, sadly, largely wasted – potential, however Odra is the worst example to prove this point. A poster child of the Polish "engineering thought" in the 70s was K-202[1], whose creator's tragic story shows how the dreams of the "Polish Silicon Valley" were defeated by the communist reality.
Exactly. Generally the best athletes have very high max HR and low resting HR but by measuring how quickly and how low your HR goes back down after an exercise is a decent indicator for stress, overtraining etc.
If your normal rHR is 55 but it only goes back down to 90 after exercise it most likely shows that you are untrained, stressed or overtraining.
All good, but without being actionable they're just vanity metrics that only get discussed during performance reviews. They don't provide any meaningful insights on how to improve actual performance in day-to-day work.
