A lot of people already "live" in Slack (i.e., slack has a 'network effect', same with Discord) and so naturally I think people are more likely to engage with my community on a tool they are using because of work (their company is on slack). How does Linen think about addressing that concern?
disclaimer: OSS founder here that cares a lot about managing community!
Sure thing! We support a two way sync between Slack and Discord so using Linen doesn't mean you have to migrate off of either. The end goal here is that we eventually build enough features that more and more people would prefer Linen in the long term.
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.
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
Hey, glad you found information that works for you!
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.
It's the first result, and has a landing page with all the information you need. Maybe you should really Google that first.
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.
> 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 feel the only time wasted has been in trying to police comments on a comment thread eliciting uncurated information.
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.
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?!")
I think Slack has realised there are shortcomings in their threading as I just noticed today in the iOS app that there is an option to re-join a threaded comment back to the main channel after it's been sent to a thread.
The functionality is amazing but the UX/UI is not polished to the level of a commercial product like Slack or Discord (or Twitter, which it is arguably more comparable to)
Clean and functional perhaps, but based on that screenshot, I would agree that it needs a lot of UI work.
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.
A lot of non-developers that use some cobbled together amalgam of tutorial code pasted into wordpress themes never have any performance problems with their site. If people are using these things for their own personal projects, then who cares. If they're posing them as in industrial tool, someone with a better vantage point should probably tell them they're about to step in shit.
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.
At a previous company the price of Slack went up and the two alternatives were Zulip and HipChat. We ended up suffering through HipChat until Atlassian finally killed it.
Unfortunately for Zulip, it's one of those things that you have to experience to understand how great it is. I can tell you all about its speed, its great UX, about how easy the threading model makes discourse, about how it's open source, about how it's a joy to navigate, etc.
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)
I personally don't think Slack is a great product for open communities. While I don't think they're actively hostile to open communities it's certainly not their priority from a feature perspective. In my view, Slack is an enterprise product, and Discord is more of a commercial product. It's very difficult to be both and gain necessary market share.
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.
We actively evaluated Linen in launching our community. Although, we went with discourse as we are going for a forum type community platform but Linen certainly has fantastic potential.
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.
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!
> Love HackerNews? HN+ includes everything you love about HN to start your own.
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
You must probably be using 16-bit computer because on my x86_64 system Firefox's about:processes tab shows 45-65 Mb of RAM usage after opening this page and scrolling. And Firefox's builtin tools tend to show smaller number than real usage: htop shows use of 85 Mb of PSS (proportional set size, that properly accounts for pages shared between processes).
Or you must be measuring something more than just the memory Linen uses, like measuring how much memory the tab itself takes, which is Firefox + the application.
Doing a heap snapshot will give you a better view of the page memory usage in isolation, without involving the browser itself.
I think linen definitely solves a lot of issues OSS communities face when the majority of issues are answered on discord/slack. The need for such a tool should decrease as docs mature however. So maybe a tool to integrate with or update the docs could be cool.
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.
Not to take away from Linen, it seems great, but whenever I see new chat software I lament the fact that Zulip isn't more popular. It's super fast, and its threading model is amazing.
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.
VC game will get crazy. Most VC backed products will have their end day like Twitter has almost.
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.
I doubt it, VC firms and their principals have a reputation, and the community is not so big that they can endlessly pass the buck like this, without suffering consequences.
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.
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.
I believe several (most?) IRC servers support logging channel transcripts; and those can be easily made web-accessible. If you're not running the IRC server, you can use a logging bot to do that.
See discussion 7 years ago on serverfault.com, and the links therein:
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.
For Matrix – view.matrix.org, as noted elsewhere in the thread. Instead of a bot, it's a lightweight Matrix client which doesn't support auth, and renders everything server-side.
I'm a big fan of IRC and have used it for many years, but one thing I notice about younger generation of techies is, they won't tolerate poor/low tech UI/UX. I see this in gaming all the time as well ... old classic games, esp. RPGs, dont get love because of the graphics and UX (keyboard controls).
I would half-agree with you. In much of the younger generation, there is a fetish for a certain kind of UX: The kind that reminds you of a smartphone; low density; anti-keyboard-orientation; maybe I could add a few more characterizations maybe. The thing is, though - that UX is often inferior - in itself, or because of it relies on very heavy infrastructure like a browser engine.
How does this compare to Ripcord[0]? Granted there haven't been any new releases of Ripcord in a couple of years, it's super lightweight and mostly perfect for my uses.
IIRC, ripcord works perfectly fine as a Discord client (used it myself for some time) - but if you have ripcord and Discord clients running at the same time, logged into the same account, Discord's anti-spam measures are triggered, and your account gets banned.
Discord support refused to reactivate my account, so I had to pester the Discord security lead on Twitter - who was so nice to reactivate it.
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.
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.
they had to change every import for an icon in 60 files. Wouldn’t it have been better if a PR was done against Rollup to fix this “bug”? probably much more difficult/not possible?
A commuter typically takes a free public bus ride to work. The bus broke down this morning. The commuter had to go out of their way to take a different bus to get to work. Wouldn’t it have been better if they stayed and fixed the first bus?
I get the proverb but you have to admit that it's kind of a big deal that a tree-shaker bundler optimizer has a pretty big glaring known broken issue with it where it doesn't bundle.
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.
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.
Many javascript programmers including library authors don't understand the tree shaking mechanisms available to them. Setting the "sideEffects" property in package.json can be very effective in detailing whether to include/exclude an entire module or certain source files:
> Love seeing websites make smart choices about which work to handle in the server versus the client.
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.
With icons, I've stopped using icon libraries a while back and now import just the SVG code that I need. I'm a big fan of Hero Icons[1] and they offer a way to quickly copy JSX or SVG code to the clipboard to faciliate this workflow.
FYI there is a middle ground with the AWS SDK. If you don’t need the entire thing (you certainly do not), you can import product specific SDKs as standalone. Still quite a bit fatter than building your own HTTP client, but it’s an easy win if you already use the SDK.
But also, if you're just making two API calls (the use case for Linen) which are using JSON, you can get both request making and json parsing pretty much out-of-the-box without doing anything, web browsers JS API ships with this by default, window.fetch and response.json(), no "building your own HTTP client" required :)
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.
That's a good trick for JSON-based AWS APIs, but the S3 API is all XML AFAIK. I had to fix some signing bugs in the unofficial Haskell AWS SDK, and found it rather fiddly and a fair bit more than 30 LoC. Compared to standard AWS SigV4, S3 is also a special case in a few ways (request chunking, support for presigned PUTs with unsigned payloads, etc).
Ah, good point, but of course the browser also ships with APIs for dealing with XML, not doing so would be weird as HTML and the XML structure a pretty fundamental part of the web. See XMLHttpRequest, XMLSerializer and DOMParser.
If you are using pre-signed urls, or public objects, then there is really no reason you need to use an s3 library, any old http client will work fine. But if you need to authenticate the request yourself, then you have to deal with the somewhat complicated process of signing the url, headers and body, if applicable. It isn't terrible, but it is probably more than you want to do if you have a library available.
> 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!
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.
i just write everything from scratch every time. (so don't take my advice)
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...
The same thing happened in a past job for me — we discovered we were included every single icon in FontAwesome. I wrote a codemod script to refactor how we were importing icons so it was treeshakeable. Cut load times from 10s to 2s — was glorious.
As far as I understand it, that's because it's different. Dead code elimination analyses the code and removes paths that can't be executed.
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.
> 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!
It might be worth testing different variants of the landing page copy. The version I see is this:
Google-Searchable and community focused
Slack alternative
Sync your Slack and Discord conversations to Linen and get SEO benefits while reducing customer support load
The 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.
And that's a pity because I got really excited by the prospect of the alternative. It made my gears start spinning for viable ways to accomplish that. Oh, the ideas I'd work on if I had unlimited time...
If you're interested in the alternative of an indexing app, you might like https://www.answeroverflow.com/! It's also open source if you want something to contribute to (for the record i'm the developer of it)
It's because a lot of projects - not just open source (hell, my laptop manufacturer is now linking to their Discord for support) - have moved their support to Discord, and finding anything on Discord is a huge pain, even if their indexer decides to work that day.
There's a different problem I'm not sure if they've addressed, namely that Google chooses what it wants to index and finds relevant, meaning it's not certain your data will be indexed.
> 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.
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
Marginally better than discord, substantially inferior to older forum software. Still a pain to get going.
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.
I don't see why you'd think it's bizarre. Using Google for inbound links was practically Stack Overflow's raison d'etre. If someone searches their question, finds an answer almost immediately via a search engine (doesn't have to be Google), and never bothers your customer support agents, then both parties are better off.
So don't use it for corporate conversations? There's already Slack for that. Corporation's private internal communication just isn't the target market.
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).
It always seemed to me the basics of a messenger app would be the easy part to be accomplished. It's the marketing that would be hard seeing as there are already existing solutions such as Slack and Discord.
I like Mattermost and Zulip: they have paid plans, but are also fully open source / self hostable, so you know your data stays with you if that's what you want.
218 comments
[ 3.4 ms ] story [ 246 ms ] threadwhile(1) malloc(1000);
Is only 0.02kb and will bring your computer to a crawl.
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.
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.
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
https://www.hn.plus
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
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.
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.
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.
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
find small packages for pagespeed metrics
serve 100mb of ads and analytics
[0]: https://cancel.fm/ripcord/
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
> 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.
[1]: https://heroicons.com/
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...
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
can it replace slack basically ? what will i have to do ?
The 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://discuss.ocaml.org/
- 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).