There’s no wey Slack will let this exist for very long. They are interested in closing their platform, as we’ve seen with the IRC/XMPP gateway déprécations.
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.
This post made me discover the Yue library (http://libyue.com), which in addition to JS also supports C++ and Lua. At a glance it looks like the best cross-platform GUI library for Lua so far!
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.
There’s no wey Slack will let this exist for very long. They are interested in closing their platform, as we’ve seen with the IRC/XMPP gateway déprécations.
I don’t think so. Wee-slack exists for nearly 4 years now, and to my knowledge, they did not have any problem so far.
I guess the Streisand effect is on our side for things like this. Just look at popcorn time…
(I was mostly posting for the wey pun. Sorry.)
Goddammit, I totally missed it ><
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.
Just set wee-slack up, it really seems to work pretty well, I had a bit of trouble with the tokens, but besides that it’s pretty sweet.
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.
This isn’t different enough stack-wise from the Slack electron app to make me want to install it.
Replacing a bloated Electron app…. with another electron app.
I don’t think they got the memo?
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.
Needing NodeJS installed for a desktop application is an immediate non-starter.
If they worked out how to use the OS provided JavaScriptCore and bind that to a native UI library, maybe I’d try it.
But I have very little faith in the Javascript community as a whole.
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?
End users not having to install it, obviously?
End users don’t need to manually install node.js to use Wey, they get a packaged .app which bundles it. https://github.com/yue/wey/releases/tag/v0.1.0
The packaged app would be a bit smaller (node.js installer by itself is 15MB for macOS), I guess…
OK, thats marginally better, but it’s still the same issue as Electron: the whole runtime is distributed (and updated, or not) with the app.
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.
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.
This post made me discover the Yue library (http://libyue.com), which in addition to JS also supports C++ and Lua. At a glance it looks like the best cross-platform GUI library for Lua so far!
What about Rocket.Chat?
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.
Just tried out the release version - looks really good, but I’ve seen some problems with threads in rooms.