"I'm afraid there is no way to disable this at the moment, and it's not in the roadmap to roll back on this feature. That said, we're still in the initial stages here, so our focus right now is listening to feedback as we consider certain changes for improvement as we move forward. You've raised some fair points here, so I've shared your feedback with my team for consideration in the future."
[0] https://github.com/kfahy/slack-disable-wysiwyg-bookmarklet/b...
How can anyone remain a customer of such idiots?
In >15 years what I have seen is that OSS comes with a huge cost of attention - that you'd be better off focusing on your business need.
Running most of these OSS even at a medium employee count scale is a full-team-commit-nightmare. It essentially means your it department now needs a specialist who will be able to handle your org quirks, remember the tweaks and keep baby sitting it. Not to mention many OSS teams (I don't know about the above listed) are ever so sneakily introducing enterprise clauses about usage in their EULA.
I don't want to name names, but even with paid software we are seeing this problem everywhere in trying to host: But at least here, we got the actual developers and experts on a call who can walk us through why x employees are fine and x+1 nukes their system.
This is what happens when you over-engineer things.
IRC is not perfectly good or it would still be used.
IRC doesn't do that, true, but there's a bunch of ways around it.
> saves history, has notifications, search
Trivial to implement in the client.
> IRC is not perfectly good or it would still be used
IRC is still used. Almost everything any fancier messaging protocol does can, and has, been implemented as a client-side feature with little hassle.
... all to save $7/month/person (or less for some competitors like MS Teams) because Slack is, like, too proprietary.
> maintain their own fork of an IRC client in order to implement inline code, images, website previews, etc
These already exist. No need to maintain a fork unless you want to add features that don't exist in it. And since IRC is so trivial a protocol, that's not even hard.
> break IRC's protocol in their client and server to allow text in excess of the maximum line length
You don't have to break shit. Just split lines into multiple messages and piece together messages from the same user when they were also the last one who said anything, or use a character that means "message continues", or any of probably a dozen other ways you could implement that on top of the already existing protocol and that will still gracefully degrade on clients that don't support it.
I'm not saying that a service that takes existing ideas and makes them easier for people to use is bad, I'm saying that the open protocol people are calling for already exists, but because they have tech-brain they'd rather build a completely new protocol because it's more fun.
[0] Not literally, I have no idea what it uses.
Edit: spelling
You can use paid services, or not. It's up to you, but they all interoperate.
That’s not even wrong because nowadays almost all software comes with some OSS contained. So the non oss set is basically empty. I wonder if HN comes with a huge cost of attention because it runs on some OSS lisp?!
It's about how the service handles change (e.g. options to use the old interface etc.) that make the difference and not open source or proprietary.
There are many examples in FOSS that made user interfaces arguably worse and you have a hard time dealing with it, if you still need/want to run the newer version for other reasons.
In an open-source thing, with this sort of productivity-harming breakage, you could worst-case just pay a random freelancer to fix it for you. You don't have that option with Slack.
Personally, I recommend switching to Ripcord as a Slack client. That's what I did some time ago, and I couldn't be happier.
This is developed in QT by one person, and it looks pretty feature-complete to me. I really don't understand why a company the size of Slack invests all their development effort into such a subpar platform as Electron, when a native solution is clearly doable with very limited resources.
Several things I can think of: "quantity is not quality"; JS developers far outnumber everyone; making web apps look exactly the way they want is easy, and they are not interested in platform-native functionality, preferring a "consistent" UI across platforms instead; "premature optimisation" dogma that means no one cares about efficiency anymore.
Microsoft Teams and (later versions of --- they actually moved away from perfectly decent native Win32) Skype also use Electron, and that's Microsoft. That says the size of the company and its resources matters little in things like this.
Its easy peasy with Qt as well. I am the only dev for https://www.sostronk.com/app and it looks (and behaves) _exactly_ as our designer wants it to. (Oh, and this is when I'm also spending time working on backend stories).
> no one cares about efficiency anymore.
That is not true. Discord and friends spend a lot of time for efficiency because they're using Electron. It is not impossible to have a (relatively) efficient application with Electron (VSCode for example), it just takes more effort. Compare that with Qt where performance is free of cost - in the last 5 years at SoStronk, I've hardly ever needed to spend dedicated effort for improving performance. Another example, and I wasn't aware of this till very recently, is the Telegram Desktop app which is Qt as well.
But yeah, I do agree with your first point, the only reason Electron is in use is because JS developers are a plenty. At the end, cost is the #1 thing when businesses make decisions.
When Atlassian finally pulled Hipchat last year I was tasked with finding the replacement. Turns out the one that met everybody's needs best was a local IRCd and whatever desktop client for it people liked.
Some problems have been solved correctly for a while; chat is one of them.
It is very far from a solution in 2019.
I've never had a problem with DCC transfers, but I suspect I'm in the minority.
"It does not keep history of discussions."
Actually, there were several servers which had "MsgServ" bot which would remember your last logout time, and could go back to retrieve all those messages from its logs and auto-relayed them to you, all you did was ask it to replay missed content from x channel and you got it.
"It does not have media embedding."
If you used pIRCh98 as your client you had live video capability and could easily do a quick desktop share through OBS or similar software, but that did rely upon everyone using pIRCh98.
Slack is basically a modernized version of a mix of the best features that IRC clients and daemons and bot creators had.
The only thing slack hasn't seemed to copy yet from all the old IRC stuff is the ability to use mIRC as a desktop file system browser (that was fun to see being coded.)
IRCd - real time, ram buffering of messages. Quassel - reads and stores buffers in a database, allows users to retrieve them.
If only there were some sort of Universal scheme for denoting the Location of a Resource. That would let you map a relatively short string to one of many possible file access services, and put that string in a text chat channel, rather than conflating two distinct problem domains.
Also every server I know and most clients do logging.
So dial back the snark.
How does IRC handle end-to-end encryption in groups?
How does IRC handle editing messages?
Servers can re-send history when a client join. At least InspIRCd supports this (though it's not enabled by default.)
Blowfish normally.
Press up arrow, retype message, or type *correction.
Which specific daemon did you settle on?
Not really looking for replacement though (team is currently on Mattermost)
A lot of reasons... a solution 1) grows to match the size of its budget constraints 2) becomes more complicated the more people with long titles have a say in it 3) becomes more difficult to implement the more people that are working on it 4) becomes less useful the more people there are that can dictate what it does and how 5) fulfills more of the letter than the spirit of its requirements as more hierarchies of people manage it 6) becomes less user friendly as fewer typical users are involved with its development
Though the actual answer is "somebody with power just wanted electron for personal reasons and nobody had the power to turn the ship once it started on its course"
Slack's good at engineering and development. They used to be good at UI/UX, but whoever over there in the text entry product design slot is having a case of the Jony Ives.
>When typing code with ```, Enter should not send the message.
>With this checked use ShiftEnter to send.
So they didn't really provide anything new here, just changed the default behavior.
edit: formatting
Other examples: * The UX around threads is still horrendous, and there's no way to turn it off. * There's no way to turn off "drafts", which still causes me to lose messages I'm working on.
Is this the future we really want?
They're not treating the users who prefer markdown formatting with respect at all. It's basically: "fuck those guys, we want to cater to a different audience".
that said, i take exception with these claims that the user is “an idiot”. it comes off as arrogant to me.
Not sure what their user base looks like now, though.
There is no way to opt-out of this change, essentially forcing everybody into entering text this way.
In my mind bolding/italicizing are nice-to-haves alongside emoji. You wouldn't compromise the entire functional user experience of the central feature of your app for nicer emojis. (at least I hope not).
That's why tech people italicize stuff.
Or, as your reply has highlighted, even with the additional emphasis, people will still fail to read it the way it was intended.
I also hate the new input field but I understand why they turned it on globally. But a strong enough want is often indistinguishable from a need.
As someone who never got into slack, and never found it appealing... How so?
We rarely pick up a phone, and we do not use email. Everything is 100% Slack.
This works well for us. You can bring in only the people you need, you can "star" messages and channels that are important, and none of us have any time to spam/meme the channels, so it's 100% business. We integrate the JIRA slackbot to keep abreast of what is going on in JIRA.
It all "just works" for us.
My employer uses Slack. Our team channels are almost completely devoid of cruft. There are office/location based channels that contain more bloat, but those are easy to ignore and typically don't contain critical information. All of the "all employee" type channels are locked down.
If it is the primary method, you'll miss stuff.
Whether it should, is another matter, and running a one-man rebellion from within is probably not the most effective way to change that.
Four months into that contract I was moved over to a struggling 'Slack' enabled project, to help them work through their ever growing backlog.
I knew someone working on that project and discussed with them the project's use of Slack only to realise it was nothing more than a talk fest and not for me.
So when the project manager approached me, asking if I would like to join in on the Slack discussions, I declined.
Needless to say that did no go down so well.
However, I stuck to my guns and 12 months on my contract was renewed.
To this day Slack is still not part of my daily development life.
As the person asking that question, no. I've heard it's used by some people ... for things.
Just like I've heard some companies use IRC for chat, and some open source projects use Discord where you can join if you feel like it.
I have no idea what its primary use-case is, who its primary audience is, and to what degree it's more critical than IRC or email or intranets to anyone.
Does that answer your question?
Your comment started off about you and was dismissive of Slack. Saying "How so?", in general, is not handled by people as a genuine and sincere question, it's usually laden with an "I don't believe you" vibe, especially with the dismissive nature of the lead-in.
If you had asked instead:
> "I've haven't really used slack, didn't really see the use case. Why can't you stop using it?"
You would have received a better response.
I don't believe that. I think it is a perfectly fine question, and don't find anything wrong with the way the post was worded. Based on my personal experience, I think my interpretation is the general one.
For example, in the case above, was the "How so?" directed at the "immediately stop using it" part or the "have no choice" part? Both?
That sounds like an extremely regional interpretation, and does not consider that the question was asked in good faith, something the HN guidelines specifically ask you to assume[1].
I'd actually be interested in the answer from grand-poster as well, if only because I am a curious asshole.
Not true. There’s several alternative clients.
I don't need ANY changes in my XMPP/IRC client to connect to a server.
But the reason why Slack discontinued XMPP/IRC is clear. They want people to use their shitty app/website.
>so the only way to connect to is via the official interface.
was clearly not about the UI but rather their HTTP way of accessing Slack. And right now there is no other way besides that.
Many folks I’ve talked to don’t realize there are alternative ways to connect to Slack still once the XMPP / IRC endpoints died. They think the only way is using the Slack developed apps. Thankfully, that’s becoming more and more not true each day.
Pedantic Point:
Re: > rather their HTTP way of accessing Slack
Slack uses Websockets. Websockets != to HTTP.
>Many folks I’ve talked to don’t realize there are alternative ways to connect to Slack still once the XMPP / IRC endpoints died. They think the only way is using the Slack developed apps. Thankfully, that’s becoming more and more not true each day.
Which are? Using a proprietary Websockets API is not "another" way if even the Slack app is using that (not sure). The main difference to XMPP/IRC is, that with the later ones not a single line of code needs to be written (not from me and not from IRC/XMPP developers). Just use the client you like, set server and credentials and you are done. That's why there are protocols.
>Slack uses Websockets. Websockets != to HTTP.
port 443 is close enough and http is needed to start anyway :P