I think this is an example of a community of nerds forgetting that we're something like 0.1% of a product's userbase.
I think the perpetual anti-electron sentiment is a strong example of how you need to be careful not to listen to just your most vocal customers. Otherwise you might triple your engineering load without even a fraction of practical, real life, measurable benefit.
This reminds me of an opinion I heard about why not to do full body scans: you'll inevitably find diagnoses that don't actually matter but will affect the patient's quality of life just by being aware of and inevitably defined by their conditions.
Hmm. On reflection I think this is closely related: treat the patient not the problem.
I support the concept of Electron, but my question is - exactly why is it so bloated? Doesn’t it come with a built-in Chromium? Why is that? Wouldn’t it make more sense if it used the machine’s default browser engine? You would need to look out for different browser versions, but we are already doing that for the web anyways.
If not that... then maybe a single electron-specific chromium engine that is shared across electron apps.
This is fundamentally impossible.
But of course getting the major browsers to play along has always been slow Microsoft as mentioned already.
But I understand why it makes sense to skip Electron in its current state
Also, you could have googled this.
(And to be fair, UI development in XAML on Windows is not too different from HTML/CSS/JS i.e. no Drag and Drop absolute positioning, everything is relative with a constraint system bolted on top.)
That being said, creating a native app for 2-3 (depends if you include Linux) different OS with completely different frameworks and maintaining feature parity between them involves a lot of specific knowledge and (probably) separate teams. Even if you have a good budget ("infinite resources" is quite arguable) it adds a lot of complexity to something that already has it. All of that just to somehow have a bit more fluent client (but probably much less polished).
The cost for this change would be very, very difficult to justify.
To make my point clear, I don't believe the current app is so terrible (performance-wise) that's making Slack lose any significant amount of users/revenue.
On the other hand, adding new features to the (cross-platform) app, fixing bugs, etc in a timely fashion will help the business. I'd also include polishing here but rewriting the whole application from scratch for different OS is, IMHO, not worth it.
Why do people believe this? It could be written once in C++ using Qt, Juce, or Fltk and be blazingly fast. This has been done thousands of times over the last few decades. Where does this myth come from?
Can you suggest a couple examples? I’m no fan of Electron, but I don’t see it as being so easily replaced as you seem to be suggesting.
So, it was written once using Electron and is sufficiently fast.
> This has been done thousands of times over the last few decades. Where does this myth come from?
There are surprisingly few cross platform apps written using these technologies that are fast, functional and have any degree of visual polish.
I started an open source Slack client but was struggle to find tractions. Yes the Slack electron client is bad, I hate it with passion but it just works. And most of the users I surveyed think so too. Either they’re not using Slack at all, or they just don’t care if it’s electron/web-based/slow (Stockholm syndrome?).
[1]: https://medium.com/@s_27669/i-am-definitely-maybe-suffering-...
Who says their resources are infinite?
> hasn’t built native clients.
What would it gain them?
And everyday the app will freeze for 5-10 seconds at a time on a 2018 MacBook Pro.
So Slack really only does 1 thing which is a chat app and if they can't do that properly then you have to wonder.
sc.api_call() with strings for the specific API (there are dozens, each with different inputs) always felt like a temporary ducttape SDK
https://github.com/kissgyorgy/gerrit-slack-bot/blob/master/s...
Why not? Theirs has better support behind it and supports everything you listed (RTM api, pagination, async, etc.).
The code is quite clean though.
edit: You also conveniently change your argument once I point out the previous one doesn't hold up.
Excellent, unlike removing a headphone jack; I consider this truly courageous.
