Show HN: Linen.team – A lightweight, thread-first Slack alternative
27 comments
If this is just a replacement chat tool, it's fine - and a great start.
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.
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.
> We're not paying for something that only gives us "just" chat with better-by-design UX and chat workflows
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.
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.
> 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).
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).
Whether it is market forces or just company shenanigans to make the product irreplaceable, can be a subject of a different discussion, albeit I tend to think of latter.
As the view being a minority, it’s true, no surprise to that in current paradigm.
As the view being a minority, it’s true, no surprise to that in current paradigm.
Anyone in here ever heard of IRC or am I too old now?
Definitely agree on developer community and third party integrations. That is our main focus after this launch. Building just a good quality chat tool took quite a bit of time but we understand how important the dev ecosystem is.
Thanks for checking the privacy policy will update to include AWS!
Thanks for checking the privacy policy will update to include AWS!
Well... first class...? It's first class in the sense that it's proven good enough to help them to become successful. But in the meantime it's a hot mess of deprecations alongside unfinished thoughts alongside convoluted docs that give you a runaround. So, not first class APIs in the way developers speak about, for example, Stripe.
Some technical notes:
This is actually a fork of Linen.dev, an SEO-friendly Slack alternative for communities. We originally built Linen.dev with Next.js but ultimately found it quite limiting when we wanted to make things fast and responsive and have custom caches. For Linen.team, there wasn’t a need for server rendering since we didn’t need our product to be SEO-friendly. We removed Next.js and replaced it with Vite and Express, which simplified our code quite a bit since we didn’t have the legacy requirements. We also spent quite a bit of time optimizing the performance and query so that it is much faster than the previous version of Linen. Our plan is to open source Linen.team as well; we need to do some repo clean-up first.
Finally, 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.
Finally, 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.
Tangentially related, and agree with the complexity and churn that Next introduces, but curious: If am building a product where SEO matters, does SEO still really suffer in absence of SSR?
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.
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.
Google says:
> 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...
> 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...
This guy from egghead.io learned how much SSR actually matters for SEO:
"""
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
"""
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
Interesting. Thanks for sharing.
It's interesting to hear about the move away from NextJS. How does your express api look?
It's a restful api that doesn't hold any state, we use jwt (jsonwebtoken) for auth. It's essentially a collection of routers for different actions. Mostly crud, with few exceptions like webhooks, auth flow. We often use middlewares e.g. for things like validation. Everything is written in ts/tsx so the client/server do share types. We serialize data to use it in a standarized/known format in the UI.
If you like the middleware system in express you might be interested in starfx, which implements the same middleware but for fetching and data synchronization in the FE. It has a simple but powerful state management system and leverages structured concurrency to manage side effects.
https://github.com/neurosnap/starfx
https://github.com/neurosnap/starfx
To be clear, this is not a dig, but I love that we're basically coming full-circle back to email, just without any of the decentralization and inter-tennant interoperability that comes natively to email.
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.
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.
Seriously. Shortwave before it pivoted to AI, before it pivoted to Google Inbox replacement, was attempting to be slack for email. You can still see parts of this alive in the UI today. But it was a dream to just have a really good mailing list UX over a slack channel. I don’t like Slack, but it has a serious moat and a lot of folks were nervous about blending internal chat and external formal email. Which once you get to a certain scale you realize Slack doesn’t work and all large notification streams eventually turn into a crappy version of email without labels, filters, search, or etc
> crappy version of email without labels, filters, search
"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.
"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.
Taking the long road back to Delta Chat? https://delta.chat/en/
Thanks! Linen is secretly email in disguise. We have played around with syncing with email clients which would let you manage all your messages and notifications from one client.
As someone who has officially given up on having any semblance of keeping up with the never ending fire house of totally unmanageable slack threads, channels, DMs etc, especially since Slacks update last year, I would sell my left Kidney to just have one big list of things I need to look at at reply to/dismiss.
That sounds similar to Basecamp tbh.
I've actually REALLY wanted to find a project that would be suitable to give base camp a try with.
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.
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.
> 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.
Perfect observation. Thank you for focusing on this reality. They aren't benign messages; they're summons, pleas, assignments, and to-dos.
Perfect observation. Thank you for focusing on this reality. They aren't benign messages; they're summons, pleas, assignments, and to-dos.
A few days ago I felt guilty for asking something from a colleague in slack.
Another small suggestion - 14 days seems way too short for a trial; most SaaS trials are 30 and I often end up emailing for extensions before onboarding a new vendor. This is not a cost skimp, it's to avoid making the wrong decision.
How does Linen compare to Zulip?
One thing that we wanted to do was to create a design that was more modern and a bit more familiar to the average Slack/Discord user. I think zulip is great but can be a bit more overwhelming. We wanted to keep a familiar UX as much as possible while giving the benefits of a thread first experience.
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.
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.
Trying to understand - how is Zulip overwhelming? I am a user of both, and I find Zulip to be way more pleasant, easier and less noisier than Slack.
The other upside of Zulip is that it is very easy to self-host.
The other upside of Zulip is that it is very easy to self-host.
Today I just tried Zulip, in order to join a dev community. Yes, coming from Slack/Discord background, I felt like Zulip is a bit too much
That sounds good, thanks!
> 400 KB
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.
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.
We actually tried shipping a desktop client with Tauri and Rust. It helped with initial bundle size but performance and resource consumption was kind of similar. We also ran in to issues with the api’s being bit limiting. Most likely we’ll revisit the desktop client with Tauri but depending on how mature the api is we may have to resort to electron.
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
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
> we try to be disciplined in not using too many external dependencies
Cheers to that. It’s unfortunately an uncommon belief.
Cheers to that. It’s unfortunately an uncommon belief.
Isn't that what a channel is for? (Ie if it's not urgent, you post it to the channel, if it is urgent you @name them so they get a push notice)
Ever hear about Levels by Derrick Reimer? Seems like this is trying to accomplish the same thing. He eventually shut it down though. Looks like you got YC funding though so that’s huge!
Pricing is a tricky endeavor but personal opinion --- $9 per user per month is a little excessive just for messaging compared to the competition.
Yeah, that's more than what Slack charges with almost none of its features. To me the lack of huddles would be a dealbreaker, they really made quick ad-hoc sync ups better.
Indeed - Twist has been doing this thread-first slack alternative thing for a while and even that is $6/user.
> threaded messaging app
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.
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.
This looks really nice. It’s similar to Slack, but still has it’s own distinctive feel.
The ways in which slack is different from IRC are it's worst features, as a developer. The fact that you've told us that you're focusing on what makes it most different from IRC is not encouraging.
Awesome! I’ve been desperately looking for a slack alternative. In part I want something more lightweight, and nowadays there are so many little upsells that get in the way.
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?
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?
One of the pain point I've actually seen for Slack is Slack Connect becomes disorganized very quickly to the point where you need a custom solution to manage it. I think it is a symptom of the overall problem with Slack. Since Linen is thread first it makes manage these conversations much easier. We do plan on shipping our own version of Slack Connect or even integrating with existing channels.
Pricing wise we're still figuring out. I do think paying for active users is a likely direction though!
Pricing wise we're still figuring out. I do think paying for active users is a likely direction though!
Going to check this out for funzies. I do love Slack threads but not something you can force. Discord threads have much to be desired in their UX/UI. My least "favorite" of theirs in fact. Losing the colocation of information is extremely negative impacting to an organization.
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.
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.
When I sign up it asks me for a display name, but after I sign up it has completely ignored that and instead added the part before the @ in my email address.
heh, makes me wonder if they're stepping on the same bug I reported https://github.com/Linen-dev/linen.dev/issues/814
Any reason you're using rest for a chat client? Maybe socket scaling limitations of the node/express stack. Not as bad as php whci slack is still mostly written in, but hard to beat the mostly Erlang stack for discord.
It also makes it's lot easier for bot dev having a two way connection without the hassle of ngrok etc.
We use Elixir for websocket/real-time updates but crud stuff like settings, creating channels etc are mostly rest.
Very humorous to see another comment bashing PHP, which scales just fine for Slack.
Yes, PHP is old and not sexy. But it works.
Yes, PHP is old and not sexy. But it works.
Very interesting, I was looking for a lightweight team collaboration tool yesterday. I like ClickUp/Wrike/etc. but even their home page feels slow, before signing up.
I wonder if there are any alternatives to you and how you compare to them.
I wonder if there are any alternatives to you and how you compare to them.
Is there a way for automations to post messages with web hooks? That's usually the easiest automation-type feature to implement on the platform and for users
Any tests done on scaling? How’s the search? Maybe because of the nature of slack but I use advanced filters very frequently to find old messages.
We've actually done test on scaling. This is a fork of Linen.dev which had community of up to 50k members. So we've tested this well. Search is an on going feature we are working on. We're going to enhance it with more embedding like search functionality.
How do you distinguish your product from Twist? I like the two levels of mentions, but that's not enough to convince me to jump by itself.
Here is Mix0r, a thread-first "Messageboard for Anything" type site: https://www.willashani.com/gigabots/db. I built it because I wanted to use a site like Twitter but with messageboard-like threads. I also believe that every post belongs to a thread so it can be easily referred to. And I too, think think that a thread-based app can be used like a todo-list. I have some examples there.
Do you have any plans to release a desktop-compatible bundle?
Yes we will! We've shipped a desktop client previously with Rust(Tauri) but their api's were a bit lacking. We'll be revisiting it very soon
I have no words to describe how bad is the ! and @ distinctions: it means you give control of your notification to other people. I can see it abused 100 different ways (and if you do build for large teams, and don't expect abuse, then you're either never been on any large enough service, or never talked with anyone in a minority group).
Contrary take: Thank goodness! Finally a useful distinction between "we want to include you" and "you must interrupt what you're doing to look at this now, now, _NOW_!"
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.
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.
other people being able to choose wether something is "hey this might be relevant to you" level vs "Hey, this needs your attention now" is something i actually like, given how right now MSTeams just has an @ that it always treats with the same level of urgency.
either way, you can just turn off desktop notifications.
either way, you can just turn off desktop notifications.
! basically functions like @ in Slack and chat applications. The only difference in Linen is that we give you an @mention so that it doesn't necessarily need to send a push.
[deleted]
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!