Live data from Hacker News

Linen.dev: A 500 kb Slack alternative

linen.dev

31–40 of 219 posts

Re: Linen.dev: A 500 kb Slack alternative

#31
post #19

Earlier quoted context omitted.

Sorry about that. It was a vestige of Linen's first version being very Enterpise sales heavy and we haven't updated it. At the moment it is 150/month for 5000 members for our paid tier and 50/month more for every 5000. Will update it this week! We just shipped our self checkout flow last week: https://github.com/Linen-dev/linen.dev/commit/61c482cab5d5aa... Just hadn't got the chance to update it on the landing page y…

Reasonable for enterprise, but that's pretty high for my tranche in small business. Any possibility of matching Slack pricing for super small (<20)?

Oh yeah we're planning on introducing pricing for teams soon. Right now we've been focusing on communities. So will have something out for teams soon!

Re: Linen.dev: A 500 kb Slack alternative

#36
How's the search? Our company moved to self hosted Rocket Chat from Slack a while ago, and while it's acceptable in general, the search is literally the worst search I've ever used in anything ever. Can't even find an exact match in the currently opened thread.

Re: Linen.dev: A 500 kb Slack alternative

#37
Not enough discussion here of the parts under "Our Optimization Strategies", which was the most interesting to me. Assorted reactions:

> We found that react-icons had an issue that lead to everything being imported. This meant that we were including every single react-icon in our package whether we need it or not.

Kudos to the Linen team for proactively finding this - I have a feeling tons of projects blindly trust that tree-shaking their dependencies will "just work" even though for many libraries it won't!

> We also noticed that we were only using AWS client for s3 upload on the client side and it was taking up significantly more bundle size we need so we replaced the entire client side package with a 2 api calls to the AWS api.

For such a minimal use case, this feels like a logical choice even if it's slightly more work to implement.

> We ended up moving the code highlight code to a backend api that would cache the results.

Love seeing websites make smart choices about which work to handle in the server versus the client.

Post reply on HN