Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open Sourcers Race to Build Better Versions of Slack

wired.com

Post reply on HN
Print view View original

391–397 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#391

Post by hobarrera »

wlesieutre wrote: post #160
alextgordon wrote: post #84

Earlier quoted context omitted.

On OS X, Adium, Textual and Colloquy are predominantly built in HTML. It's hardly groundbreaking.

This is a good point. I'm not opposed to using HTML in an app. Back in the early 00's, I did a decent bit of tweaking my Adium conversation display style. It's useful for displaying that kind of content easily. But there's a difference between saying "I put a webview in my app" and "I put my whole app in a webview". Driving the whole thing from HTML/JS tends to have bad implications for: • Performance (laggy animatio…

UI concistency is horrible with these html-in-a-webview app.

Every app has to re-invent the wheel here, and there's a lot of native controls that don't exist on HTML.

Generally though, window management is unimportant because these apps tend to be single-windowed apps anyway.

Re: Open Sourcers Race to Build Better Versions of Slack

#392

Post by wlesieutre »

hobarrera wrote: post #391
wlesieutre wrote: post #160

Earlier quoted context omitted.

This is a good point. I'm not opposed to using HTML in an app. Back in the early 00's, I did a decent bit of tweaking my Adium conversation display style. It's useful for displaying that kind of content easily. But there's a difference between saying "I put a webview in my app" and "I put my whole app in a webview". Driving the whole thing from HTML/JS tends to have bad implications for: • Performance (laggy animatio…

UI concistency is horrible with these html-in-a-webview app. Every app has to re-invent the wheel here, and there's a lot of native controls that don't exist on HTML. Generally though, window management is unimportant because these apps tend to be single-windowed apps anyway.

They're only single-windowed apps because they choose to be. Colloquy and Adium both let you pull channels/servers out into multiple windows (just like tabs in a browser).

Slack actually does use multiple windows. The sign-in flow (enter organization, enter email address, choose between magic-email or password authentication, enter password) happens in a popup.

What it can't do is pull organizations out into separate windows like Adium or Colloquy. I'm in 3 separate groups on Slack, and sometimes in a conversation in more than one of them simultaneously.

And yeah, I can go open up the second one in my web browser, but it kind of defeats the point of having a "native app" if it's going to be crappier than just going to the website.

Re: Open Sourcers Race to Build Better Versions of Slack

#393

Post by creshal »

MattJ100 wrote: post #371
creshal wrote: post #351

Earlier quoted context omitted.

There is an XMPP extension for it: http://xmpp.org/extensions/xep-0136.html The problem is, there are far too damn many XMPP extensions and too few of them see any kind of real adoption.

XEP-0136 was pretty complex, and didn't see that much adoption. XEP-0313 is a modern replacement, focusing on just the things that people actually need. It's implemented in many servers and clients already (see https://www.zash.se/mam.html ). It's still under development, but it's already in active use by many people.

Great, there's even two extensions on it!

This is why nobody wants to touch XMPP with a ten-foot pole.

Re: Open Sourcers Race to Build Better Versions of Slack

#394

Post by davecridland »

leonroy wrote: post #353
creshal wrote: post #351

Earlier quoted context omitted.

There is an XMPP extension for it: http://xmpp.org/extensions/xep-0136.html The problem is, there are far too damn many XMPP extensions and too few of them see any kind of real adoption.

Pretty much this. Openfire for instance only recently had XEP-0136 implemented across the board on the server side. In the meanwhile I couldn't find a single client with decent support for chat archiving (XEP-0136) on the client side. Not one (and I really looked).

What? Openfire has had XEP-0136 for literally years. I think a little over a decade, actually. It's only recently implemented XEP-0313.

Re: Open Sourcers Race to Build Better Versions of Slack

#395

Post by davecridland »

creshal wrote: post #393
MattJ100 wrote: post #371

Earlier quoted context omitted.

XEP-0136 was pretty complex, and didn't see that much adoption. XEP-0313 is a modern replacement, focusing on just the things that people actually need. It's implemented in many servers and clients already (see https://www.zash.se/mam.html ). It's still under development, but it's already in active use by many people.

Great , there's even two extensions on it! This is why nobody wants to touch XMPP with a ten-foot pole.

So either XMPP is bad because it hasn't changed for years and is therefore old, or else XMPP is bad because there's new replacements for stuff that didn't work so well.

Honestly, there's some days I wonder if there's any way to win.

Re: Open Sourcers Race to Build Better Versions of Slack

#396

Post by davecridland »

creshal wrote: post #393
MattJ100 wrote: post #371

Earlier quoted context omitted.

XEP-0136 was pretty complex, and didn't see that much adoption. XEP-0313 is a modern replacement, focusing on just the things that people actually need. It's implemented in many servers and clients already (see https://www.zash.se/mam.html ). It's still under development, but it's already in active use by many people.

Great , there's even two extensions on it! This is why nobody wants to touch XMPP with a ten-foot pole.

So either XMPP is bad because it hasn't changed for years and is therefore old, or else XMPP is bad because there's new replacements for stuff that didn't work so well.

Honestly, there's some days I wonder if there's any way to win.

Re: Open Sourcers Race to Build Better Versions of Slack

#397

Post by leonroy »

davecridland wrote: post #394
leonroy wrote: post #353

Earlier quoted context omitted.

Pretty much this. Openfire for instance only recently had XEP-0136 implemented across the board on the server side. In the meanwhile I couldn't find a single client with decent support for chat archiving (XEP-0136) on the client side. Not one (and I really looked).

What? Openfire has had XEP-0136 for literally years. I think a little over a decade, actually. It's only recently implemented XEP-0313.

Hi Dave, firstly thanks for all the hard work on Openfire over the years, very much appreciated.

Secondly regarding XEP-0136 support in OF. I did state that Openfire has only recently had 'XEP-0136 implemented across the board'.

Whilst the Open Archive plugin which provided support is a fine piece of work it was an incomplete implementation with only 1-to-1 chats (no group chat support).

I worked on merging the monitoring and open archive plugins to provide support for both MUC and 1-to-1 using XEP-0136. That work was only fully finished a couple years ago in 2013 so think my comment's still accurate.

Post reply on HN