Wee-slack has an extremely niche appeal. They can afford to ignore things like that because the target market is tiny. I only hope that Wee-slack doesn’t get cut off when Slack does decide to kill this new one.

Remember that a lot of companies didn’t have problems making compatible products until companies like Microsoft and Oracle were hitting them with copyright suits claiming API ownership or patent suits over core functionality. Any group is at risk in known and unknown ways if their work builds on proprietary work by a profit-motivated, selfish company. Double true on average if it’s public like Slack intends to be.

And even if, then the best case scenario is still to be tolerated by the owners of a proprietary product while donating them free labor to play cat and mouse with their protocol.

This reminds me an awful lot at the times when I used GAIM (nowadays called pidgin) because that allowed me to chat with my school friends on ICQ even though I was on Linux which wasn’t supported by ICQ itself. GAIMs was really nice, but broke from time to time when ICQ modified the OSCAR protocol, until the developers catched up.

The author, Cheng Zhao, works for GitHub on Electron and before that worked on node-webkit, which is now known as NW.js. The stack is Yue (cross-platform native UI library) and Yode (Node.js fork with GUI message loop), all of which he also wrote based on lessons learned from Electron.

I think that lumping it all into one bucket doesn’t acknowledge the progression they’ve been making with each new library and/or approach.

I’m curious what the tradeoffs of Node vs JavaScriptCore for a JS engine in this kind of application are.

For platform-specific stuff like UI widgets, certainly agree that using anything that platform ships with is a plus. But from the point of view of developing a cross-platform framework, having a common lower layer like node.js means less platform- or language-environment-specific quirks to work around. What’s the case for not using it?

I was quite intrigued by this, and the Yue framework it runs on, since it seems to be on a similar path to what React Native would look like on desktop.

I think frameworks like these (native UI with logic running in a separate JavaScript thread) are promising, but in this particular instance was disappointed to find the main message pane still running in a webview.

Please limit the size of pull requests under 300 lines, otherwise it would be rather hard to review the code. If you have a big feature to add, please consider splitting it into multiple pull requests.

This is amazing to have in a contributions guide, and I wish it was more prevalent. I think developers believe splitting things into small chunks slows things down and adds unnecessary overhead, but given how faster small PRs are reviewed they’re usually landed earlier and more frequently than their bulkier counterparts. Developers initially hate breaking up PRs so it’s good to have this sentiment front and center.

I guess the target audience is less in people who are free to choose their means of communication but more in people who are forced to use Slack if the wan’t to keep their current job. Like so many proprietary products before, Slacks secret of success not so much in its technical merits as in its marketing department.