eul is a very lightweight and fast native desktop client for Skype, Slack, Gmail, VK, FB, Jabber, Telegram, and Signal. Right now only the first four are supported, and the rest should be done by the end of August.
Why did I create this? To solve two big problems I see with the current IM solutions: there are too many of them, and the clients are ridiculously bloated for what they are built to do. For example, everyone knows what a huge resource hog the Skype client is. Even the Telegram client, which is supposed to be lightweight, is using 1.3 GB of RAM on my desktop right now.
I'm obsessed with performance. The entire application is about 4 MB, and it's never going to be more than 10 MB. In fact there are still many things to optimize. It's native, so you don't need to download a 100 MB browser just to use your IM client.
eul can display thousands of messages in one conversation without the constant page fetching. The scrolling is instant and smooth. You can jump to any message without waiting. I've tested it with 50 000 messages in one chat. No lags, instant scrolling to any point, instant search. That should be enough for most :)
This is a very early alpha release. A lot of essential features are still missing (for example, images and other attachments are not supported yet). Automatic updates will be released every day. There's a built in contact form, please use it to submit bugs and suggestions.
- THANK YOU! It's near impossible to find a client that isn't either run in a console (admittedly not the worst problem) or horribly bloated (what the hell are people thinking when the bundle a browser to show a single page!?).
- What do you think of adding Matrix (https://matrix.org)? The protocol is HTTP + JSON based and well documented.
- Have you thought about open sourcing? My guess is either you want to sell this eventually or your coding standards are quite high and you doubt people can contribute too much while meeting them. In the case of the latter, I'd still like for it to be around, even if your standards for PRs would be too high for me to meet.
I have to agree about matrix. In fact I think at this point effort should be focused on bridging protocols to matrix instead of each different client implementing support for protocols by themselves. Then the client can only implement matrix support.
> I'm obsessed with performance. The entire application is about 4 MB, and it's never going to be more than 10 MB. In fact there are still many things to optimize. It's native, so you don't need to download a 100 MB browser just to use your IM client.
The in browser Slack is getting slower each day. If I don't do a full refresh of the page after about an hour, the interface is so slow that even typing text is painful.
So having a lightweight client is definitely appealing to me. However Slack keeps adding features often and every one using Slack assumes the recipient runs the same version of Slack as his.
I wonder how can your unofficial client can deal with this problem the next time Slack releases the next update that is as big as adding threaded conversations for example.
My coworkers and I have been looking for something exactly like this, and we've been let down by numerous Electron projects like Franz that don't really offer any different, simplifying experience.
I will definitely be trying this out.
However a question essential for our pending use is: any plans to support HipChat? That would pretty near seal the deal for my current group.
Eul's target audience is primarily professionals, so it's silly of me to forget about HipChat. I just had a look at its API, and yes, it will absolutely be supported. In fact, most likely this is going to be the next protocol implemented.
Hi again! That's great news. I passed the app around to my coworkers already, however we can't actually use it!
If it's at all possible, we'd love to have a build compatible back to macOS 10.10. Right now, it can only run on 10.12 and we work in a large enterprise where updates are withheld for mostly software-compatibility reasons (a lot of media software relies on older systems).
Nice idea. FYI I just tried it on my Mac (10.12.5) with Safari as a default browser and Safari crashes every time it's opened to do the login to any service. After a couple try also eul crashed.
- This is a native application, but does not use any native controls, so currently lacks text selection or navigation, tab to change input focus, or anything else you'd expect from a native application (apart from speed). One of the things that bothers me most about the Slack application is it's lack of interoperability with macOS, for example in drag and drop - this application does not appear to be targeting that interoperability either.
- Slack authentication doesn't appear to be working at the moment - it directs me to my browser to authenticate, but after doing that I'm left in the Slack web-app, not redirected back to the application.
Is it possible to fix the scale factor for Linux desktop hidpi display? It doesn't seem to pickup system global setting for the display. Does it use GTK on Linux or what is it using otherwise?
Hey - I wanted to give you a BIG thank you for creating a native / non-JavaScript client for this, JavaScript (no matter the framework) has been the death of me and my peers with regards to desktop ‘apps’ for the last few years and it’s so damn good to see someone stop, think and give a $#!+ about performance. I’ll add that the last thing I (and I’ve heard my team say the same) want is another app that has to run in a web browser.
When I get to work tomorrow I’ll be trying this out (knowing it’s in beta) for XMPP / Jabber, if it doesn’t already support OTR encryption - that’d be a killer feature. A big problem I see is that a lot of places want to or do run internal XMPP/Jabber because they have engineers working that don’t want to / can’t run ‘enterprise’ rubbish like Skype or those of us that are sick of JavaScript heavy SaaS apps like slack - but then you’ll have a few managers or project managers that still run Windows likely for excel or out of habit etc... and they have to use Pidgin - which while it works across a lot of IM systems - is very awkward and ugly as anything, so it gives the better protocols a bad name, on Mac there’s Adium which is a pretty decent multi-IM client but has stagnated somewhat. So a clean, easy to use, stable and well performing chat client that supports XMPP/Jabber with MUC and OTR would be an absolute killer.
There is no mention of this supporting XMPP, but I use profanity for XMPP, and love it. The fact that it's a console application may or may not suit your tastes, of course.
Even without defender activated, the fact that the binary is not signed is triggering windows 10 security. Not an issue for me but you might want to sign the binary to avoid this.
Win32/Lineage[0] is a bit of malware (or perhaps a characteristic of malware) that steals credentials. It looks like other software has had false-positives for this before (i.e. optipng[1]). You can also submit eul as a false-positive here[2].
I appreciate all these new clients with some interesting twists, but I would appreciate more if people spent at least a relatively small portion of their time contributing to existing (very good and solid) messengers like Pidgin, instead of re-inventing the wheel. Every now and then, someone hacks a new client, which begs the question about the value of that effort.
amazing, i always wondered why people don't create more GUI stuff with Go, the performance of Go is pretty nice and a lot of good multi platform desktop apps could be build using it, keep up the good work!
This looks great - the Slack app is a massive PITA because it's so slow. The only thing stopping me junking Franz for this is that Franz has whatsapp (which you probably can't integrate into Eul anyway because it has to be the web client).
I find this interesting, as I've been toying with similar ideas in head. In particular the messenger / facebook side of things is of great value to me. However implementing and more importantly maintaining support for this protocol seems like something which will require a vast amount of time and work. Could you briefly describe the status of this support and what hurdles there are to overcome. Messenger used to be XMPP right, I remember and miss the time when you could use pidgin to access this particular service!
Please do consider paid version and/or donations to sustain the development. I'd pay for a fast native app for Slack and others but I also know these services would change over time and it would be nice to get updates.
There already exist tons of high quality irc clients, so there's no reason for irc support to be high priority. I see eul's reason to exist to be more to alleviate the weight of having several low quality messaging apps open at the same time.
IRC is still very active in certain circles, though relatively few these days. Many open source projects have channels for discussion and support for example.
#blender and related, the freenode community is still very active for real time support for many projects.
I think IRC still could have a great place in the world - decentralised, open, etc. The ui is just very expectant that you already know and understand the ecosystem.
Needing to know user /auth stuff happens by sending private messages to bots, and other insane hacks.
I am most likely going to open source it, so you will be able to build your own version and control everything.
For now I guess you can only monitor the traffic with a tool like WireShark and see for yourself that eul only fetches current version for the autoupdates and submits error reports.
Mattermost is the open source Slack alternative, right? I haven't considered these smaller projects yet, because there are a lot of them. Implementing new protocols takes time.
There are still a lot of crucial features I need to implement, but after eul is out of beta, Mattermost support should be there.
I understand it's early in the project and you are still nailing things down, but please consider open sourcing your project. Not being able to support things like smaller protocols (Spark, MS Teams, etc.) and legacy platforms (IRC) go away when others have the ability to contribute. Don't get me wrong, nothing comes for free and managing contributors is often times very difficult. Regardless, I think it's worth it. Plus, being able to see the source and build it ourselves is very important for this type of security sensitive project.
Thank you for your effort and I'm looking forward to using Eul quite a bit in the future. :)
This is pretty stupid. Dev machines come with at least 8 gb or ram, why would anyone run a closed source software to save a hundred megabytes and risk compromising their machine. Meanwhile the account is 1 day old and the exe is being flagged by antiviruses.
Security concerns with this particular project aside, my dev machine does indeed have 8 GB of RAM, which Slack alone readily consumes 1/8th of whilst also using 15% of my total CPU power at rest, doing nothing at all.
There is no excuse for this - it is shoddy engineering. Sending text messages is a simple task. Ruining my battery life and performance for the sake of making it easier for the billion dollar company to ship a cross platform app which feels wrong on every platform is something I despise and I for one am extremely happy that people are trying to counter this ridiculous trend.
I'm saying this as a past user of slack and knowing that this doesn't help, but if they can't keep their frontend solid we can probably surmise their backend is just as shoddy, so we shouldn't be using it, no matter what client we choose to use.
What a ridiculous comment.. I can assure you that the majority of the developers do not own a 8GB dev machine, and surely you can see why this application would be valuable for the average user chatting with their friends on Skype/whatever on their 2GB, i3 laptop (assuming they're lucky enough to be able to afford such a device).
I have browsed Show HN every day for over a year now, and I can't think of any project that made me as excited as this (although https://github.com/google/xi-editor and https://github.com/limetext come close). I bet that almost every Go developer on HN would love to read, study and learn from his code, so how about we ask him nicely instead of attempting to attack his credibility in hope of pressuring him into releasing his source code..
His credibility is already at 0, because he's an anon.
> in hope of pressuring him into releasing his source code..
Not my hope, I don't even install official slack client because I don't trust it to be built by competent people (it's web app for me tyvm), my hope is that everybody who installed this software formats their hard drives for the sake of other people if not for themselves. How do you think things like this http://www.nbcnews.com/id/15316394/ happen?
With you here. I don't really care how much ram something uses as long as it's fast. Biggest problem I have are all these "native" apps just being electron wrappers. I miss the old days of real chat apps. Unfortunately they've all gone to hell - looking at you trillian.
I think RAM usage is important. My machine only has 8 GB of RAM, and I had to quit Telegram (1.1 GB) and Skype (550 MB) every time I launched a virtual machine to compile eul for other platforms :)
Someone is this thread mentioned windows defender and I checked with virustotal where there are some others as well. These might all be false positives, even then it still seems wrong to run a random executable from some anon from the internet.
Here's why I don't use Tox, the executable are provided by a bunch of anons and while I could compile the code myself I'm not really bothered, especially because I can't force everybody to do the same. I like my software to have some collateral, usually it's either someone's good name or their company. On the other hand, I can't find anything about you, your records show you live at Pobedi (victory) 112, 84, Moscow. Really?!
Thanks for pointing that out, I need to update whois data. I'm using an 8 year old throwaway name registrar account, because my primary registrar doesn't support .im domains.
I should get the code signing certificate by the end of the next week.
eul is a very lightweight and fast native desktop client for Skype, Slack, Gmail, VK, FB, Jabber, Telegram, and Signal. Right now only the first four are supported, and the rest should be done by the end of August.
Why did I create this? To solve two big problems I see with the current IM solutions: there are too many of them, and the clients are ridiculously bloated for what they are built to do. For example, everyone knows what a huge resource hog the Skype client is. Even the Telegram client, which is supposed to be lightweight, is using 1.3 GB of RAM on my desktop right now.
I'm obsessed with performance. The entire application is about 4 MB, and it's never going to be more than 10 MB. In fact there are still many things to optimize. It's native, so you don't need to download a 100 MB browser just to use your IM client.
eul can display thousands of messages in one conversation without the constant page fetching. The scrolling is instant and smooth. You can jump to any message without waiting. I've tested it with 50 000 messages in one chat. No lags, instant scrolling to any point, instant search. That should be enough for most :)
This is a very early alpha release. A lot of essential features are still missing (for example, images and other attachments are not supported yet). Automatic updates will be released every day. There's a built in contact form, please use it to submit bugs and suggestions.
Looking forward to hearing your feedback :)
Thanks