Show HN: Linen.team – A lightweight, thread-first Slack alternative
Modern workplace messaging apps (like Slack) are based on IRC, which is great for small groups, but as it scales, breaks down quickly: you either get overwhelmed by notifications or you have to turn them all off. Most chat apps have threads tacked on but aren't built from the ground up with this design in mind. We wanted to create a thread-first experience where you can organize and prioritize conversations so that you are not reliant on notifications to make sure you don’t miss anything.
In apps like Slack, you have to check activities, channels, threads, and replies just to make sure you aren't missing anything important. We designed every message in Linen to belong to a thread, so it makes it easy to centralize everything in a single location. We let you select which channels you subscribe to from your inbox. This way, your inbox only has the important channels. This makes it easy to keep track of conversations without having to rely on notifications to make sure you don’t miss anything.
We also wanted a better way to separate urgent vs. non-urgent communication. In Linen, we have introduced the concept of a !mention that is designed for urgent/time-sensitive messages. A !mention will send a push notification, whereas an @mention will show up in the person’s inbox. This allows us to encourage more async conversations and reduce the need for the number of push notifications. We also designed the mention system closely with the inbox so that even if you aren’t subscribed to channels, mentions will still appear in your inbox. This is great for joining partner teams where you don’t need to view every conversation but do need to respond when you are mentioned.
We believe that most messaging apps are secretly to-do lists in disguise; you have to read, respond, or do some task when you receive a thread. We wanted to give you the ability to manage threads individually. We let you mark each thread as done, which hides them from your inbox and is useful to keep track of tasks. You also can set reminders and mute threads with one click/key. With these features, we make it easy to get to a zero inbox state. This combined with the inbox makes it easy for you to keep track of conversations and make sure you don’t miss anything.
Linen is designed for power users. We love keyboard shortcuts and want an experience that is keyboard-first. For many, the messaging app is the app that is used the most. We believe that you should be able to use Linen for an entire day without touching the mouse. We’ve added modern features like CMD+K for navigation. We’ve designed Linen to be fast and lightweight. Our gzipped bundle size is 400KB, so it's fast on first load, and we’ve introduced multiple layers of caching to make sure things are fast on subsequent loads.
We’ve been working hard on this app for the past 6 months, so there are still gaps in the platform. But we’re also very excited about the direction we can take. Our focus is on what a modern message platform built in 2024 should look like and what lessons we can take from the previous decades of IRC and messaging apps. If our message resonates with you, we would love for you to give us a try at https://www.linen.team/signup?callbackUrl=%2Flinen, where you can join our public community and come say hi!
68 comments
[ 3.2 ms ] story [ 46.5 ms ] threadFinally, after a year, we actually reduced our client bundle size from 500kb to less than 400kb. You can see our post on bundle optimization here: https://news.ycombinator.com/item?id=35718417.
https://github.com/neurosnap/starfx
Sure TTFB (& potentially other web vitals) are better with SSR, but I still keep hearing SEO friendliness as a primary reason for SSR though prevalent crawlers like Google/Bing can index js loaded content.
"""
figured out what ruined egghead's SEO and dropped our monthly traffic 90%...
broken SSR
anybody that tells you search bots don't require SSR is full of shit
"""
https://twitter.com/jhooks/status/1757086865348522109
> Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines. Instead, we recommend that you use server-side rendering, static rendering, or hydration as a solution.
https://developers.google.com/search/docs/crawling-indexing/...
and:
> Crawlers may understand JavaScript, but there are often limitations worth being aware of in how they render. Client-side rendering can work, but often not without additional testing and leg-work.
https://web.dev/articles/rendering-on-the-web#seo_considerat...
Secondly we are a bit more opinionated in thread management. Our inbox is designed to get to an inbox zero state. We have things like !mention vs @mention which helps with urgent vs non urgent communication.
The other upside of Zulip is that it is very easy to self-host.
Slack's UI with activity and all that went down significantly from their latest update. Shocked they haven't switched back. Community feedback from what I gathered is extremely unhappy users.
My biggest use case is talking to people on other teams (Slack Connect.) How is that managed here?
Also, what is the narrative around adding users and billing? I hate that every time I add someone to slack for a project need to make a buying decision (are they a full user, guest user, active vs inactive…) Is it possible to pay for users when they’re active, and not have to worry about managing seats when projects end?
Pricing wise we're still figuring out. I do think paying for active users is a likely direction though!
But if you want to replace Slack, you need to focus on the developer community and third-party integrations right now. We're not paying for something that only gives us "just" chat with better-by-design UX and chat workflows. Teams is free and fits this purpose, at least in the eyes of an executive.
Slack's developer environment (outside of Grid features, the new "Premium Workflows" and "Next Generation Platform") is first-class.
At the very least start with some webhook integrations.
Also your Privacy Policy has no mention of Amazon Web Services, I think you might want to review your "DATA PROCESSORS / SERVICE PROVIDERS" section.
Also, are you planning on offering single-tenant options? Not a fan of our chat data sitting with a bunch of other organisations.
Thanks for checking the privacy policy will update to include AWS!
Perhaps it is true from developer perspective, but from management perspective I welcome clear chat as it is without bells and whistles of countless integrations.
Slack at current state of events turned into colossal distraction and time waster.
All those integrations have nothing to do with comm platform IMO, they are well belong to other business processes.
I think the market has spoken and your view is in the minority I'm afraid. There is a non-zero chance that Windows 2030 Enterprise will throw away the start menu, the desktop, the app store, File Explorer, etc. and replace it all with TeamsEdge (Teams + Edge).
As the view being a minority, it’s true, no surprise to that in current paradigm.
Yes, PHP is old and not sexy. But it works.
Not everyone goes to the cloud by default. There are many orgs out there that want full data sovereignty for better infosec without relying on someone else's servers.
Can/will you maintain this devotion to optimization when shipping a a desktop client? If it could not be Electron, that would be great.
I love the differentiation between ! and @. There are many times when I want to inform a group without bothering them.
Our bundle size has actually only gotten smaller since we’ve shipped our first version. We know it will gradually grow but we try to be disciplined in not using too many external dependencies
Cheers to that. It’s unfortunately an uncommon belief.
All we need now is for someone to give every Linen user an externally accessible handle that allows cross-tenant invites or 'thread sharing' and we'll have officially closed the loop.
It DOES feel like it "could" be that holy-grail between IM, project management, email, etc.
But I feel like you need a whole team all onboard for it to make sense.
"Oh and if you'd like to talk to someone from outside your company, my god have mercy on your soul if their entire business isn't also subscribed to our premium plan" - someone at Slack, almost certainly.
either way, you can just turn off desktop notifications.
De facto other people already have control of interruptions, but with umpteen concurrent notifications (sometimes in multiple places, like DMs to say "did you see the notification in channel X / thread Y yet??" overlapping the original notifications), how to know where to focus? @ vs ! finally gives people a way to distinguish between inclusion and urgent interruption.
I wonder if there are any alternatives to you and how you compare to them.
Perfect observation. Thank you for focusing on this reality. They aren't benign messages; they're summons, pleas, assignments, and to-dos.
I hated threads in slack when they were introduced. However, as with a lot of things (new site designs etc) it helps to give them time to settle in before you decide if you really like them or not and I'm happy to report that now after several years have passed since they were introduced I still absolutely hate slack threads.
They are one of the worst parts of slack. They are where information goes to die, they are easily missed, they are cumbersome to deal with. I would disable them if I could.
Perhaps they work well with huge teams, but I've worked in companies with tens and hundreds of engineers and they have been an unecessary hindrance.