Hacker News Reader

>Electron suited us perfectly, since we could write our UI code once and make it consistent across Linux, Windows, and Mac.

This is the source of your mistake. Users don't desire to have the same UI across different OS environments, it's only an app's developers that care about that. Cross-platform UIs are inarguably a worse user experience than UIs tailored to the conventions and designs of each OS.

A Mac app that doesn't actually feel or behave like a Mac app is not a good Mac app. The same is true with tvOS apps like YouTube and Prime Video that don't actually feel or act like good tvOS apps.

I wholly agree with this, I choose Macs and use basically exclusively "good" Mac apps since I want everything I use to just feel right. On the occasion I use Windows or Linux, I want the UX to feel akin to what other applications on those platforms use.

Kinda a random thought, but is it at all possible to build a native 1Password app using their API [1]? I haven't read Agile Bits' ToS, but I would be interested in working on / following a Mac-centric client.

[1]: https://support.1password.com/connect-api-reference/

> Users don't desire to have the same UI across different OS environments

Um, speak for yourself. I personally don't like having the docs showcase completely different UIs to the one I'm using. I also like having an app i can run on Linux, which has been happening a lot more since Electron became a thing (no sane company wants to write apps in GTK, and much as Qt is a great toolkit it requires expertise most SaaS vendors don't have).

You're speaking as if it's fait accompli that 1password made a mistake picking electron. It is not, and I am fairly certain they did not.

There's an argument to be made the other way around:

Maybe if you choose to use multiple platforms you should just deal with the multiple approaches to UI? Why should the single platform citizens suffer from a UI that's inconsistent with the rest of the platform?

To stretch it to an absurd case:

Imagine Slack decided that the shortcut to copy text will be Ctrl+C on all platforms. And Windows users who occasionaly use a mac would rejoice because it would save them from having to think which button to press.

What percentage of users will be using the app across multiple operating systems and notice and prefer having a consistent interface?

Anecdote, but, my workstation is Linux, my work laptop is macOS, my personal computer is Windows where I run Linux VMs. I run 1Password across all these operating systems. Having a consistent interface is nice and it means I don't have to relearn the UI three times.

I think many people here will have a similar setup but that isn't representative of the general population or probably even 1Password's client base.

I feel like you didn't read my comment if that's your take away.

> Users don't desire to have the same UI across different OS environments, it's only an app's developers that care about that.

I guess we'll have to agree to disagree on that. I personally enjoy having consistent user interfaces across the apps that I use, and there are many other people that would say the same, so I would avoid making broad assumptions. From our perspective, consistent user interfaces are a win-win for both the development team and the majority of end users. That being said, I'll take your feedback into account.

This is a curious response. I would have used the same reasoning as an argument against Electron (or similar unified development systems): they are not consistent with all of the other native apps that people use.

I don't know if your reasoning is that looking like a web app means it is consistent with those apps, or that the apps look the same across platforms, but neither of those arguments are compelling to me. I chose the platform I am on because I think the interface is a good one that makes me more productive.

And I have never found an Electron app (or web app in general) that is as high quality as good native apps (on any platform). There are just so many compromises, and I am not even considering resource usage here. Everything just feels a little slip-shod.

This comment reminded me of a Gruber blog post from a few years ago

https://daringfireball.net/2018/12/electron_and_the_decline_...

Thank you for that well-written explanation of your concerns. Your frustrations are shared by many users in this thread, and I'll do my best to pass them forward to the rest of the dev team.

This comment is so well written

> I guess we'll have to agree to disagree on that.

This is such a bizarre claim. I know Agilebits understands Mac users.

To be brutally honest, I've heard this line from a lot of software shops after they decide tailoring their apps to the native platform is too expensive or inconvenient for them. Suddenly they all find that their users don't care about their native platform - I suspect if I went looking for the discussion from back when Adobe did this, I'd see the same phrasing.

I canceled my subscription today.

> I guess we'll have to agree to disagree on that.

Let's be clear about this: you are the seller, we are the customer. You can't `agree to disagree` with your customers.

If you don't agree to what some your customers are telling you, then they won't be your customers, and you won't lose just these customers but also all the others who observe your behavior. It is a modified case of repeated prisoner's dilemma. If I observe that you tend to defect on other instances, I will less inclination to cooperate. In other words, your reputation will suffer.

On the consistent user interfaces, the consistency of an app with other apps on the same platform is much more important than the consistency of that app across platforms. Even if you use multiple platforms, you switch much more frequently between apps on the same platform than between different instances of one app across platforms.

I don't have super strong feelings about native v.s. cross-platform UIs, but I think I (and maybe others) think about this question from the "reverse" direction. I expect a given service / app / functionality to work the same everywhere, no matter the platform. This is true of tools I use through my terminal or tools I use in GUIs. Other approaches feel to me like they make using the product more difficult - I may not be able to help someone else on another OS use it, it may mean that an obscure platform has more bugs than a unified approach, etc. I understand why native may make sense, but I do not think it is a given.

But how can you justify removing the ability to have a local vault?

Why would anyone think for a second that it would be a good idea to force people to store every password for everything in their life in your cloud without an opt out?

That, even more than Electron and the subscription model (both which do bother me), is an absolutely deal breaker. I've paid for every version of 1Password since v3 in 2009, but I'm done with it now.

The original article goes into great detail as to why we're moving away from local vaults.

That being said, we are looking into gauging user interest in self-hosting. Please take a look at our survey [1] if you want to share your thoughts. Hope that helps!

[1] https://survey.1password.com/self-host/

I don't want self-hosted, and I definitely don't want subscription based. I, 1Password user for many years, want the local vaults!

1Password 6 is great, and I'll keep using it until it quits working on my devices, but no more after that! I used to recommend 1Password so much to people it was borderline evangelizing, but I quit recommending it once the subscription was pushed over the other options, and now that local vaults are going away I'm actively recommending against it to anyone that asks.

Guess I'll be moving to Bitwarden or Keepass myself; time to research!

Word for word my response as well. I've never had a product go from beloved to this before.

May just want to stop before you step in things further. You’re honestly just making things worse.

You're taking a survey about not removing a feature you already have? Why not just keep it?

This would be an appropriate riposte to [1], a vitriolic comment that draws the line between VC money and Electron, but not to parent.

Parent makes a lot of sense, actually, in context of the submission headline. There was no misinformation here at all.

[1] https://news.ycombinator.com/item?id=28145755

Thank you for pointing me to that thread. I'll make sure to respond there as well.

I did (incorrectly) assume that the parent was talking about Electron, so that's my bad. That being said, our decision to move away from licensing is absolutely not being driven by VC funding, so the parent comment is also spreading misinformation. We were building a subscription-based model all the way back in 2014, and we're phasing out licenses for the host of reasons that were mentioned in the original article.

In my experience the impact of VC money isn't directly seen by engineers but is rather a subtle top down shift in direction. Growth matters more, revenue matters more, existing users matter a bit less versus future users, features that impede this are removed, etc. Feature direction shifts slowly but surely.

The goal of a VC company is to either grow big or die. That's it. Risky bets at the expense of existing users are expected if current growth does not meet expectations. Worst case everyone quits the app and you go bankrupt. VCs expect that 9 time out of 10 so no big deal as long as the 10th makes it big.

Hi, I didn't mention Electron in my comment, it was purely about the move to remove single time purchase and local vaults. I don't like the direction where the product is heading, therefore I want out.

Question: you built it in Rust for performance reasons, right? Wouldn't Electron take it away?

The short answer is no. People often have misconceptions about Electron apps based on their experiences with a poorly written one. I've had my own fair share of bad experiences with Electron-driven apps. But the way we've utilized Electron is far different than most applications.

Our Electron app is really only a thin client over a Rust-driven backend that handles all our business logic. We only invoke Typescript when we need to render the UI; everything else goes through Rust. We even run some Swift code too, for deep integration with the operating system.

Memory is still an issue with Electron, but we're getting better at reducing the footprint. We've put a lot of work into optimizing this app, so I recommend you give it a shot; I think you'll be pleasantly surprised by how performant and responsive it is.

> People often have misconceptions about Electron

> Memory is still an issue with Electron

Sounds like their conceptions are correct.

This is pretty much the main point that people bring up. Followed by UX experience.

My work Slack dies at least once every day, and makes my laptop scream if I have VS Code on. I don't want to know what adding 1Pw will do.