Linen.dev: A 500 kb Slack alternative
linen.dev
linen.dev
> 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.
What tool did they use: Browserify, Webpack, Gulp, Rollup, Babel, Parcel, ESBuild, etc.
And this looks like the PR for the icons update: https://github.com/Linen-dev/linen.dev/pull/1001
The bus gets fixed eventually. This doesn't (unless somebody fixes it).
Unfortunately, the current state of ESM in Node is such a mess that you can't assume most packages are tree-shakeable. There is package.json metadata to do that.
It's more likely to be a "simple" bug (with far reaching consequences) in react-icons' package.json and/or build process.
Taking a quick glance at https://github.com/react-icons/react-icons/blob/master/packa...
Yeah, it's using the old non-standardized "module" field as opposed to the modern and mostly standard (now at least) "exports" field [1] or "type" field.
"exports" would be a quick fix of the existing package.json file with no other changes to the build process, but given this is a UI package intended primarily for browser usage I'm having a hard time understanding why it bothers to include CommonJS at all and isn't just `"type": "module"` and remove CommonJS from the build entirely.
That probably points to why this hasn't been done yet: it gets into a bikeshed argument and a lot of potential discussion on big changes to a presumably "not broke" build system.
[1] https://nodejs.org/api/packages.html#packages_exports
(ETA: Existing Issue on this subject in that repo: https://github.com/react-icons/react-icons/issues/717)
https://webpack.js.org/guides/tree-shaking/#mark-the-file-as...
All popular bundlers (webpack, rollup, esbuild) respect that field.
The intro community discussion page at https://www.linen.dev/s/linen does need to load 20+ javascript files for some reason to show the latest messages.
Whereas messages still show up even if javascript is entirely blocked, just starting from the beginning in 10/2022 (?).
So I'm not quite sure if it's as optimized as it can be.
They provide a full framework but you can also download SVGs.
ex, an s3 only Java sdk:
https://stackoverflow.com/questions/35591248/aws-sdk-for-s3-...
You need to have two calls at least, generate a signed URL and then actually uploading it. How many lines on the client would you guess that requires? My guess is less than 30, and you cover 100% of your use case without putting in any 3rd party code what so ever. Sounds like a solid win with few drawbacks.
Is there an easier way to verify this than, say, observing the final bundle size and looking inside the JS bundle? I'm not a frontend developer so this is outside my usual area of knowledge.
[source-map-explorer]: https://github.com/danvk/source-map-explorer
[Lighthouse Treemap]: https://umaar.com/dev-tips/270-devtools-lighthouse-treemap/
I notice that if I lower the bar and allow half baked hackish solutions to slip in, beyond some point, upkeep consumes infinite time. There seems no way back from that besides starting from scratch.
There is no good reason for front end things to break. I can only think of document.writeln() but who in his right mind...
Any possibility of you sharing your "codemod script" so others can potentially implement it too? :)
Always fascinated when I hear that JS term for what's essentially dead code elimination.
Tree shaking only looks at the imports and removes code that isn't imported from the bundle. If code is imported but not executed, then tree shaking won't remove this code, even though it is dead code.
Using a different term is reasonable to avoid confusion, in this case.
For one particular microsoft product, this is brought to attention by documentation: https://learn.microsoft.com/en-us/power-apps/developer/compo...
It's usually a call you need to make based on what you're shipping, but at the very least, it'll ensure you don't blow up your performance because something slipped by.
Finally, looking at the components of your bundle if you haven't already is well worth it. Like the people over at Linen noticed, they were shipping a ton of icons they were never using. This is happening all over the internet, and it's a real drag on the network, parsing, and executing phases in a browser. If you benchmark, you'll see significant differences when you trim things back.
If you have customers using lower powered devices, this is even more crucial.
You can get a feel for what it looks like here on an active project here: https://app.relative-ci.com/projects/TMqufq6bi8qzsOjEHSWY – but mostly you end up using the status pushed to GitHub PR's
I totally agree with the need to run bundle analysis checks often for medium/large-size applications. It will help to notice the issues when they are introduced, otherwise, the optimization task becomes really challenging. Actually, I built bundle-stats & RelativeCI after spending weeks on optimization tasks running hundreds of slow builds, staring at multiple webpack-bundle-analyzer reports, and using google spreadsheets to track asset/module changes.
One thing I noticed in the last 2-3 years is that we got better as an industry at managing the bundle size bloat: - improved libraries - new light versions for popular libraries - new and improved bundlers - new and improved meta frameworks - better tooling & more resources
However, the web applications we are building now are larger and more complex than before, with hundreds of bundled libraries and tens of thousands of modules. The increased complexity has made the bundle analyzing and optimizing even more complicated. One of the most common feedback I received was to better integrate the bundle analysis and insights during the code review phase and allow developers to detect and fix the issues as soon as they are introduced: - [done] Pull request comment with bundle analysis insights & summary (https://relative-ci.com/documentation/setup/configure/integr...) - [in progress] pending/approve/reject review flow based on custom rules
Google-Searchable and community focusedThe latter sounds like I need to be a Slack or Discord user, and Linen makes the conversations searchable on the web. But the title (Slack alternative) makes it sound like I can use Linen instead of Slack.
Which is it?
After spending some more time it seems to be a chat app that allows importing.
god it's HARD to search on discord.
why anyone ever thought hyperactive gamer chat was the right way to offer community and support to their tech product is beyond me
I also don't want it in Slack - Slack is office chat for my job, I don't want to be adding random other stuff in there
Please just use a forum. Discourse seems to be the good/popular one.
Honestly it's a shame that forums aren't a big thing anymore.
I especially loved the look and feel of systems like phpBB or SMF forum software. Just really nice readability and usability, good organization of everything and pretty limited hardware requirements. I'd argue that even better in some ways than Discourse, despite its more modern look.
The only problem was that due to how they were deployed (and how many of the PHP codebases were structured), it was challenging to deal with updates and/or plugins.
Discourse is so horrible people would rather use Discord or Reddit - that's how horrible it is.
I think I recognise the Discourse forum software across several sites I've used (correct me if I'm wrong about any of these these someone!):
- https://forum.rescript-lang.org/
- https://discuss.huggingface.co/
- https://socialhub.activitypub.rocks/
- https://discuss.pytorch.org/
- https://forum.strapi.io/ (maybe)
I don't know if it's a pain to run for maintainers or something, but as a user I have found the experience on these sites infinitely preferable to Discord
Thank god someone else like Linen is trying their shot at it, before Discourse kills forums by being terrible.
Genuinely don’t know how you prefer it to anything, the only thing it has over Discord is being searchable, the rest is obnoxious. The giant avatar bubbles, the random large numbers thrown everywhere, hiding easy to navigate features from forums in favor of endless scrolling, list goes on.
The issue is the public side of projects that are using Slack or Discord to answer questions. Those questions have to be answered again and again by the poor employee instead of the answer being searchable (via Google, or other search engine).
One very minor friction point with Linen was, it needs to be a bit transparent about their pricing for business tier. I don't think "contact us" pricing strategy is the perfect fit Linen's target audience.
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 yet
For anyone interested in HN-type forums (with lots of other features we've built)
Obviously HN+ is missing the single most important thing about HN, the users.
Also, did you really have to steal the name too? Would probably been better off if you called it something different.
By the way, you should read your own terms of service and maybe start following it yourself if you ask others to follow it too?
> Your site is not getting advertised via unwanted electronic messages such as spam links on newsgroups, email lists, other forums and web sites, and similar unsolicited promotional methods;
> Your site is not named in a manner that misleads your readers into thinking that you are another person or company. For example, your site’s URL or name is not the name of a person other than yourself or company other than your own; and
congrats on making the right choice
This is more of an IRC/forum alternative to me (which Slack originally was) until it is possible to use Linen instead of Slack.
Or just as a Slack plugin for the public Google search aspect - but this is absolutely incorrect to call it a Slack alternative for anyone who is using Slack as Slack. Things video/screen sharing/drawing huddles, integrations, SSO and permissions, slackbot, OCR search, notification settings etc aren't just a different of features - it makes it a different platform and tool entirely and solve different problems.
Expect this to become a paid offering at some point.
Initial and middle Investors kept passing the pie to the next bigger fool and the last bigger fool is now stuck with a very expensive web property desperate to recoup the investment let alone a 10x return.
Sounds like a Bitcoin food chain.
And then - aggressive monitization, price hikes staff cuts, SLAs adjustments etc.
In current economic climate if a VC is only getting 4x return on their initial investment and not the usual 10x, they'll say "oh wait, we think this 4x is still over priced, market might slump further and we care for our reputation so much therefore, please pay us only 2x" or they'll say "selling at 4x would ruin our reputation therefore let us not sell at all"?
This is the classic VC cycle, companies get sold to the next one for higher gains till the last buyer cannot find any further buyer that can pay even inflated prices neither the stock market responds that much so they end up squeezing every bit of juice of the company by raising prices, reducing free features and what not.
Heroku is one example.I can count a dozen more.
On a general note I think you should link back to your landing page from the navigation of a project. Especially if people enter via a search engine, they are essentially locked within an organization. The only way out is to manually navigate to linen.dev.
Zulip is the only software I've found where you can catch up on weeks of conversation extremely quickly. It's fantastic. I never felt that I lost messages, unlike Slack, and it's very responsive, again unlike Slack.
I wish all the locked away Slack communities would use Linen[1] because there are so many nuggets of bug-fixery buried in Slack that will age off or never be found in the horrors of Slack search
1: I really wish they'd just stop using Slack entirely since Zulip is open source and bundles this "allow search engine indexing" built-in, but I think that ship has sailed
In my experience, Google search results are poor these days, prioritizing esoterica or blogspam instead of useful insights due to decades of SEO battles. I prefer to hear what folks I'm directly interacting with are saying when they make a recommendation instead of jumping to the old "LMGTFY" silliness we all smugly passed to others circa 2008 who forgot to RTFM/RTA.
Asking intelligent questions, but doing some of the legwork yourself would get better results in my experience. Wasting people's time by asking them with 0 context provided (so they know your level of expertise) often gets them to repeat to you what could have been discovered in 30 seconds. You waste your time. You waste their time. It's a selfish thing to do.
I disagree, evidenced by the many other commentators who clearly wanted to discuss. I feel the only time wasted has been in trying to police comments on a comment thread eliciting uncurated information. Have a good day wherever you may be.
I disagree. I don't think anyone has tried to police anything here. I sent you down the best path to get the information you wanted quickly, and I was the first one to reply to your question. You're welcome. Have a nice day.
Web client is responsive and has good shortcuts.
Easy-ish to self-host, cheap to buy hosted.
Configurable privacy.
Integration with all sorts of stuff, including email.
A little lacking in community moderation tools.
Text-mode client works acceptably well over a low-ish bandwidth connection.
IOS and Android clients.
Open source.
And, perhaps most relevant to my complaint, they offer hosting for open source projects (unlike Mattermost which is ... like, "send us email and we'll think about it" or something). I would guess Mattermost would feel the most comfortabe to Slack users, since I admit that Zulip has a different mental model than Slack, but I believe it is much better for ongoing thread management once one gets used to it (IOW, had they won the fight, it would be Slack that would be the "eww, what is going on with this threading model?!")
---
https://github.com/zulip/zulip#readme (Apache 2!) just as a contrast to the sibling's LMGTFY comment :-(
The bold text being the same size and weight as the username while having the same alignment, the reply icons being the same size as the user icons, no real spacing difference between the username and post content vs the username and post above it, the spacing in general mostly separates things rather than organize things... and that's just from looking at one screenshot. Compare it to a screenshot for slack: while there are surely things you might like more than the slack interface, you can deny that through holistically manipulating alignment, spacing, text size and weight, scale, etc. you can instantly visually parse what's grouped and what's not, what are people's usernames, what's message content, what's metadata and what's reaction/reply content, etc. all while packing more on the screen. Simple things like visual hierarchy and gestalt do a lot of work for them.
That stuff is crucial for an efficient corporate messaging application that needs to be easily visually parsable.
UI design (and most other visual work) is much deeper and more difficult than most developers realize. Laymen familiar with CSS frameworks can make something that looks designed in their estimation, but when it comes to functionality, it falls flat every time. This is why we need more designers in FOSS.
Different people have different use cases. Many people-- support, customer service, incident response, etc. need to be able to parse those screens incredibly quickly all day long. The small amounts of time that people spend visually orienting themselves on these pages not only takes up time, it unnecessarily imposes a cognitive load. While you could have a code editor that used the glyphs, cursor, and layout of a word processor, and a low-volume coder might not even care, for most developers, it would just be exhausting to visually parse all day long. For many people, communication tools are essentially their code editors and their work is often far more time sensitive than a developer's.
We had an IRC server. IT and Ops used it.
We moved to ejabberd. IT, Ops, and a couple of devs used it. Not all.
We moved to Zulip. Everyone in the company uses it.
Nothing sounds like that big a deal unless you seriously try it in a company setting. I tried it once and there's no going back, I miss it every time I have to use Slack or Discord.
I haven't used it yet, but in general excited by projects like Linen and Zulip. I hate Slack and Discord (I love the web, deep links, and indexability/searchability)
Do people consider Slack search subpar?
I haven't used a chat app with a better one. Discord is abysmal by comparison
There's also the tangential fact that open source shouldn't be relying on proprietary communication protocols that are difficult to migrate away from or make it difficult to maintain anonymity.
import hljs from 'highlight.js';
Do you really need Mathematica, "ISBL", and "GML" — or would a curated list of popular programming languages such as Python, Java, JavaScript, and HTML ("xml.js" ) be enough? This results in a massive reduction down to ~70 kilobytes.
Even better: load this reduced size of highlight.js only on demand, leveraging Webpack's "import(..) to webpack chunk" mechanism:
const getHighlightJs = async function() {
let result;
if (window.hljs) {
result = window.hljs;
}
else {
result = (await import('highlight.js/lib/core')).default;
const javascript = (await import('highlight.js/lib/languages/javascript')).default;
result.registerLanguage('javascript', javascript);
const xml = (await import('highlight.js/lib/languages/xml')).default;
result.registerLanguage('xml', xml);
// xml provides html/html5 highlighting
window.hljs = result;
}
return result;
};
const lazyHighlightAll = async function() {
let result = null;
// see https://highlightjs.org/usage/
// highlight.js's hljs.highlightAll() matches on 'pre > code'
const hasHighlightableCode = document.querySelector('pre > code') ? true : false;
if (hasHighlightableCode) {
const hljs = await getHighlightJs();
hljs.highlightAll();
result = hljs;
}
return result;
};
document.addEventListener('DOMContentLoaded', function() {
lazyHighlightAll();
});The one you complain about is specifically about importing everything, because that's what the user wants in that case, importing it like that signals that that's what the user wants.
Otherwise you can do the following:
import hljs from 'highlight.js/lib/core';
import javascript from 'highlight.js/lib/languages/javascript';
hljs.registerLanguage('javascript', javascript);
76K node_modules/highlight.js/lib/core.js
20K node_modules/highlight.js/lib/languages/javascript.js
Edit: I see now their budget was actually more than 1MB actually, as they for some reason only "really care" about gzip'd sizes... Then I wouldn't say it's so bad to just say fuck it and do it the easy way. Saves any latency introduced by lazy-loading it too.
The two different variants written are six of one half a dozen of the other. There's nothing stopping you from writing the imports + register in one file and dynamically importing it in a dom loaded event in another.
They'd move begin searching for a new solution.
Some would recognize they should substitute their language.
Then a tiny fraction of users will actually read your documentation :)
disclaimer: OSS founder here that cares a lot about managing community!
We think that there is a better chat app out there that isn't built yet that handles things like: 1. A non chaotic notification system. Slack and Discord stresses me out. We want to introduce things like !mentions which sends you a push notification and @mention notifies you but doesn't interrupt you. 2. Better thread and content management. Things can get messy in Slack and that you can't find information. We give you ability to move threads and messages around to help organize that and we want to do more to help people find content. 3. More power user features: Slack is probably the most used app for a lot of us and I don't think it is optimized for individual productivity. We want to build something that is designed for our productivity. Something along the lines of Linear or Superhuman.
apples and oranges?
Also, I seem to recall there was some drama about if one used Ripcord against a Discord server, it resulted in your account getting banned
while(1) malloc(1000);
Is only 0.02kb and will bring your computer to a crawl.
Meanwhile I can just write a IRC client in C that's less than 100kB.
As somebody that used irc a lot in the day, it's ridiculous to suggest that a protocol that doesn't even save chat history is being compared to the feature rich chat apps of today.
They're also much more wasteful of resources, and needlessly proprietary ecosystems.
I'm going to put Linen on my list and I'm curious to see where it's going. The concept of a searchable alternative to 'closed' communities like Discord is promising.
I'm wondering, though, if it's essentially a real-time chat experience that perhaps focuses on speed rather than depth.
I only realised this after reading your comment. That was an unexpected/pleasant surprise.
I found a 'typo':
> Get branded colors and logos of your community or company. Your community should feel like yours and not
The sentence does not
Slack is mostly IRC with persisted history and threads.
Do I really need all these API keys for s3, sentry, push service, ngrok, etc to run a web app on a home network?
can it replace slack basically ? what will i have to do ?
I'm probably too dumb. clicked some 20 places and still nothing. only find their unlinked to source marketing nonsense "Linen is an open source".
Want a lean Slack alternative? Use IRC. Want a fancy Slack alternative? Use Matrix.
I want rich messages, images, links.
I want threads.
Anyone has usable threads yet? For the life of me I can't follow Slack threads.
Given that we're talking about search-engine-visible logs - just use an existing, public server.
> I want my messages to be synced between multiple devices including mobile ones.
I actually believe it's better for people _not_ to have Slack on their mobile, so as not to be pestered, but if that's what you want, then you want the "fancy" alternative. Matrix clients can offer you that.
> I want rich messages, images, links.
So, Matrix.
> I want threads.
If that's the case, maybe what you really want is a Discourse web-forum rather than Slack.
See discussion 7 years ago on serverfault.com, and the links therein:
How to set up a IRC server that logs all messages? https://serverfault.com/q/190069/113898
How to Offer Searchable IRC logs? https://serverfault.com/q/36886/113898
The bot option should be valid for Matrix as well, although there I'm not sure the bot world is well-enough developed to be 100% sure that a bot exist for every common desire like saving channel logs.
It's not too pretty though, but definitely usable: https://view.matrix.org/room/!SzcRUxcpYurpoctOzk:matrix.org
For me, the biggest barrier for adopting an alternative to Slack (or Facebook Messenger) is that no one else will switch with me.
It would be great if Slack could simply become an API for a chat client I prefer.
> Violating your privacy by sharing or analyzing your data is a criminal offence.
Uh, yeah. I don’t think that has ever stopped anyone. We have had companies literally spraying the personal info of all their customers all over the internet, and as far as I know they’re still running.
I’m in some communities who are currently looking for slack alternatives, that may not want their chats to be logged and shared online beyond the chat tool itself.
Page open:
Firefox: 18.5MB
Chrome: 12.1MB
After browsing:
Firefox: 27.14MB
Chrome: 11.7MB
Doing a heap snapshot will give you a better view of the page memory usage in isolation, without involving the browser itself.
Still, optimised code is cool.
find small packages for pagespeed metrics
serve 100mb of ads and analytics
It sounds like an exercise for a CS student's first TCP/IP program.
Is it just me, or does anyone else think that there's something wrong about the modern Web when a chat program taking 500kb (gzipped!) is an impressive technical achievement to be proud of?
It's something I didn't realized until I started coding it: every detail that you omit from your chat UX is a tragically noticable pain to the user used to WhatsApp and Slack 100 times a day.