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.
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? :)
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.<p>0 - <a href="https://github.com/yue/yue" rel="nofollow">https://github.com/yue/yue</a>
Awesome! ...also kinda depressing that it's neccessary.<p>Hey Slack! How about an app for your service that doesn't grind my macbook pro to a halt?
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.)<p>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.<p>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.
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.<p>[0]: <a href="https://github.com/yue/yue" rel="nofollow">https://github.com/yue/yue</a>
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.<p>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.<p>Also new features in slack will börk this app pretty quickly, as they have to be implemented for one to use them.<p>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.
How does this compare to Franz?
<a href="https://github.com/meetfranz/franz" rel="nofollow">https://github.com/meetfranz/franz</a>
I installed it, it seemed a lot more "performant" than Slack's app on OS X. The Wey app crashed within 5 minutes though. :(<p>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.
The beta version of the slack app for macOS seem to be better <a href="https://slack.com/beta/osx" rel="nofollow">https://slack.com/beta/osx</a> I can run it all day without problems. The non-beta one, consumed too much RAM.
Another client built specifically for Linux: <a href="https://github.com/raelgc/scudcloud" rel="nofollow">https://github.com/raelgc/scudcloud</a>
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.<p>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.<p>What we need is something similar to <a href="https://github.com/splinesoft/SSDataSources" rel="nofollow">https://github.com/splinesoft/SSDataSources</a> 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.<p>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.
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.
* If all Electron/Yue apps's performance are like this, I'm fine with Electron/Yue.<p>* The app is still quite buggy but showing a lots of potential.
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?
> 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.<p>This is actually a Slack client, then?
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?