Live data from Hacker News

Migrating Slack's Desktop App to BrowserView

slack.engineering

81–90 of 214 posts

Re: Migrating Slack's Desktop App to BrowserView

#81
post #38

Earlier quoted context omitted.

That's why I'm developing eul, a lightweight native desktop client for Slack, Skype, Facebook etc: https://eul.im It's only 4 MB and handles tens of thousands of Slack messages in one chat without lag. 1.0 release is going to be out in early November.

One thing that concerns me about any 3rd party chat application is that it's difficult to know if my data is secure. Any thoughts on open sourcing your application?

Yes! I want to make it open source, from my experience that's the best option for all parties. Unfortunately it won't be possible to open source some parts of the app.

I'm setting up a company right now to increase trustworthiness. Like the home page says, no data will ever be shared with anyone and soon it will be possible to verify this.

Re: Migrating Slack's Desktop App to BrowserView

#82

As a Linux laptop user, I fully endorse Electron. There’s so much more available for Linux because of it that would have no client at all otherwise. Between NVMe disks and the ability to have 64gb of RAM if I want...keep it coming. I’d rather have heavy software than no software.

Why? Electron apps still have to be packaged for Linux. And cross platform apps can be written in Qt or Java too. Doesn't seem like Electron is the thing making the difference here.

Re: Migrating Slack's Desktop App to BrowserView

#83
post #7

Earlier quoted context omitted.

When these kinds of things come up there's often complaint that desktop apps running in the browser are inefficient. As it happens, I agree. An old favourite of mine, Adium, probably never used 600 MB because I'm pretty sure my PowerBook G4 had less RAM than that. But I think it's a mistake to jump to the conclusion that these apps should be written in a native framework rather than a web view. Slack is doing much mo…

That's why I'm developing eul, a lightweight native desktop client for Slack, Skype, Facebook etc: https://eul.im It's only 4 MB and handles tens of thousands of Slack messages in one chat without lag. 1.0 release is going to be out in early November.

How are you writing it? C++?

Re: Migrating Slack's Desktop App to BrowserView

#84
On macOS, web app wrappers created with Fluid (http://fluidapp.com) consistently use less resources than the official Electron-based versions, in my experience.

It's a wrapper for the system-supplied Webkit, so it inherits those benefits from that. I've been experiencing a similar performance to Chrome in Safari 11, but lower RAM/CPU/GPU usage overall.

Re: Migrating Slack's Desktop App to BrowserView

#85

As a Linux laptop user, I fully endorse Electron. There’s so much more available for Linux because of it that would have no client at all otherwise. Between NVMe disks and the ability to have 64gb of RAM if I want...keep it coming. I’d rather have heavy software than no software.

Ah yes, let Windows and macOS users suffer from garbage so you can have "much more available for Linux". The year of Linux desktop is upon us.

Re: Migrating Slack's Desktop App to BrowserView

#86
post #53

Earlier quoted context omitted.

That's why I'm developing eul, a lightweight native desktop client for Slack, Skype, Facebook etc: https://eul.im It's only 4 MB and handles tens of thousands of Slack messages in one chat without lag. 1.0 release is going to be out in early November.

Sorry, but it doesn't work for me at all. When I try to add a service, I get the login screen for few seconds, and then the whole window turns gray and I can't type anything, the only thing I can do is to close it. Tried several times with different services. Tried macOS version on High Sierra.

That's weird. What's your hardware?

Re: Migrating Slack's Desktop App to BrowserView

#87

Earlier quoted context omitted.

That's why I'm developing eul, a lightweight native desktop client for Slack, Skype, Facebook etc: https://eul.im It's only 4 MB and handles tens of thousands of Slack messages in one chat without lag. 1.0 release is going to be out in early November.

How are you writing it? C++?

Go

Re: Migrating Slack's Desktop App to BrowserView

#88
post #7

Earlier quoted context omitted.

When these kinds of things come up there's often complaint that desktop apps running in the browser are inefficient. As it happens, I agree. An old favourite of mine, Adium, probably never used 600 MB because I'm pretty sure my PowerBook G4 had less RAM than that. But I think it's a mistake to jump to the conclusion that these apps should be written in a native framework rather than a web view. Slack is doing much mo…

That's why I'm developing eul, a lightweight native desktop client for Slack, Skype, Facebook etc: https://eul.im It's only 4 MB and handles tens of thousands of Slack messages in one chat without lag. 1.0 release is going to be out in early November.

"Native" does not just mean "use the native toolkit" or "write in non-web tech". This app looks nothing like macOS or Windows apps. Most likely, none of the features users are accustomed to will work.

Re: Migrating Slack's Desktop App to BrowserView

#89

Earlier quoted context omitted.

That's why I'm developing eul, a lightweight native desktop client for Slack, Skype, Facebook etc: https://eul.im It's only 4 MB and handles tens of thousands of Slack messages in one chat without lag. 1.0 release is going to be out in early November.

"Native" does not just mean "use the native toolkit" or "write in non-web tech". This app looks nothing like macOS or Windows apps. Most likely, none of the features users are accustomed to will work.

True, but it will get better with time.

Re: Migrating Slack's Desktop App to BrowserView

#90
post #78

Earlier quoted context omitted.

I think, that he was trying to say, Typescript feels like C#, so why not use the more performant option, if you use something similar but slower anyway.

I don't know if TypeScript is the culprit here. Just look what Microsoft pulls off with VSCode.

I didn't look into the JS TypeScript compiles to, but I saw some output from Reason/OCaml and it looked much more streamlined for performance than what I would write in JavaScript myself. Much more use of integers than strings etc.

So I could imagine that compile-to-javascript languages could get you much faster apps than traditional JS.

Post reply on HN