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.
pulls in over a Megabyte of hundreds of programming language syntax definitions.
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();
});
Hightlight.js basically have two main modes of usage:
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);
Maybe the defaults should be different, but a 30 second read of the most basic information available in the repository would reveal how you can use it the way you want too, without any complication that the rest of your comment seems to want to introduce.
But that's what my code does, albeit my code loads only on demand (plus can be easily improved to load any further language dynamically), whereas your code statically bundles everything into the main bundle (if not using proprietary Webpack chunk comments, which I see as antipatterns).
But I agree with you, that you probably want to only load it when really needed, especially if your total budget is 500kb which this would take a big part of it already.
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.
Dynamic imports aren't unique to webpack, they're a standard feature.
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.
90% of time people will use the default unless it doesn't work for them. So if you used a default with a popular language, many people would try copy-pasting and it would "not work" because they didn't substitute their own language.
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 :)
If you're making software for actual end-users, your point has merit. If you are creating a library for programmers to import into their own projects, nope, sorry, RTFM (at least the first part of it) or get lost.
Are third party clients allowed? One thing that has made me avoid discord and most of these sorts of chat apps is that they really hate users having customized clients. There's a lot of cool features that people have made for unauthorized discord client modifications which are technically forbidden which is not ideal.
You would also need to modify both the server and client to handle things like special roles and permissions, invitations, embeds, file hosting, chat history retention, chat search, threads, and custom reacts, to name a few differences
While the optimization is cool and an interesting read - it's interesting to call this a "Slack alternative" when there are only a couple similarities between the products in that they have people sending text messages to channels.
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.
I highly recommend front end devs add a step to their CI pipeline which extracts bundle size information from the build and includes it in pull requests, or something similar. It's great to have eyes on how heavy your bundle is, and keeping an eye on how it changes over time (easy to add as part of the pipeline) can help the team understand when things are trending the right way or not.
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.
RelativeCI founder & bundle-stats maintainer here, thank you for the mention, Tom!
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
It's 500kb javascript. That makes it al lot less impressive, as a lot of stuff will be done by the parser. And it seems to pull in a lot of libraries too.
> If Volt is not open-source yet, how can I be sure my messages and accounts are secure?
> 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 thought perhaps this was another "open-source" "free-unless-you're-a-business" product, but the license is actually AGPL, so you can go host this yourself regardless of use case. You just have to share any modifications you make.
500kB is the size of the web frontend. To that you'd need to add the web browser, the backend, and whatever runtime the backend needs. It's unlikely to be any less than 10MB.
Meanwhile I can just write a IRC client in C that's less than 100kB.
And then you need an irc bouncer as well though. And still don't have a fraction of the features.
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.
Maybe it's just me being slow in the morning, but it's really cool to read the post and only a few seconds later you realise, you're already using the product. :D
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.
Chat is pretty trivial: Everybody logs into a server. One person types a line of text, and it replicates on everybody's computer.
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 the 80/20 ratio - going from working MVP of a chat app takes about 5kb, but then you have literally nothing else that makes something like linen or slack usable for lots of different edge cases (styling, file uploads, channels, UI, etc)
The text chat experience is something that has been so refined over the last 10 years that to meet today's expectations towards it, you need a very surprising amount of engineering.
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.
Instantly sold. I have noticed programs and apps increase in size of the years and I never was really quite sure of why. Functionality had not changed all that much to warrant the change in size. I'm glad someone is thinking about sizes for once.
Does it also support private chat groups and non Google searchable groups if desired?
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.
reply