At heart, Slack is a chat app. Chat apps have existed for 40 years and don’t require a whole lot of data.
The complex part might be displaying the data, but that’s not much different than what an RSS reader does.
Even calling a chat app “complex” sounds absolutely ludicrous. It’s just that devs are now used to shipping 100MB apps in the name of fast development, so Slack is what we get.
I'm not sure when you used Slack the last time but there's a lot more than "just a chat app" and it sounds like one of these "I can build that in a weekend" comments.
There's video calling, audio calling, screen sharing, file sharing, permissions, media files sent around. It's not comparable to some old chat app where you only have to get new messages and display them in a chronological list.
I'm sure the app has to be able to deal with all that, and that unmistakably adds a layer of complexity which ought to exhibit _somewhere_.
On the other hand, when using the Slack app as a simple chat app - formatted text only, a few formatted in-line code snippets, things like that.. the experience can often be abysmal.
Just the other day, I was typing a _text_ message in a private chat, text only - no images, no fancy stuff other than a few bold and italics and inline code tags, and I could visibly measure the delay between typing and the text appearing on the screen.
That should never happen, regardless of whichever other fancy features the app _might_ be able to do.
> video calling, audio calling, screen sharing, file sharing, permissions, media files
Back before Apple dumped half the features and renamed it Messages, iChat had literally all of these features and then some and it was fast. It was efficient. It didn't run my CPU up to max no matter how I was using it nor how much, and it used very little RAM for an application in its class. It ran very well on hardware that Slack would choke to death.
Slack is the way it is because Slack has other priorities above being fast and efficient, it's not inherent to the nature of a chat app with AV calling, screen sharing and file sharing (file sharing was table stakes for a chat app even 15 years ago or more).
Telegram has done it twice, since both their cross-platform and their native apps are speedy, and they're different codebases started by different people.
Slack/others got where they are by not paying attention, not because it's all that difficult.
There is an unofficial one for Mac (i.e. not actively developed and anyway not by the core devs) - Seaglass. Pretty much dead/abandoned.
Besides, irrespective of what the founder (or someone) might say/indicate at times I really don't think Matrix/Riot is looking to compete with Telegram/WhatsApp/Signal. They are trying for a pie of what Slack and the kind have. I am giving up on Matrix as well for it to ever be a personal IM app/service. It' just doesn't make sense and biggest reason for that not happening are:
- People are not going to bother finding different instances, or host their own - they just want one service, one server
- The UI of Riot is specifically designed for group/team chats and I don't think they will try to stand in two boats in one app or have two separate apps.
- There's no money in personal IM apps. So unless there's a coffer like Fb/Telegram or someone like Acton donates handsomely at some point there isn't much there other than just being another Diaspora but in instant messaging space.
> It’s just that devs are now used to shipping 100MB apps in the name of fast development
Reminds me of that time people where upset they had to download a hundred MB OS update file instead. Turned out someone forgot to downscale some installer images from the raw bitmaps. After that the update was actually a few MB's.
What overhead? You don’t run any optimization step on your code? I haven’t seen a single front end project without package.json in years in all the companies I consulted for, and I don’t even deal with fancy frameworks.
People were going to work in Italy in non-essential industries until recently. Those workers went home to their aged parents. Countries with lower rates of working aged adults living with the elderly are likely to have higher infection rates of a particularly vulnerable age group than those where such living situations are less common.
I totally get why people delivering great content want to maximize their readership this way, but I've never read an article on that site before, so how would I know if its worth giving my email?
@Kye - After seeing the crap that comes on the History Channel, I don't know if I can trust anything anymore. National Geographic might just become National Geothermal Signatures of Alien Presence... But that's just my ignorance of NG speaking.
Are you going to press the rerun tests button on every project every day in perpetuity? No one does that. If you're going to automate something to deal with this (that either reruns on dependency updates or just every day), then you can make that automation ignore or update your lockfile, and then the big problems in my post stay solved. If you run into a problem with a new version of a build/test dependency, then your project stays working for developers in the meantime until it's solved.
What’s the point of reproducibility in your team but not with your users (which is by definition the most common use case)?
Libraries should skip lockfiles because they are ignored by the end user and therefore any testing you do based on them helps no one.
I’ve had lockfiles being broken for no reason* so if you can avoid them, do.
* For example, multiple versions of the same package were installed after several install/updates, but nuking the lock would avoid this issue and solve the problems it caused.
If your code has 20 if else in a row I don’t care if it’s performant and has no bugs, you’ll get a change request because I don’t want to maintain that pile of garbage.
There are minor code style preferences and others that affect maintainability. Just because it works now it doesn’t mean the code is done.
Yes, there are conventions that are generally harmful to code maintenance. For these things the preferred approach is screening via some sort of automated gatekeeper whether its unit tests, code beautification, better custom types, code validation, or something else. If a developer isn't willing to do the work to automate these subjective concerns then their complaints really need to be something measurable. Everything else isn't worth the energy when instead you could be productively writing the next hot feature.
How that code example a style violation? I am not even sure how it's bad code. In JavaScript that would just return a value without the first index. What code style rule would solve for that in a meaningful way that you are willing to enforce uniformly on all concerns?
It is because if a file is made of a hundred 1-line functions that’s not good code. The separation of concerns is likely not meaningful and it’s detrimental to the reading/understanding of the file.
Why create a function that shortens/clarifies nothing and is used once? If you want to explain some code, use a comment, don’t make spaghetti
