Electron

Thank you for the feedback, everyone! I especially appreciate that you compared our 1Password 7 and 1Password 8 memory usage and performance.

I am not sure it is a fair comparison because there is a lot more happening in 1Password 8, compared to the older version. The app is running as multiple processes and the frontend is designed to know as little as possible to stay secure. For example, the frontend part of the application does not even get the password value until the user clicks the "Reveal" button.

Still, we want the app to be a good macOS citizen and will do everything we can to make it happened.

Thanks to one of the reports today, we found that the Rust backend is using too many threads and will try to make it better.

Don't forget, this is a very first public beta build of 1Password!

roustem - thank you for confirming - but what about the other fundamental issues with the front end - the fact that menus won't extend beyond the initial render window - the delays in rendering?

I don't really understand why you felt the need to change things so much - we pay for a great service and above all a truly native App experience, from what was formerly a Mac first company. Using Electron is a betrayal to so many of us. What on earth possessed the development team to use it? Surely anyone can see that in terms of raw functionality, it is not as 'native' as 1P7?

I'd rather the front end knew more about the passwords themselves if it meant we could avoid this ridiculous mess of electron.

gussic I haven't seen any performance issues myself, in fact the app feels faster to me compared to version 7. However, you are the second person today who mentioned the performance issues and we want to track them down. Can you tell us more about your Mac model, hopefully we could recreate it in development.

Re: Electron. You make a good point there and I will make sure we have a good description of how we ended up here. Long story short, for over 6 months we had the internal builds with frontend in both SwiftUI and Electron and we simply couldn't get the SwiftUI version to have the same polish and performance and still ship the apps this year.

Some people on Twitter simply dismiss the app as another "Electron" but we have more Swift code in the repository than TypeScript/React.

gussic about frontend knowing more.

The app does a lot of things you wouldn't want to have a vulnerability that could lead to access to your unencrypted data. For example, at some point, in 1Password 7 we found a problem that could lead to vulnerability while displaying the Markdown-formatted notes. The problem is fixed today but this kind of problem would have much less impact in 1Password 8.

roustem Thank you for the reply.

Oh the App itself feels faster than 1P7, I don't think many are disputing that, but it is a massive resource hog in comparison. Furthermore, the new Browser extensions are also heavier than the outgoing ones - what was once lightweight, and super fast is now not the case.

What about the issues with Electron's usability, having menus that won't display beyond the rendered window (as a post above provided screenshots for) I know these things seem little, but they are really jarring. I think we'd have all preferred less polish, but SwiftUI and taken the jankiness that might have meant. Alternatively, delaying shipping the Apps until next year would be much better, if it meant Electron was not used.

I appreciate this may not be a typical Electron App, as twitter suggests, but you know you have a large number of proud macOS users, did you really think this change would go over well? I'd happily take a regression back to 1P7's speed if it meant we could avoid Electron at all. Please don't take this the wrong way, but using Electron is lazy, other methods might take more time and money, but they would have worked much better for us, the end user.

RE: Mac models - 16 inch MacBook Pro (i9, 16GB RAM) and a M1 MBP with 16GB UM.

roustem thanks for the information about the front end. I'd posit that we'd all happily trade in markdown formatted notes if it meant we could get rid of Electron, and go back to a more native feeling App.

gussic I agree about the browser extension. I am not sure what is happening with the memory usage there, it would have to load all items in memory to decrypt them and find the matches but it feels that it is doing more than that. We'll need to debug it.

You might be happy to give up Markdown notes but others might not :) Also, it is not just Markdown, rendering things is a complex task and it is nice to have it in a separate process.

Re: delaying the release. It is not ideal because we also have to keep updating 1Password 7 at the same time until we have the new version available to everyone (and it still might take another year for the users to migrate). Still, we discussed the idea but there was a separate issue because the SwiftUI is limited to newer version of macOS and it means that we still need a fallback for the users on older macOS. The fact remains that the most important functionality is done in the Rust code and the frontend can be replaced when/if there is a better alternative. We'll see how far we could take the current solution.

roustem Re the browser issue - why step backwards then, and make it so resource hungry? Why not keep developing a lightweight BE for those who have the desktop version installed? Yes it costs more for you to do, but its better for the user (I note subscription fees haven't reduced).

Regarding the front end again - can you please explain, on what basis do you think it is a good experience to have menus cut off by the render window? Surely no one in your team thinks that's ok? Can you please explain why, despite knowing macOS users general distaste for Electron based apps, you went ahead anyway, you must have known this wouldn't be popular, you can literally see for yourself that it is a regression in terms of UI experience?

gussic I think we could make the browser extension behave better. I'd love to make you happy but at the same time I don't agree that implementing something in multiple ways is a good approach. It makes things more complex, there will be more bugs, and it will use more memory.

roustem I agree with the more bugs part, but the more memory part I do not agree with. I am looking at the memory comparisons between 1P7 and the bundled safari extension, vs the new one, the new one uses significantly more memory.

Back to the front end - can you please answer the question, re menus being cut off by the render window? Surely you can see this is not a good look, irrespective of the 'Alpha' nature of the App? My understanding is you can't fix this - menus can't extend beyond the render window?