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

Zulip 3.0: Threaded Open Source Team Chat

blog.zulip.com

Post reply on HN
Print view View original

91–100 of 134 posts

Re: Zulip 3.0: Threaded Open Source Team Chat

#91

Post by fareesh »

tabbott wrote: post #32
fareesh wrote: post #19

Unrelated question - I went to chat.zulip.com in the browser and signed up. Scrolling through the messages (pixel xl2) is incredibly laggy. If I were to build a similar UI on some project, what's a good way to ensure good scrolling performance on the web?

I notice you mention a pixel phone; are you by any change using mobile Chrome? I think this is https://github.com/zulip/zulip/issues/14943 , which sadly didn't get fixed for this release but is being worked on. Generally Zulip's scrolling and view-switching is very smooth and a ton of work has gone into it (my view is that if an app that you use all day isn't snappy it's going to waste tons of your time). The short a…

Seems to be the case. Scrolls fine on Firefox

Re: Zulip 3.0: Threaded Open Source Team Chat

#92

Post by price »

AceJohnny2 wrote: post #85

I found Slack's design discussion on how they decided for single-depth threads interesting. There's a balance to strike between powerful features and usability. https://medium.com/slack-design/threads-in-slack-a-long-desi... Of course, people here have self-selected for favoring threads, but Slack's attention to the silent negatives is interesting and a lesson in product design.

In the context of this post, an important thing to add is that threads in Zulip also have just a single level of hierarchy - it's not at all like the tree structure here on HN, or on Reddit. We've felt that single level is the right balance for having a conversation that someone else can come to an hour later and easily read and follow.

The way it works in Zulip is quite different from Slack, though. Here's a description in another comment in this thread: https://news.ycombinator.com/item?id=23863588

Re: Zulip 3.0: Threaded Open Source Team Chat

#96

Post by Legogris »

jlokier wrote: post #34
isbjorn16 wrote: post #6

Earlier quoted context omitted.

They are the primary reason to use Zulip. In this way, Zulip is more of a Teams competitor than it is a Slack competitor. I, frankly, cannot stand threads. I want a chat room, not a realtime forum. I understand why people would like that, but it still bothers the shit out of me. I work for MS so we have to use Teams, but I'd prefer opt-in to threads vs. threads by default. I fully understand and accept that my way is…

> The good news is there are tons of options for people to choose what fits best for them! That's super exciting! Personally I'm finding it a bit of a nightmare, as just about every community I'm interested in seems to require a different tool to be installed. Same for work clients. Worse than that, some communities are fragmented into different IM tool groups. The plethora of IM and other tools needed to stay vaguel…

> Matrix is an attempt, but by no means a solution.

Care to elaborate why you think so? (Obviously it's not there yet, but does anything make you think it won't?)

Re: Zulip 3.0: Threaded Open Source Team Chat

#97

Post by pm90 »

eigenspace wrote: post #18

A group of us in the Julia open source community have been trying to migrate to Zulip [1] from Slack. There's a lot of resistance from some community members, but those of us who made the switch are quite happy. The topics model is fantastic, having proper markdown and LaTeX support is also killer. The development team for Zulip is also really responsive and friendly. Coming from Slack, it was a breath of fresh air t…

Nice, I wandered on to the Zulip Chatroom for Quarkus. It didn’t take me very long to figure out the interface: it was very intuitive, and I absolutely LOVE the syntax highlighting support AND topic centered conversations! For technical conversations when you gotta share a lot of code, it makes a HUGE difference when you can share code snippets that are easy to read. Slack allows this with the upload a snippet feature but it’s hard to use and the UX of snippets is kinda atrocious.

If I were to start a new community, I would absolutely go with Zulip.

Re: Zulip 3.0: Threaded Open Source Team Chat

#98

Post by neumann »

I love Zulip. Not only does work smoothly and with no bugs, it was one of the least painful installs and maintenances of any recent service I've tried to self host.

I've tried to get traction with it as a self hosted solution at a few orgs instead of cloud offerings, and often meet with resistance by ITS in party because of the pains of administering a lot of these products. However, one I have succeeded pushing it through the feedback has been, 'Great, it just worksout of the box. We don't have to deal with it regularly'.

Re: Zulip 3.0: Threaded Open Source Team Chat

#99

Post by aero31aero »

dzonga wrote: post #94

the codebase is beatiful, however this is a nasty gem: https://github.com/zulip/zulip/blob/2374e25b941977e95493ebe4... . if it was me, I would've broken that into at least 3 models

Good point! When I was new to the Zulip codebase I thought the same but after a while, my views changed. Its a very long model (and file) but very linear and organized, so it doesn't have that usual set of problems for which we have the common wisdom of not having long classes or methods.

Basically, for this you have to ask yourself why you want to split it and what would you split it to. If ultimately what we'll get is something like UserProfileA, UserProfileB, UserProfileC, then that's arguably worse than one long UserProfile.

Re: Zulip 3.0: Threaded Open Source Team Chat

#100

Post by nikisweeting »

dzonga wrote: post #94

the codebase is beatiful, however this is a nasty gem: https://github.com/zulip/zulip/blob/2374e25b941977e95493ebe4... . if it was me, I would've broken that into at least 3 models

Having worked in Django a lot I actually quite like big UserProfile models, they're significantly easier to manage at scale than several (often overlapping) smaller models. The migrations are less tedious, and it's easy to see "everything" for a given user in one place.
Post reply on HN