Show HN: Wey – A fast, open-source Slack desktop app | Hacker News Reader

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

github.com

277 pointszcbenz177 comments

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.

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.

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.

The last time I checked (roughly a year ago) Moore's law was still holding.

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

GPUs were stuck on 28nm for over 5 years before 16nm one launched. Intel has been stuck on 14nm for three and a half years and counting. This has certainly not been anything close to doubling every 18 months.

To repeat: Moore’s law is about transistor count, not size. From the Wikipedia article linked in the comment above yours: “Moore's law is the observation that the number of transistors in a dense integrated circuit doubles approximately every two years.”

Transistors can stay the exact same size for twenty years as long as the die size grows, and Moore’s law still holds.

But the die size didn't grow at nearly that rate, large dies remain very expensive to make. For example, comparing the HD7970 and RX 390X, similarly positioned GPUs released 4 years apart in 2011 and 2015, transistor count grew ~50% from 4.3 billion to 6.2 billion.

https://www.anandtech.com/show/5261/amd-radeon-hd-7970-revie...

https://www.anandtech.com/show/9387/amd-radeon-300-series/3

> But the die size didn't grow at nearly that rate, large dies remain very expensive to make.

But again, did transistors double in count on any processor, not just GPUs? If so, Moore held. Yes, according to this chart:

https://en.m.wikipedia.org/wiki/Moore's_law#/media/File%3AMo...

I mean if you want to go with the highest transistor count chip currently in existence, that would obviously be the 512Gb flash chips with ~170 billion transistors. Or if you want to constrain it to 'processors' that would be the 30 billion transistor Altera FPGAs. Which have been available for 3 years. No CPU yet has exceeded the 10 billion transistor count of the Sparc M7, also released 3 years ago. The Tesla P100, two years old, retains the highest GPU transistor count at 15 billion.

It's meaningless to compare these totally different types of chips that end up with extremely different transistor densities on the same node due to the wiring requirements.

I'm just the messenger. Apparently there is some sort of criteria for what a "dense integrated circuit" is for the chart previously pasted, and apparently all of the listed processors passed the required criteria for charting the law through time. What that criteria is, I couldn't tell you. Couldn't find it on the Wikipedia page. "Moore's law is the observation that the number of transistors in a dense integrated circuit doubles approximately every two years." (Wikipedia)

Yes. I read the wikipedia quote the first time you posted it. No need to say the exact same thing 5 times. The chart is clearly restricted to CPUs and ends in 2016. It's 2018 and the top chip on that chart still has the highest transistor count of any CPU on the market. Absolutely zero increase in transistor count for the type of chip that would go on that chart. Every category is seeing the exact same stagnation, Moore's law has been nowhere close to being matched in the past few years. Every chipmaker is struggling with their new nodes and falling way behind schedule on improvements. High-volume chips that normal people buy are really a far more realistic and useful barometer for Moore's law, and again you see the stagnation. Skylake and Kaby Lake are near-identical chips. Coffee Lake is ~25% bigger. There is no doubling of transistor counts going on in anything resembling an 18 month time frame.

Okay, so the comment is then that you believe Moore's law no longer holds because for the past two years transistor counts on CPUs have not increased. On that basis, I might agree. Not (as you were stating earlier) about the sizes of the transistors themselves, or about GPUs from 2011 to 2015, or about 512Gb flash chips. None of that applied to this conversation, hence the desire to repeat myself. Thank you for finally clearing that up. Now that we're finally on the same page, I might agree.

Are there no CPUs with higher transistor counts out there? Maybe ones you are not aware of yet?

Please show me this CPU with a higher transistor count. There is a maximum die size that each fab is able to make, mostly related to the optics used for their photolithography process. Most designs are nowhere near the limit because larger sizes are uneconomical to produce, though NVIDIA for example is on the record stating that TSMC is physically incapable of producing anything larger than their current GPUs.

> Please show me this CPU with a higher transistor count.

That was my question to you. You claimed, "It's 2018 and the top chip on that chart still has the highest transistor count of any CPU on the market." Which I take to mean that you don't know of any CPU with any higher transistor counts, which is an argument from silence. There could be a CPU outside of your knowledge.

So, we wait to see. Moore may be dead but "moore" time may be needed to hold the funeral.

I agree with both of you that transistor count per mm² is stagnating in the last years. However that has happened before. For example, 1982-1987 and 2007-2010 according to Wikipedia data.

It is too early to declare Moore's Law dead.

> Not that we ever should have

You say that like people were making these bloaty apps for the good of humanity—trying to make them objectively perfect, but falling short. While FOSS is done with that mindset, FOSS isn’t usually where bloat comes from.

Bad engineering is usually the result of overriding business concerns: being first to market, iterating quicker than your competitors, having more reach on more platforms with less expense, etc. More features before feature polish, and user-visible polish before good architecture.

Even without Moore’s law, this incentive is still in place. It not just has a slight countervailing force of nobody wanting to run apps that take too many resources.

What that means in practice is that apps will still be as bloated as possible (or rather, with as little optimization done as possible) while still managing to not choke the machines they’re on.

Moore's law is alive and well. If it is slowing at all it is evidently due to monopoly/lack of competition more than anything else. It feels like Moore's law is dead because there actually were a few more laws at play which have died. We went from exponential-exponential to just exponential, which feels like going from exponential to linear from our perspective, but is not the death of Moore's law.

Can't make transistors smaller? just add more! Speed of light becoming a problem? Stack em! Speed of light and heat becoming a problem again? Stack cores, improve multi-core architecture in both hardware/software and enjoy another many decades of Moore's law. It won't be dieing any time soon

If it’s slowing? Intel says it is. And Moore said dying in next decade.

Wikipedia:

Moore's law is an observation and projection of an historical trend and not a physical or natural law. Although the rate held steady from 1975 until around 2012, the rate was faster during the first decade. In general, it is not logically sound to extrapolate from the historical growth rate into the indefinite future. For example, the 2010 update to the International Technology Roadmap for Semiconductors, predicted that growth would slow around 2013, and in 2015 Gordon Moore foresaw that the rate of progress would reach saturation: "I see Moore's law dying here in the next decade or so."

Intel stated in 2015 that the pace of advancement has slowed, starting at the 22 nm feature width around 2012, and continuing at 14 nm. Brian Krzanich, CEO of Intel, announced, "Our cadence today is closer to two and a half years than two." Intel is expected to reach the 10 nm node in 2018, a three-year cadence. He cited Moore's 1975 revision as a precedent for the current deceleration, which results from technical challenges and is "a natural part of the history of Moore's law."

More background in recent article here on 40 years of processor performance:

https://www.eejournal.com/article/fifty-or-sixty-years-of-pr...

HN: https://news.ycombinator.com/item?id=16750733

How much RAM does wee-slack use? https://github.com/wee-slack/wee-slack

thanks for linking this, I was looking for a way to intergrate slack into weechat without using the irc gateway since they are dropping support for that

The price of RAM has actually gone up in the past 5 years, so that's not a terrible idea.

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? :)

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.

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.

> 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.

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.

As a citizen of one of those countries, this fails spectacularly when your family doctor does -not- know best or just doesn’t care about his job, yet due to the huge scarcity of family doctors, will never lose any of his clientele.

And a lot of developers just don't have an eye for it at all. I can look at a UI all day and tell that something is off but I couldn't even begin to tell you what or how to fix it. It doesn't mean I don't care.

It’s not just having an eye for it; UI design is an entire field, and human computer interaction (HCI) has existed since the 70s. I think that a large part of the problem is PMs / managers / tech leads not understanding that design has subjective elements but can also be objectively good or bad, and that they can’t tell the difference between a design that is correct and works well but might not look very flashy vs something that gets lots of likes on Dribble but is awful to use. This feeds into itself and leads to more people thinking that they know what good design is (pretty) and hiring other people who call themselves designers who have no idea about the actual science behind it.

As a developer who appreciates good design but doesn’t really know how to create it, can you suggest a good entry level resource that summarizes what we’ve learned over the last 50 years about HCI and how to make usable interfaces?

Pluralsight has a few nice courses.

Don't Make Me Think be Steve Krugg,Grid systems in Graphic Design by Josef Müller Brockman, Designing with Grids by Mark Boulton, Any of Ellen Lupton's Type Design books. All light reads except Josef's.

Also, the classic Elements of Typographic Style by Robert Bringhurst, and probably just go and read everything on Smashing Magazine from about 2010 to now.

I have the same problem. If you showed me two UIs I could probably identify the more aesthetically pleasing one.

But if you showed me a single UI, I highly doubt I could improve it.

I believe [0] the biggest trick is to avoid most of the things you can do.

[0] http://beza1e1.tuxen.de/slide_design_programmers.html

cracks fingers I made a book for you! http://uxbook.io/

A sample would be nice.

The publishers have plans to do that apparently but not yet. I definitely want to do chapter excerpts.

I don't think that's a matter of priorities so much. I think most of them simply don't notice it or don't know what's exactly wrong when they do. At least that's what I noticed in some people I worked with.

Tweaking that stuff early on is so effective that it could almost be thought of as a "cheat code" for development. User perception is greatly enhanced by a few hours of tweaking padding spacing etc., rather than a few months or years of deferring that tweaking.

> User perception is greatly enhanced by a few hours of tweaking padding spacing etc., rather than a few months or years of deferring that tweaking.

Some of us explicitly don't want the UI to give off the impression that the software is more finished than what it really is, so we sometimes intentionally keep the UI unpolished while we know that we have important things not yet implemented.

However I have come to realize that there are several downsides to this line of thinking;

1. If the app looks bad then it might permanently put off would-be users.

2. By not giving the UI enough attention early on, discoveries of UX problems that could have been caught early are not made until much later, delaying the project and potentially leading to more work as well because there will be more things that need to be rewritten or remade in order to fix the UX problems.

3. If you think feature X needs to be completed before you do the UI, then what is going to keep features Y and Z and so on to make you think the same way when you get there? Software is often never "complete". If you think it needs to be "complete enough" before you can give it the UI it deserves, how will you know that you've reached the stage of complete enough?

Furthermore, I have come to realize that often we don't know what we want exactly. We might think we know, but as we work on implementing our ideas things turn out to not be quite as we'd imagined them to.

But I also think that grand parent was on to something. When we build software, we should strive to implement features that are useful but not only that, the software needs to make the most common tasks as efficient for the user to perform as possible. And in order to find out what that means, we need to consider the UI from the very beginning.

I used to work for a company that put out thousands of site a year. I was fortunate enough to work with some really anal retentive designers. After a few months, I was able to pick up a 1 or 2 pixel difference in the photoshop docs, see how fonts did or didn't work and if color schemes were decent.

There's a ton of tools out there to help you with these, and as a developer, I like tossing around a lot of the design stuff that gets regulated until an app or site is totally functional, when I feel like most of the design work stuff should be done prior to getting your app working.

Design is the hard part, coding it? For me, that's the easy part. I feel like once I've got some decent font's paired, a color scheme worked out and other design elements nailed, the rest is easy.

First make it work, then make it correct, then document it, then make it efficient, then make it pretty.

Rarely all stages are reached, but in open source projects, anyone can cook their favorite dish for this dinner.

The problem with that is that “pretty” is implying simple visual beauty. It diminishes what design really is: the way something works not simply how it looks. “Pretty” should be integral to “make it work.” If your design is good, it’s more self-documenting, so pretty early in the process means less work documenting — it also reveals more of the essence of what exactly you are building which then helps drive the decisions on what to build next.

Design shouldn’t be an afterthought, it should be THE thought.

I disagree. If you make something, THE thought is that it fulfills its function correctly. I wouldn't pursue an excellent UX if the inner workings are buggy.

Aesthetic and polish are over-prioritized in modern development. Which is more likely to anger the user -- a beautiful app sadly broken or an ugly one which does what it says on the tin?

It really depends on degrees. I've seen apps that were so bad, I couldn't even figure out what to do. It could be mathematically provable under the hood, but if I can't even figure out how to use it, or if the experience is bad enough, I won't care how well it is implemented.

They are one in the same. It’s not zero sum. You don’t sacrifice function for form nor should you sacrifice form for function. They should be the same thing. Form follows function — form shouldn’t be tacked on at the end.

We aren’t talking about the color of the paint, we are talking about the way the parts fit together.

These developers are front end developers they should care about that kind of thing.

I guess this is an early release and getting the details right does take time. I sometimes get comments along the lines of 'is that all it does?' when I've spent lots of time getting the details correct.

Plus yes I think it does require some level of sensitivity to it. 99% of people just don't notice, but the details do matter in the long run as it begins to feel right to people, who will never be able to explain to you why or even complement you on it but will carry on using the system because of it.

Yes, it is called frontend development, regardless of native or web based stacks.

Care to learn about UI/UX and human psychology how regular users approach computers.

Learn how to design UIs and application workflows for people that care how to do their job, without having to understand the internals how computers work.

Requires to learn about design and soft skills as well.

Although it's important to care about stuff you mentioned, that's completely unrelated to what I meant ;)

What do you mean; the lack of padding in the blue column?

Overall, UI design is really not too bad here. On the other hand, it's almost 1:1 copied from the official Slack app.

There is no "vertical rhythm". The strength of the different elements is all over the place.

Some elements randomly have 20px spaces between them, some have 28px, some have 32px. This would be fine if they were done on purpose but right now they look like they were chosen randomly.

https://user-images.githubusercontent.com/639601/38463114-17...

Take a closer look at the space below the "BabelJS" title.

Compare the space between "direct message"/"slackbot" vs. "slackbox"/"zcbenz".

Why is the padding around the channel icons 20px on all side while the spacing to the left of "BabelJS" only 13px?

etc.

Edit: If you still cannot grok what I'm taking about, play a bit with this tool and you will understand https://www.gridlover.net/try

This! It's very far from being 1:1 clone of Slack UI, it's closer to a child's drawing of Slack UI. A mockup.

See, this is what I meant, some people just don't see it!

> See, this is what I meant, some people just don't see it!

i'd say most people don't see it. maybe it's not very important then?

People won't see it when looking at you app with blinders on. However, they will feel the difference when using the competition's app.

They won't be able to tell you why they prefer the one with more time invested in the UX/UI, but they will almost always choose that one.

There are universal rules in design and everyone is using them. We are actively training the users into feeling those rules as superior.

(This is also why huge paradigm changes feel so refreshing. Breaking the rules on purpose is very strong.)

> They won't be able to tell you why they prefer the one with more time invested in the UX/UI, but they will almost always choose that one.

do you really believe that or does your job depending on you and others, believing that? I get UX is important, where UX is defined by such things like "number of clicks to achieve a task", but the OP was talking about margins and padding etc which just are a lot less important than designers like to think. It's probably an uncomfortable truth for people who spend all day tweaking things 1px at a time, but I think it's largely true.

A case in point is the new Reddit design being tested (https://media.wired.com/photos/5abed25228f0c90b2647ac08/mast...)

It's prettier, I can see that. If it was a painting I'd rather hang the new one than the old one on my wall, but when it comes to pure functionality (read a list of links) the current (ugly) design is better (imho).

>do you really believe that or does your job depending on you and others, believing that?

It's not a question of believing; the job exists because there's a real need to optimize the visuals. The brain has its own API (see [1], [2]) and if you don't optimize the "visual code" to it, the interface may work, but in sub-optimal ways and causing a discomfort to the user. It's like having a C program that leaks memory. It may perform the expected task, but you wouldn't say it's "right".

Margin and padding, alignment, contrast and relative positions define the structure of the interface - in the same way that you use Layout objects behind the curtain to program where every widget is placed, you should use the visual properties of separation, visual weight and rhythm to tell the user which parts are related and what is the hierarchy of the elements. If you fail to convey the structure to the user, their mental model will be wrong and the interface will be hard to use.

[1] https://en.wikipedia.org/wiki/Gestalt_psychology#Pr%C3%A4gna...

[2] http://www.scholarpedia.org/article/Gestalt_principles

There are no glaring mistakes when it comes to Reddit's new design. Nobody is saying that the use of white space is wrong or that having margins and padding is wrong.

The issue is when it's not respecting anything and is simply thrown together randomly. If OP's app were to copy the same padding and margins as Reddit's new sidebar, I would have nothing to say against it.

Yes, your app will do fine with minor design issues. It won't drives all of your users away. However, they might start to notice that your main competitor's app feels better and slowly trickle that way. There is a reason that all top brands have such strong design and user experience/graphic design teams. One or two small issues is fine, but they pile in really quickly. Nobody wants to complete a checkout when the entire page looks like the content of a 1995 website in a iframe.

My personal philosophy is "why do anything if you are not going to do it beautifuly?". As a full-stack developer, it's easy for me to see both side of the medal. It would be very straightforward for me to simply throw components on the screen and call it a day. By the time I've programmed and integrated them in, I'm tired and only want to close the task. I have to remind myself of my motto and it always results in a better experience for everyone involved with the end product. Most of those design decisions can be done in a few minutes if you take the time (and if you have received proper training to spot the issues) and those few minutes can results in a big leap in quality.

I agree with you wholeheartedly (as a fellow full-stack dev) but I think that much of what constitutes modern "design" places too much emphasis on expectations management and user feelings. There seem to be few that are truly concerned with usability metrics and too many concerned about aesthetics or optimizing for business objectives.

Sometimes the best user experience does not look the prettiest, and even more often does it fail to line up with business requirements. Both of those concerns need to be de-prioritized.

> OP was talking about margins and padding etc which just are a lot less important than designers like to think

Are you just saying that or do you have evidence to back it up? I'm not a designer but I work closely with them and I'd say it's the exact opposite. Developers (myself included) tend to get tunnel vision on finishing functionality but the actual end users of the software care a lot more about the 'small things' like that than you're giving them credit for.

The fact that you say 'tweaking things 1px at a time' shows that you don't quite understand that it isn't about moving things around arbitrarily, it's about creating a design system that does it for you. Every header should have X amount of spacing between it and other elements, every paragraph should have the same size that makes sense with the headings it sits under, backgrounds should draw the users eye to important places, etc.

Using the old/new Reddit is a horrible example, because the old Reddit absolutely had a design system that made sense to the user. It might have been simple, but the spacing was consistent across every element. Watch the comments when a subreddit mod team updates their theme and small things like the padding around the comment preview is missing, it's the first thing that the users of the sub notice.

I've done a lot of end-user interviews, and actually paying attention to your padding/margins and making sure all of the elements fit your grid can be the difference between the user trusting your app because it looks professional, and giving up on it because it looks like a side project (or to use the Reddit example, the difference between using the home page and a half-baked custom sub theme).

HN might not be the demographic that you're going to get that feedback, but unless you're writing your software specifically for developers you're going to be losing a lot of trust regardless of how solid your software is behind the UI. It's not about creating 'art', it's about making your work look trustworthy to the end user.

grids are great. nobody's arguing that a UI should be inconsistent, that is absurd. The vast majority of designers only attack the problem from a shallow aesthetic pov though.

>Using the old/new Reddit is a horrible example, because the old Reddit absolutely had a design system that made sense to the user.

Your own argument supports exactly what I'm saying. The designers of the new Reddit took an existing, very functional design and then f*cked it up by making it "pretty".

Most designers put UX on their resume (because it's trendy), but their folios betray that they do aesthetics (which is great, but not terribly important), and only have an effect on UX accidentally.

> We are actively training the users into feeling those rules as superior.

I would wager that we are not necessarily training users into feeling those rules as superior, but the absolute opposite — people tend to feel more at ease / comfortable when those rules are in place, and we want people to feel that way when they use our products, and so we use those rules. Ubiquity/familiarity is one reason why someone may feel at ease with a design, but it’s absolutely not the only reason. There are other more fundamental reasons why some designs are pleasant and others are unsettling / frustrating.

For example we can’t explain why harmony sounds pleasant and why dissonance is unsettling. We can explain how they are different from each other and describe these differences with rules, but not necessarily why one makes us feel good and why another makes us feel bad. But the musician knows these things— that certain arrangements make people feel a certain way. And using this knowledge, the musician can compose music that falls in line with the effects that he wants it to have on people.

Still, you don’t need to be a musician to know when a song sounds horrible. You don’t need to be a chef to know that the food tastes horrible. You don’t need to be a designer to know that it’s unpleasant. We can feel an unsettling interface even if we don’t necessarily know why it’s bad. Good designers are just more in tune to these feelings and also are able to identify and implement the technicalities as to how to make the design feel the way they want it to.

We generally don’t want people to feel uncomfortable when using our interfaces (although maybe sometimes we do), so we tend to settle on some rules of thumb that we know make people more comfortable like “visual heierarchy” “vertical rhythm” “line length not more than 60 characters” “not having to make 6 clicks for something you do fairly often” “context (such as breadcrumb navigation)” etc. And, I mean, when you put a lot of these rules together you end up with a lot of interfaces that converge to look and feel the same. Doesn’t necessarily mean we are actively training people to feel that these things are better. At a fundamental level people already do. Good design is more of a discovery of human nature / an applied science.. than a conspiracy to make people like things.

We don’t like food that tastes like crap. If everyone’s food tastes like crap, well, we’re going to be eating food that tastes like crap. Because we still need to eat. But the moment someone puts out food that tastes less like crap, people are going to want to eat that person’s food more than others’. And maybe that chef proclaims a rule that “when you include X in your recipe, or when you don’t do Y, your food tastes less like crap and more people want it.” And now more chefs who want to sell food are putting out food that follows that rule. And now more food on the market taste a little less like crap. That’s pretty much how design works as an industry.

> There are universal rules in design and everyone is using them. We are actively training the users into feeling those rules as superior.

If the rules are universal, then why would users have to be trained to consider them superior?

Dissonance and consonance are universal. You still have classical music, rock & roll, metal, techno, pop, etc. Even in the world of classical music, there are different waves and composers stretching the limits of the framework around them.

We are training the users into enjoying very rigid and professional looking websites. Anything amateur looks jarring these days.

This wasn't true in the 90's - we trained the eyes of the users into disliking amateur looking websites.

OK. If you say so. It doesn't make much sense to me.

You could also argue that with the Slack app's memory usage, it's closer to how a child would build professional app, and is more of a prototype than a shipping product. (No disrespect to Slack developers: I understand the tradeoffs of using Electron). My point is that if design shortcuts were taken, that's because development priorities were elsewhere (ostensibly, focusing on performance)

I absolutely agree with you, my observation is strictly limited to the design. I think Slack's devs are way more to blame than Wey's, we're just not talking about memory usage in this thread :)

I can see what's wrong with the things you're talking about, except for one — the space below the BabelJS title. For me, it creates a clear separation between it and what is below, which I think makes sense. What am I not getting?

(I have to work hard to see such things, though, and I'd have to try even harder to be bothered by them.)

Without a doubt. However, why the magical 50px?

Why not take some of that screen space and move the title a bit lower so that it doesn't look so out of place with the whole vertical rythm of the page? The icons to the left are starting at 20px, why not put the title there? The title is also directly linked to those icons. Clicking on an icon changes the title. The title is the current selected icons's title, in fact. Aligning them makes that connection clearer.

That's the kind of questions you should ask yourself when you design an interface.

Right now, the title has a 50px margin because that's the distance the official Slack app uses. However, the official app puts the current user's username there, so that there's Title>10px>Username>30px>Channels ... instead of Title>50px>Channels. It's a direct copy that is missing some elements and that's why it feels wrong to the eye.

Thank you for those details. I'll have to look for a good resource that explains these things well.

Then let me recommend you Design for Hackers† by David Kadavy. If you care to take the step it'll be an enlightening journey after which many things cannot be unseen.

† ISBN 978-1119998952

Thanks for recommending D4H!

Yeah, heading distances are a bit awkward - especially because the lower one ("Direct Messages") is closer to the first item than the first to the second item. But I'd say it doesn't hurt usability too much. If anything, I'd rather tackle the slightly different font sizes in the left and right area first.

It's not necessary that everyone should be well versed in design. I code in js and can't really do design well. If you can do good UI stuff then you can contribute to it!! They would welcome withopen arms!! Cheers!

Design is not my thing as well. I code - mobile OSes, XMPP clients, backend/frontend, native utils, games, various stuff (majority of this as FLOSS contributions, even at work ;)) I was never trained in design, I don't care about it that much. Yet I see all those wrong paddings and wouldn't do them this way even in a quick proof of concept.

I don't blame the developers, I don't blame the project. I'm glad they do such client and would probably use it over the official Slack client even with its current UI (I'm more interested in a solid XMPP transport though). I just noticed that some people genuinely don't see or can't put their finger on those issues at all, which makes them unable to think about it and fix them without external help. And I wonder why it is like that - what makes you see those misaligned things as standing out, while others don't notice it?

Because:

* in open source software projects, professional designers are rare.

* functionality or documentation might have been higher priorities

* it would be unfair to deprive you of the opportunity to contribute a better design to this open source projet

The last bullet should come with a warning to put your drink down first.

What is the best way for designers to help with opensource projects? These projects are often very developer oriented.

Not bash their contributions like it has happened on GNOME and KDE.

The bashing is truly amazing. Not only does it lack constructiveness (in most cases), but Gnome (I speak of Gnome here not to the exclusion of KDE. I just happen to be a Gnome user) is beautiful, and has been for years.

Thank you Gnome team, including designers, that created such a beautiful desktop experience for me.

Design is more than beauty. Design is functionality, how you use stuff. As long as I rather jump into a terminal than navigate through the UI, that's a fail in my book, and very few DE's on Linux pass this test.

Nicely ask in the bug tracker about how a designer can help. Maybe start with a mock of what you want to change. I'm sure most open source developers will put in extra effort to help you because they value contributions from designers.

Regardless of comments about the required skill levels of whatever profession, in this case I think it is clear that it is because it is still in development and the screenshots are only meant to demonstrate the look of the native UI elements. Setting all the paddings to something acceptable takes time (and is just one part of perfecting a design), and that time is pretty much wasted if the layout might still change significantly.

Even if they just went with 10px spacing everywhere it'd be an improvement.

I thought it wouldn't be so bad, but now that I have seen the screenshots... it's pretty bad.

The thing is, a lot of developers seem to have no anesthetic sense whatsoever. I realized this when I noticed that almost all Emacs themes are garbage, and that no one seems to mind. I even wrote a blog post about it with several examples and people thought I was trolling.

I mean, just five minutes of work put into this Slack thing would have improved the look a lot, so the other commenter's point about priorities is just kind of dumb. Slack may be a piece of junk but at least it is passable in the looks department. It's not like it's the 90s or anything. How can someone think that looks aren't important?

It’s an open source project with bold text saying not to use it for work since it’s incomplete and may be buggy.

The authors goals may not align with yours, and their decision of what they want to do on their free time might not align with yours - this is exactly why releasing it to the open is a good thing, talented and interested people can contribute to it if they choose, or use something else if they are so inclined.

I’d love to try themes developed by someone with as strong opinions on design as yourself, but you wrote a blog instead. Its what you wanted to do, and you did!

I tend to focus on configurability up front, while respecting system defaults. That approach doesn't always yield the cleanest results out of the box, but I'd want user feedback on functionality before I get into polishing the look and feel.

Not that designers have any better ideas. Where the hell did 20px margins and 90% whitespace come from?

As a developer who both suffers from the same issue and is a little aware of it, I would say lack of training. What do I need to read to fix this?

And the hordes clamoured in unison "You need to have an MVP. If you are not embarrassed by your first release, then you have released too late!!". And the developer released his Minimum Viable Product unto the public. And the hordes were dismayed, and they reeled back uttering "That is butt ugly!". And the developer was dejected and wandered away to work on something else.

In all seriousness - mixed messaging as seen on this thread is why I believe most (myself included) eschew the whole 'MVP' thing and try to polish products before release.

Exactly. It drives me nuts in startup world the "push for MVP" or critical path first -> release -> iterate/improve, yet when the product gets released it is criticized for rough edges, bugs, but most appallingly missing features.

Well yeah, users want the full fucking product, not the MVP.

MVPs happen to be an (apparently) efficient model for startups, but its not like anyone actually wants it. Your users might grudgingly accept your half-finished, buggy, unoptimized MVP because nothing better is available to them, but how could you possibly expect anyone to be happy with this?

MVPs are pushed by businesses, not by consumers. But on the market-scale, it also pushes MVPs (because you get bonuses from being first-to-market and such).

But no individual consumer goes around saying "yeah I'd love to be promised the world, and instead recieve a millionth of it".

Of course you're going to be criticized by the people you've given hope to, only to let down with bug report #985

I've been trying to put this effect into words for years... You've nailed it with "wrong paddings, margins & font size". Nicely done!

Personal opinion I guess. FWIW the screenshots look completely fine to me. And most important, they don't waste so much screen space as is common with UIs created by "UI designers".

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

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

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?

slack-term is pretty great, but mentions don’t really work wells.

Humm, interesting, that looks more like a feature to me.

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.

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.

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

It can be not native and still lighter-weight than electron

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.

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.

Telegram is amazingly smooth on Linux and Windows.

Because it has a real native backend. It uses Qt/C++. I really wish other chat apps would do it...

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).

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.

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.

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...

Still sucks, but better than the Web client IMNHO.

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.

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.

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.

It's faster

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.

I absolutely hate websites and apps that hide scroll bars. I always turn that feature off in OSX.

I share that sentiment about web sites. But this is what I am talking about: 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?

Ok fair enough that’s pretty bad design flaw.

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

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.

What's the bit about using electron in the JS bindings docs?

http://libyue.com/docs/v0.4.0/js/guides/getting_started.html

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.

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.

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

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/ will up to my expectations.

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.

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

VirusTotal link: https://www.virustotal.com/#/file/e88753917d7283715f0a4c633e...

Screenshot: 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.

The latest version fails to start for me (just crash upon startup)

Have you tried eul? How does it behaves compared to the official clients or other non-native alternatives?

It was still very unstable for me and somehow their change-log always indicates that the upcoming version n+1 will be SO MUCH BETTER than the current version n.

Therefore I am always skipping the current version and wait for the next one.

Yeah I've been really slow and unreliable with the releases so far with weekly delays. Developing a truly native client for all 3 platforms is pretty hard.

The final beta with Linux support is going to be released in a couple of hours, and the development process should be quicker now that I'm finally done with UI and graphics.

Looks cool, I especially like the proposed Signal support... how can I download the Linux Beta? Not finding a link, and since it's not open source I assume the code isn't on github. Good luck, looks interesting

Similar alternative https://github.com/saenzramiro/rambox

Really want spell check in rambox.

I don't know enough about electron, but this seems pretty bad: https://github.com/saenzramiro/rambox/blob/8094752efb55a003b...

https://github.com/saenzramiro/rambox/blob/b217c9d8f1c0030a7...

https://github.com/electron/electron/blob/master/docs/tutori...

Good catch!

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.

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

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

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 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.

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.

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?

* 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.

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

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

Did you file a bug report?

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?

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/yue/yue

https://github.com/parro-it/libui-node

https://github.com/kusti8/proton-native

> 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?

Ay, wey; qué chido

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?

As a random data point: As I write this, irssi with perl and xmpp plugins consumes about 6M and never gets slow.

It's a chat client that supports rendering HTML as a first-class citizen. The definition of what a 'chat client' _is_ has changed since the days of AIM/MSN messenger/IRC.

Even AIM allowed basic HTML for profile pages.

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.

> 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 …

>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.

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.

> Slack's content is web content.

That's the underlying issue. If the "protocol" uses HTML, all clients will need to embed a web view.

And to think the first WWW browser just used Next's Text view.

Telegram, which I believe uses Qt, currently sits at 90MB on my macbook. It's not great either, but how much would a "Hello world" Electron app need?

Telegram is native code (Swift/etc), not Qt* - at least, depending on which version you're using, and it largely eschews webviews short of one or two places as far as I know.

* - Unless you're using the (older, I believe) Telegram Desktop client, which is different from... Telegram.

Telegram Desktop is the current client for all major desktop platforms. The last commit on the repo was yesterday. It does use Qt. And how is Qt not native code? It's C++. The Android client is mostly Java, the iOS client is mostly Objective-C, and there's also an actively maintained web client.

https://github.com/telegramdesktop/tdesktop

Mmmm incorrect. See: https://macos.telegram.org

Which clearly links source as: https://github.com/overtake/TelegramSwift

Nobody I know on OS X would use the Qt one as it feels really out of place... I guess if you cared about ricing out your desktop or something.

Or have consistent experience across platforms.

edit: 200MB installer compared to 30MB for the "Telegram Desktop".

Consider compressing your graphics (pngnq et al), or use resolution-independend image formats, like SVG.

I think ultimately the image has to be represented as a bitmap in memory somewhere, right?

I used to play 3D games like Midtown Madness 2 in my computer with 16MB ram. Now my iMac with 8GB memory and i7 processor can not handle opening Slack, Chrome and an e-mail app at same time. This is where we are at.

I agree.

At work, one of my projects is a cross-platform scientific C++/Qt application. It is currently open, and with 5 charts (hundreds of data points each) and a full-blown interactive 3D representation of a model, it sits at 160 MB.

Seriously, I understand the trade-offs of writing HTML+JS vs. C++, but at some point we must start taking into account the amount of waste (energy, resources) that hybrid apps create.

RAM is cheap, why should we care?

RAM is not cheap at all. Especially for many of your costumers running on limited resources.

Also, a chat app is generally not the "main" application and should strive not to deprive the system of its working memory.

But, hey, that's just my opinion. Luckily your users agree with you (looks like many of Slack's don't!).

Something something 'do you know da wey :DD'

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

Reply on news.ycombinator.com