34 ms·

Show HN: Wey – A fast, open-source Slack desktop app

277 points by zcbenz 9y ago

faitswulff 9y ago
> While Wey currently only supports Slack, it is on roadmap to add support for more services, and in future we will support plugins to add arbitrary services. This is actually a Slack client, then?
PrimeDirective 9y ago
How is this better than the official web client and why would I use it? It's not really "native", either.
- wlesieutre 9y ago
  It can be not native and still lighter-weight than electron
- bartread 9y ago
  I would guess it uses less memory: it claims generally <100MB, although in my opinion that's still a ridiculous amount of memory for a desktop IM client to use. Still, it's better than 800MB.
  - PrimeDirective 9y ago
    A bit off topic but yes, these days "native" apps tend to be memory hogs. Modern computers have tons of CPU and memory which makes the developers lazy, it would seem. Generally, noone optimizes their desktop clients.
    - corrigible 9y ago
      Telegram is amazingly smooth on Linux and Windows.
      - chocolatkey 9y ago
        Because it has a real native backend. It uses Qt/C++. I really wish other chat apps would do it...
    - benplumley 9y ago
      I've had Telegram, Slack and Discord open all day. Currently, they're using: 7MB Telegram, 350MB Slack, and 140MB Discord. Other heavy things I've got running are 160MB Spotify (which is electron) and 1GB Firefox (which is doing actual work with its memory).
  - e12e 9y ago
    Meanwhile weechat w/wee-slack is lightweight. I do miss a richer (g)ui though - the standard console setup tends to break urls. And I haven't figured out if weechat supports soft line endings for eg: posting code snippets as a single (slack) message. Maybe at some point I'll find the time to revisit qweechat and see if it might be possible to strike a better middleground between "it's just chat" and all the fluff slack adds.
    - meroje 9y ago
      Are threads still all over the place in wee-slack ? Last time I used it was impossible to follow a channel with multiple threads going on, let alone reply to one.
      - e12e 9y ago
        Fwiw i think threads are all over the place in slack (for Web) too. That said, a thread can be moved "out" to a buffer, and you can apparently rename them if you want/need to: https://github.com/wee-slack/wee-slack/blob/master/README.md#threads https://github.com/wee-slack/wee-slack/blob/master/README.md... Still sucks, but better than the Web client IMNHO.
  - jiveturkey 9y ago
    800MB? Is that for the Linux or Windows client? My mac client is consuming 77.0MB per activity monitor. Which I assume on Mac is power of 10, so 73.4MiB.
    - bendiksolheim 9y ago
      That is probably the main process. Slack has one process per team. I am currently running at 1.4GB on my Mac with 6 (relatively small) teams.
- mistermann 9y ago
  Perhaps it might show you not only new messages across your workplaces, but also a way to actually read those new messages without loading (and waaaaaiting) each one and hunting for them. Don't know if it does this, just complaining about the official client on Windows.
- nvr219 9y ago
  It's faster
simon1573 9y ago
How does this compare to Franz? https://github.com/meetfranz/franz https://github.com/meetfranz/franz
- hs86 9y ago
  Franz launches a completely new instance for every workspace/network that you add and these are based on their regular webviews. Unlike Slack, it will not unload less frequently used workspaces from your RAM and with 8 Slack workspaces, Telegram, Whatsapp and IRCCloud it managed to permanently allocate more than 3 GiB RAM. That may be fine on my beefy desktop PC but not on my MacBook Air with only 8 GiB RAM. In my case, just leaving the official apps of these chat networks in the background seems to be less resource intensive than running Franz. I really hope that https://eul.im/ https://eul.im/ will up to my expectations.
  - gmemstr 9y ago
    I'm still really leery of eul.im, I can't seem to find anybody reviewing/actually using it and it throws up a couple detections on VirusTotal. Would be interested to hear of your experience.
    - amedvednikov 9y ago
      Hi, developer here. I just tested it on VirusTotal and didn't get any detections. Could you please post a screenshot with what you get here or contact me via support@eul.im? Thanks
      - gmemstr 9y ago
        VirusTotal link: https://www.virustotal.com/#/file/e88753917d7283715f0a4c633ea9f6740b38dd0fed3419a3ee03bcc84357185b/detection https://www.virustotal.com/#/file/e88753917d7283715f0a4c633e... Screenshot: https://i.imgur.com/X60nnAT.png https://i.imgur.com/X60nnAT.png I'm excited to try it but because I'd be using it for sensitve/confidential work I don't want to risk it unfortunately.
      - 9y ago
m0meni 9y ago
This is pretty cool. From just reading the repo, it's built on this library I'd never heard of before called Yue[0] that seems to be similar to electron, but more lightweight. [0]: https://github.com/yue/yue https://github.com/yue/yue
- opencl 9y ago
  It's not similar to Electron at all. Zero web technologies involved in it, other than supporting JS bindings. Far more like Qt/GTK except trying to use native widgets as much as possible. The Linux support actually is GTK, but MacOS/Windows use the vendor UI libraries.
  - bpicolo 9y ago
    What's the bit about using electron in the JS bindings docs? http://libyue.com/docs/v0.4.0/js/guides/getting_started.html http://libyue.com/docs/v0.4.0/js/guides/getting_started.html
- godot 9y ago
  https://github.com/yue/yue/graphs/contributors https://github.com/yue/yue/graphs/contributors It's also mostly created by zcbenz, the author of this project (Wey), and according to another commenter, also the author of Electron.
kodablah 9y ago
First time I'm seeing Yue [0]. Seems like C++ w/ some Lua and JS bindings. Are there C bindings available so it can be used in other ecosystems without writing C++ glue? Writing a lib in C++ is rough for sharing across ecosystems and I'd say is a reason Qt and wxWidgets aren't more widespread than they already are. 0 - https://github.com/yue/yue https://github.com/yue/yue
- frou_dh 9y ago
  Yue sounds similar to libui[0], which has numerous language bindings, but seems to be in long term flux in terms of scope. [0]: https://github.com/andlabs/libui https://github.com/andlabs/libui
maxehmookau 9y ago
Awesome! ...also kinda depressing that it's neccessary. Hey Slack! How about an app for your service that doesn't grind my macbook pro to a halt?
- SirensOfTitan 9y ago
  slack-term is pretty great, but mentions don’t really work wells.
  - MrQuimico 9y ago
    Humm, interesting, that looks more like a feature to me.
- rplnt 9y ago
  Disable emojis. Seriously, the animated emojis must be implemented with something like this while(true) { foreach(emoji) { emoji.refresh(); if (emoji.since_last_frame() > 1/60) emoji.next_frame(); } } Slack can easily eat up one core with just a few of them on the screen. Never seen that.
  - wccrawford 9y ago
    IIRC, the last update on OSX specifically mentioned that they were requesting the emojis way too often, and that it's now just doing it once.
seba_dos1 9y ago
Nice! However, looking at the screenshots... I wonder why developers so often seem to get UI paddings, margins and font sizes so wrong. Does it really need some special kind of sensitivity to notice and care about it? :)
- iaml 9y ago
  Unfortunately a lot of developers value aesthetic and polish somewhere deep down on the list of priorities and don't seem to comprehend that other people care a lot about such things.
  - pjmlp 9y ago
    It is ok, we cannot be an expert on all areas. My focus is on full stack, so I do care a lot about UI/UX, and improving my skills there. However don't ask me to do anything related to NoSQL or Deep Learning, I would be a lousy contributor.
    - oneweekwonder 9y ago
      > It is ok, we cannot be an expert on all areas. > My focus is on full stack, I'm sorry, imo those are two contradicting sentences. But it might be related to a personal pet peeve of "full stack" developers claiming to be expert in most moving parts of the stack. Only to post on medium this amazing db hack they found, to be called out in hn comments for not reading the basic docs of one of the core items in their stack. I always look at Doctors for a bad analogy; why full stack developer is a bad idea. Sure the heart surgeon will be able to diagnose your broken leg. Might even be able to assist you with a cast. But trust him to operate? There a specialist for that! Is this not the same for dev work? Designer, Developer split into 4 fields(desktop, mobile, frontend, backend), database admin, sys admin. All possible to be done by a "full stack" developer. But I don't see you become a specialist or expert in any of the fields of your stack, if you don't dedicate to a few.
      - pjmlp 9y ago
        Well, there is a reason why in some countries access to specialists is forbidden unless you are checked by a general physician first, the one responsible for being your official doctor throughout your entire life. He knows best than having people searching for specialist by themselves. As for myself, if you prefer a more descriptive example, I specialize in everything related to Java, .NET and Web (VanilaJS) stacks.
Wingwing 9y ago
This is madness. You can't solve every problem with a technological bandage. Spend the time making a nice IRC client.
rplnt 9y ago
It's insane that 100MB of ram for a "chat" client is seen as a good result. How did we get there? Is it really that much cheaper to develop desktop apps as slow and bloated web applications?
- Klonoar 9y ago
  Most people don't seem to grasp that in this day and age, any GUI program (at least on OS X) is going to be minimum 20MB due to the retina display. Add in that realistically you need to use Webkit (or some HTML renderer), at which point... 100MB is pretty good. For reference, an RSS reader I threw together using standard Cocoa widgets will hit 50-60MB with no issues, and that's with my being annoyingly judicious with how it's built.
  - zeveb 9y ago
    > Add in that realistically you need to use Webkit (or some HTML renderer), at which point... 100MB is pretty good. Why do you need an HTML renderer? Slack uses Markdown. emacs-slack is pretty lightweight …
    - verandaguy_alt 9y ago
      >Why do you need an HTML renderer? Because it's objectively easier to do cross-platform GUI development using a single, well-defined and portable API that someone else maintains. That that API is nowadays de-facto WebKit supporting a HTML/CSS/JS stack is a natural, but unfortunate choice, and it's got a much lower barrier of entry and much less maintenance overhead than, say, Gtk+ or Qt.
    - Klonoar 9y ago
      Slack uses Markdown, yes, but supporting everything under the sun that Slack does (especially as they add new things) is just much easier inside a Webview. The job of programming isn't to reinvent the wheel everywhere, it's just to deliver a product that doesn't suck - with native code, you're implementing a native solution for each feature Slack has or adds. Slack's content is web content. You're really arguing that an insane amount of extra engineering time should be spent to conserve, at best, an extra 40-50MB of RAM... and this is disregarding how modern RAM works anyway.
staticelf 9y ago
I kind of understand the need, but I would be more prone to actually use it if it was actually fully native. Now, I can simply just wait for Slack to update their client. I don't really get why I should use this instead of slack unless I run really shitty hardware, which I don't. I had issued with Slack before, but they fixed most of them. Also new features in slack will börk this app pretty quickly, as they have to be implemented for one to use them. Cool project though, even if I personally don't get the value of it. Maybe if they added Gitter, Rocketchat etc support so you would have one client to rule them all.
wuliwong 9y ago
I installed it, it seemed a lot more "performant" than Slack's app on OS X. The Wey app crashed within 5 minutes though. :( I noted that Wey only gives links to pictures with no previews. The linking out is fine but I think inline previews would be a nice addition down the road.
polpo 9y ago
Interesting to see this is from zcbenz, who was the initial creator of Electron. Slack's desktop app, which is based on Electron, is often criticized for its memory and CPU usage, so I'm wondering if the creation of Wey and its underlying Yue library are an answer/atonement for that.
- GoneToThailand 9y ago
  It is so damn ugly that I prefer to keep my fans spinning the whole day than looking to that every day.
- bb88 9y ago
  On the github page, he writes this: > Normally for multiple teams with heavy traffics, Wey should not have any significant CPU usage, and RAM ussage is usually under 100MB. However if you have a team with more than 10k users in it, the memory usage may increase a lot. Bloaty technologies was what made MS great in the 80's/90's, because 18 months later, the speed of the CPU would double. I feel like we should think hard about optimizing for memory/cpu again.
  - JustSomeNobody 9y ago
    Now that Moore's Law is dead, that time is coming. We can't afford to be wasteful. Not that we ever should have, but we've spent over a decade now catering to "developer productivity", now it's time to put the user role back in the forefront.
    - qznc 9y ago
      The last time I checked (roughly a year ago) Moore's law was still holding.
      - chacham15 9y ago
        Not sure why the downvotes. Moores law[1] refers to the number of transistors that are on the die. With the decreasing size of the transistors, this has remained true. Despite that, clock speeds have stopped growing thereby leading to serial performance not increasing as fast as it had in the past. [1] https://en.wikipedia.org/wiki/Moore%27s_law https://en.wikipedia.org/wiki/Moore%27s_law
zackmorris 9y ago
Just to play devil's advocate, I still hope that Slack and other Electron apps put pressure on things like DOM libraries to improve their internal representations. The issue here is that a table or manually nested divs store everything at once rather than memoizing. I personally don't believe that RecyclerView/TableLayout/GridLayout and UITableView/UICollectionView are the future because they are not declarative. The more code we have to juggle, the more it opens us up to bugs and pathological edge cases. What we need is something similar to https://github.com/splinesoft/SSDataSources https://github.com/splinesoft/SSDataSources that abstracts away the micromanagement inherent to view recycling. It would likely need to be tied into an evented data source like Firebase for JSON or maybe Redux or the immutable data store that Clojure uses. Then that metaphor could be adapted to the DOM and Electron's speed/memory overhead would be reduced substantially. TL;DR Wey will likely succeed because it optimizes the table loading either with a faster runtime or by implementing the view recycling manually. This is not a long-term solution, unfortunately. But I applaud its efforts.
rsyring 9y ago
Another client built specifically for Linux: https://github.com/raelgc/scudcloud https://github.com/raelgc/scudcloud
xena 9y ago
I'd love it if someone made a slack desktop app using actually native code instead of javascript. I'd pay you money. Please, someone make this so I can pay you money.
- wffurr 9y ago
  Did you try Wey? Is it fast like the author claims? Is Javascript vs Native Code really the problem or is it Slack's bloated Electron usage?
wenbert 9y ago
The beta version of the slack app for macOS seem to be better https://slack.com/beta/osx https://slack.com/beta/osx I can run it all day without problems. The non-beta one, consumed too much RAM.
CNJ7654 9y ago
Something something 'do you know da wey :DD'
deleted 9y ago
[deleted]
godot 9y ago
Seems really fast and snappy when I tried it, but already ran into multiple bugs within minutes of using it that makes it not usable for me. (Not meant as a harsh criticism, but just understand that it's early software, and I hope for it to improve and get good enough for daily uses.) 1. The always-visible scroll bars (both horizontal and vertical) on the text box makes it not possible to see what I am typing (the scrollbars cover it and the text field is not large enough to show both scrollbars and the text) -- this is on the Mac client. The same scrollbar issue exists on the channel list on the side as well, but at least it's not blocking anything. 2. When I sent a URL, the message immediately disappeared because Slack tried to generate the link preview, and apparently it's not supported yet in this client, so the whole message is just not shown.
- philliphaydon 9y ago
  I absolutely hate websites and apps that hide scroll bars. I always turn that feature off in OSX.
  - godot 9y ago
    I share that sentiment about web sites. But this is what I am talking about: https://imgur.com/DMOtSaO https://imgur.com/DMOtSaO That input text field is where I am supposed to type my message. I can't see what I am typing. I can't resize it either. Doesn't that make it unusable instantly?
    - philliphaydon 9y ago
      Ok fair enough that’s pretty bad design flaw.
betimsl 9y ago
I was reading slack as in Slack in Slackware. Then I opened the link, now I'm disappointed.
aphextron 9y ago
Is there any possibility of getting a signed macOS package for this? I can't install anything on my work machine that's unidentified.
tuananh 9y ago
interesting bit: the creator of Yue is working at GitHub but Atom's xray is already started so there's no way to see this get adopted by Atom right?
- lioeters 9y ago
  Perhaps the author of Yue has different opinions than the team working on Xray? It seems that there's duplicated effort among projects like xray, yue, libui-node/proton-native. Still, I'm glad to see people trying to solve this problem area of cross-platform apps, taking the Electron paradigm to the next level of efficiency. https://github.com/atom/xray https://github.com/atom/xray https://github.com/yue/yue https://github.com/yue/yue https://github.com/parro-it/libui-node https://github.com/parro-it/libui-node https://github.com/kusti8/proton-native https://github.com/kusti8/proton-native
tuananh 9y ago
* If all Electron/Yue apps's performance are like this, I'm fine with Electron/Yue. * The app is still quite buggy but showing a lots of potential.
indigodaddy 9y ago
Seems does not support Azure SSO login for Slack? Advises password incorrect. Made me a bit nervous actually TBH.
- voxadam 9y ago
  Did you file a bug report?
grafofilia 9y ago
Ay, wey; qué chido

277 points by zcbenz 9y ago

> While Wey currently only supports Slack, it is on roadmap to add support for more services, and in future we will support plugins to add arbitrary services. This is actually a Slack client, then?

PrimeDirective 9y ago

How is this better than the official web client and why would I use it? It's not really "native", either.

wlesieutre 9y ago
It can be not native and still lighter-weight than electron
bartread 9y ago
I would guess it uses less memory: it claims generally <100MB, although in my opinion that's still a ridiculous amount of memory for a desktop IM client to use. Still, it's better than 800MB.
- PrimeDirective 9y ago
  A bit off topic but yes, these days "native" apps tend to be memory hogs. Modern computers have tons of CPU and memory which makes the developers lazy, it would seem. Generally, noone optimizes their desktop clients.
  - corrigible 9y ago
    Telegram is amazingly smooth on Linux and Windows.
    - chocolatkey 9y ago
      Because it has a real native backend. It uses Qt/C++. I really wish other chat apps would do it...
  - benplumley 9y ago
    I've had Telegram, Slack and Discord open all day. Currently, they're using: 7MB Telegram, 350MB Slack, and 140MB Discord. Other heavy things I've got running are 160MB Spotify (which is electron) and 1GB Firefox (which is doing actual work with its memory).
- e12e 9y ago
  Meanwhile weechat w/wee-slack is lightweight. I do miss a richer (g)ui though - the standard console setup tends to break urls. And I haven't figured out if weechat supports soft line endings for eg: posting code snippets as a single (slack) message. Maybe at some point I'll find the time to revisit qweechat and see if it might be possible to strike a better middleground between "it's just chat" and all the fluff slack adds.
  - meroje 9y ago
    Are threads still all over the place in wee-slack ? Last time I used it was impossible to follow a channel with multiple threads going on, let alone reply to one.
    - e12e 9y ago
      Fwiw i think threads are all over the place in slack (for Web) too. That said, a thread can be moved "out" to a buffer, and you can apparently rename them if you want/need to: https://github.com/wee-slack/wee-slack/blob/master/README.md#threads https://github.com/wee-slack/wee-slack/blob/master/README.md... Still sucks, but better than the Web client IMNHO.
- jiveturkey 9y ago
  800MB? Is that for the Linux or Windows client? My mac client is consuming 77.0MB per activity monitor. Which I assume on Mac is power of 10, so 73.4MiB.
  - bendiksolheim 9y ago
    That is probably the main process. Slack has one process per team. I am currently running at 1.4GB on my Mac with 6 (relatively small) teams.
mistermann 9y ago
Perhaps it might show you not only new messages across your workplaces, but also a way to actually read those new messages without loading (and waaaaaiting) each one and hunting for them. Don't know if it does this, just complaining about the official client on Windows.
nvr219 9y ago
It's faster

simon1573 9y ago

How does this compare to Franz? https://github.com/meetfranz/franz https://github.com/meetfranz/franz

hs86 9y ago
Franz launches a completely new instance for every workspace/network that you add and these are based on their regular webviews. Unlike Slack, it will not unload less frequently used workspaces from your RAM and with 8 Slack workspaces, Telegram, Whatsapp and IRCCloud it managed to permanently allocate more than 3 GiB RAM. That may be fine on my beefy desktop PC but not on my MacBook Air with only 8 GiB RAM. In my case, just leaving the official apps of these chat networks in the background seems to be less resource intensive than running Franz. I really hope that https://eul.im/ https://eul.im/ will up to my expectations.
- gmemstr 9y ago
  I'm still really leery of eul.im, I can't seem to find anybody reviewing/actually using it and it throws up a couple detections on VirusTotal. Would be interested to hear of your experience.
  - amedvednikov 9y ago
    Hi, developer here. I just tested it on VirusTotal and didn't get any detections. Could you please post a screenshot with what you get here or contact me via support@eul.im? Thanks
    - gmemstr 9y ago
      VirusTotal link: https://www.virustotal.com/#/file/e88753917d7283715f0a4c633ea9f6740b38dd0fed3419a3ee03bcc84357185b/detection https://www.virustotal.com/#/file/e88753917d7283715f0a4c633e... Screenshot: https://i.imgur.com/X60nnAT.png https://i.imgur.com/X60nnAT.png I'm excited to try it but because I'd be using it for sensitve/confidential work I don't want to risk it unfortunately.
    - 9y ago

m0meni 9y ago

This is pretty cool. From just reading the repo, it's built on this library I'd never heard of before called Yue[0] that seems to be similar to electron, but more lightweight. [0]: https://github.com/yue/yue https://github.com/yue/yue

opencl 9y ago
It's not similar to Electron at all. Zero web technologies involved in it, other than supporting JS bindings. Far more like Qt/GTK except trying to use native widgets as much as possible. The Linux support actually is GTK, but MacOS/Windows use the vendor UI libraries.
- bpicolo 9y ago
  What's the bit about using electron in the JS bindings docs? http://libyue.com/docs/v0.4.0/js/guides/getting_started.html http://libyue.com/docs/v0.4.0/js/guides/getting_started.html
godot 9y ago
https://github.com/yue/yue/graphs/contributors https://github.com/yue/yue/graphs/contributors It's also mostly created by zcbenz, the author of this project (Wey), and according to another commenter, also the author of Electron.

kodablah 9y ago

First time I'm seeing Yue [0]. Seems like C++ w/ some Lua and JS bindings. Are there C bindings available so it can be used in other ecosystems without writing C++ glue? Writing a lib in C++ is rough for sharing across ecosystems and I'd say is a reason Qt and wxWidgets aren't more widespread than they already are. 0 - https://github.com/yue/yue https://github.com/yue/yue

frou_dh 9y ago
Yue sounds similar to libui[0], which has numerous language bindings, but seems to be in long term flux in terms of scope. [0]: https://github.com/andlabs/libui https://github.com/andlabs/libui

maxehmookau 9y ago

Awesome! ...also kinda depressing that it's neccessary. Hey Slack! How about an app for your service that doesn't grind my macbook pro to a halt?

SirensOfTitan 9y ago
slack-term is pretty great, but mentions don’t really work wells.
- MrQuimico 9y ago
  Humm, interesting, that looks more like a feature to me.
rplnt 9y ago
Disable emojis. Seriously, the animated emojis must be implemented with something like this while(true) { foreach(emoji) { emoji.refresh(); if (emoji.since_last_frame() > 1/60) emoji.next_frame(); } } Slack can easily eat up one core with just a few of them on the screen. Never seen that.
- wccrawford 9y ago
  IIRC, the last update on OSX specifically mentioned that they were requesting the emojis way too often, and that it's now just doing it once.

seba_dos1 9y ago

Nice! However, looking at the screenshots... I wonder why developers so often seem to get UI paddings, margins and font sizes so wrong. Does it really need some special kind of sensitivity to notice and care about it? :)

iaml 9y ago
Unfortunately a lot of developers value aesthetic and polish somewhere deep down on the list of priorities and don't seem to comprehend that other people care a lot about such things.
- pjmlp 9y ago
  It is ok, we cannot be an expert on all areas. My focus is on full stack, so I do care a lot about UI/UX, and improving my skills there. However don't ask me to do anything related to NoSQL or Deep Learning, I would be a lousy contributor.
  - oneweekwonder 9y ago
    > It is ok, we cannot be an expert on all areas. > My focus is on full stack, I'm sorry, imo those are two contradicting sentences. But it might be related to a personal pet peeve of "full stack" developers claiming to be expert in most moving parts of the stack. Only to post on medium this amazing db hack they found, to be called out in hn comments for not reading the basic docs of one of the core items in their stack. I always look at Doctors for a bad analogy; why full stack developer is a bad idea. Sure the heart surgeon will be able to diagnose your broken leg. Might even be able to assist you with a cast. But trust him to operate? There a specialist for that! Is this not the same for dev work? Designer, Developer split into 4 fields(desktop, mobile, frontend, backend), database admin, sys admin. All possible to be done by a "full stack" developer. But I don't see you become a specialist or expert in any of the fields of your stack, if you don't dedicate to a few.
    - pjmlp 9y ago
      Well, there is a reason why in some countries access to specialists is forbidden unless you are checked by a general physician first, the one responsible for being your official doctor throughout your entire life. He knows best than having people searching for specialist by themselves. As for myself, if you prefer a more descriptive example, I specialize in everything related to Java, .NET and Web (VanilaJS) stacks.

Wingwing 9y ago

This is madness. You can't solve every problem with a technological bandage. Spend the time making a nice IRC client.

rplnt 9y ago

It's insane that 100MB of ram for a "chat" client is seen as a good result. How did we get there? Is it really that much cheaper to develop desktop apps as slow and bloated web applications?

Klonoar 9y ago
Most people don't seem to grasp that in this day and age, any GUI program (at least on OS X) is going to be minimum 20MB due to the retina display. Add in that realistically you need to use Webkit (or some HTML renderer), at which point... 100MB is pretty good. For reference, an RSS reader I threw together using standard Cocoa widgets will hit 50-60MB with no issues, and that's with my being annoyingly judicious with how it's built.
- zeveb 9y ago
  > Add in that realistically you need to use Webkit (or some HTML renderer), at which point... 100MB is pretty good. Why do you need an HTML renderer? Slack uses Markdown. emacs-slack is pretty lightweight …
  - verandaguy_alt 9y ago
    >Why do you need an HTML renderer? Because it's objectively easier to do cross-platform GUI development using a single, well-defined and portable API that someone else maintains. That that API is nowadays de-facto WebKit supporting a HTML/CSS/JS stack is a natural, but unfortunate choice, and it's got a much lower barrier of entry and much less maintenance overhead than, say, Gtk+ or Qt.
  - Klonoar 9y ago
    Slack uses Markdown, yes, but supporting everything under the sun that Slack does (especially as they add new things) is just much easier inside a Webview. The job of programming isn't to reinvent the wheel everywhere, it's just to deliver a product that doesn't suck - with native code, you're implementing a native solution for each feature Slack has or adds. Slack's content is web content. You're really arguing that an insane amount of extra engineering time should be spent to conserve, at best, an extra 40-50MB of RAM... and this is disregarding how modern RAM works anyway.

staticelf 9y ago

I kind of understand the need, but I would be more prone to actually use it if it was actually fully native. Now, I can simply just wait for Slack to update their client. I don't really get why I should use this instead of slack unless I run really shitty hardware, which I don't. I had issued with Slack before, but they fixed most of them. Also new features in slack will börk this app pretty quickly, as they have to be implemented for one to use them. Cool project though, even if I personally don't get the value of it. Maybe if they added Gitter, Rocketchat etc support so you would have one client to rule them all.

wuliwong 9y ago

I installed it, it seemed a lot more "performant" than Slack's app on OS X. The Wey app crashed within 5 minutes though. :( I noted that Wey only gives links to pictures with no previews. The linking out is fine but I think inline previews would be a nice addition down the road.

polpo 9y ago

Interesting to see this is from zcbenz, who was the initial creator of Electron. Slack's desktop app, which is based on Electron, is often criticized for its memory and CPU usage, so I'm wondering if the creation of Wey and its underlying Yue library are an answer/atonement for that.

GoneToThailand 9y ago
It is so damn ugly that I prefer to keep my fans spinning the whole day than looking to that every day.
bb88 9y ago
On the github page, he writes this: > Normally for multiple teams with heavy traffics, Wey should not have any significant CPU usage, and RAM ussage is usually under 100MB. However if you have a team with more than 10k users in it, the memory usage may increase a lot. Bloaty technologies was what made MS great in the 80's/90's, because 18 months later, the speed of the CPU would double. I feel like we should think hard about optimizing for memory/cpu again.
- JustSomeNobody 9y ago
  Now that Moore's Law is dead, that time is coming. We can't afford to be wasteful. Not that we ever should have, but we've spent over a decade now catering to "developer productivity", now it's time to put the user role back in the forefront.
  - qznc 9y ago
    The last time I checked (roughly a year ago) Moore's law was still holding.
    - chacham15 9y ago
      Not sure why the downvotes. Moores law[1] refers to the number of transistors that are on the die. With the decreasing size of the transistors, this has remained true. Despite that, clock speeds have stopped growing thereby leading to serial performance not increasing as fast as it had in the past. [1] https://en.wikipedia.org/wiki/Moore%27s_law https://en.wikipedia.org/wiki/Moore%27s_law

zackmorris 9y ago

Just to play devil's advocate, I still hope that Slack and other Electron apps put pressure on things like DOM libraries to improve their internal representations. The issue here is that a table or manually nested divs store everything at once rather than memoizing. I personally don't believe that RecyclerView/TableLayout/GridLayout and UITableView/UICollectionView are the future because they are not declarative. The more code we have to juggle, the more it opens us up to bugs and pathological edge cases. What we need is something similar to https://github.com/splinesoft/SSDataSources https://github.com/splinesoft/SSDataSources that abstracts away the micromanagement inherent to view recycling. It would likely need to be tied into an evented data source like Firebase for JSON or maybe Redux or the immutable data store that Clojure uses. Then that metaphor could be adapted to the DOM and Electron's speed/memory overhead would be reduced substantially. TL;DR Wey will likely succeed because it optimizes the table loading either with a faster runtime or by implementing the view recycling manually. This is not a long-term solution, unfortunately. But I applaud its efforts.

rsyring 9y ago

Another client built specifically for Linux: https://github.com/raelgc/scudcloud https://github.com/raelgc/scudcloud

xena 9y ago

I'd love it if someone made a slack desktop app using actually native code instead of javascript. I'd pay you money. Please, someone make this so I can pay you money.

wffurr 9y ago
Did you try Wey? Is it fast like the author claims? Is Javascript vs Native Code really the problem or is it Slack's bloated Electron usage?

wenbert 9y ago

The beta version of the slack app for macOS seem to be better https://slack.com/beta/osx https://slack.com/beta/osx I can run it all day without problems. The non-beta one, consumed too much RAM.

CNJ7654 9y ago

Something something 'do you know da wey :DD'

deleted 9y ago

[deleted]

godot 9y ago

Seems really fast and snappy when I tried it, but already ran into multiple bugs within minutes of using it that makes it not usable for me. (Not meant as a harsh criticism, but just understand that it's early software, and I hope for it to improve and get good enough for daily uses.) 1. The always-visible scroll bars (both horizontal and vertical) on the text box makes it not possible to see what I am typing (the scrollbars cover it and the text field is not large enough to show both scrollbars and the text) -- this is on the Mac client. The same scrollbar issue exists on the channel list on the side as well, but at least it's not blocking anything. 2. When I sent a URL, the message immediately disappeared because Slack tried to generate the link preview, and apparently it's not supported yet in this client, so the whole message is just not shown.

philliphaydon 9y ago
I absolutely hate websites and apps that hide scroll bars. I always turn that feature off in OSX.
- godot 9y ago
  I share that sentiment about web sites. But this is what I am talking about: https://imgur.com/DMOtSaO https://imgur.com/DMOtSaO That input text field is where I am supposed to type my message. I can't see what I am typing. I can't resize it either. Doesn't that make it unusable instantly?
  - philliphaydon 9y ago
    Ok fair enough that’s pretty bad design flaw.

betimsl 9y ago

I was reading slack as in Slack in Slackware. Then I opened the link, now I'm disappointed.

aphextron 9y ago

Is there any possibility of getting a signed macOS package for this? I can't install anything on my work machine that's unidentified.

tuananh 9y ago

interesting bit: the creator of Yue is working at GitHub but Atom's xray is already started so there's no way to see this get adopted by Atom right?

lioeters 9y ago
Perhaps the author of Yue has different opinions than the team working on Xray? It seems that there's duplicated effort among projects like xray, yue, libui-node/proton-native. Still, I'm glad to see people trying to solve this problem area of cross-platform apps, taking the Electron paradigm to the next level of efficiency. https://github.com/atom/xray https://github.com/atom/xray https://github.com/yue/yue https://github.com/yue/yue https://github.com/parro-it/libui-node https://github.com/parro-it/libui-node https://github.com/kusti8/proton-native https://github.com/kusti8/proton-native

tuananh 9y ago

* If all Electron/Yue apps's performance are like this, I'm fine with Electron/Yue. * The app is still quite buggy but showing a lots of potential.

indigodaddy 9y ago

Seems does not support Azure SSO login for Slack? Advises password incorrect. Made me a bit nervous actually TBH.

voxadam 9y ago
Did you file a bug report?

grafofilia 9y ago

Ay, wey; qué chido