[HN Gopher] Linen.dev: A 500 kb Slack alternative
___________________________________________________________________
Linen.dev: A 500 kb Slack alternative
Author : cheeseblubber
Score : 711 points
Date : 2023-04-26 19:00 UTC (1 days ago)
(HTM) web link (www.linen.dev)
(TXT) w3m dump (www.linen.dev)
| amir734jj wrote:
| I don't understand. Is this just the frontend or backend?
| mgaunard wrote:
| 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.
| hyperhopper wrote:
| 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.
| jdthedisciple wrote:
| It's about how much gets downloaded to your client machine
| stavros wrote:
| 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.
| tinyhouse wrote:
| The main problem with Zulip is that I always end up messaging
| in the wrong channel without noticing.
| stavros wrote:
| Hmm, really? How come? That never happened to me, I don't
| think.
| CoolGuySteve wrote:
| 500KB seems to be the bundle size, how much RAM does the client
| use?
| capableweb wrote:
| At https://www.linen.dev/s/linen
|
| Page open:
|
| Firefox: 18.5MB
|
| Chrome: 12.1MB
|
| After browsing:
|
| Firefox: 27.14MB
|
| Chrome: 11.7MB
| codedokode wrote:
| 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).
| capableweb wrote:
| 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.
| revskill wrote:
| Need desktop app and mobile app.
| gregors wrote:
| It's cool they're using a touch of elixir for the websockets
| apatheticonion wrote:
| Is it possible/legal to create third party chat clients for
| services like Slack?
|
| 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.
| rillweed wrote:
| https://volt-app.com/
| apatheticonion wrote:
| This is cool! Looking forward to Linux and Windows support
| seeing as that's where I spend pretty much all my time
| Aeolun wrote:
| > 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.
| alberth wrote:
| FYI - this is a VC backed project.
|
| Expect this to become a paid offering at some point.
| cheeseblubber wrote:
| We do have a paid offering. Basically it's free on Linen's
| domain for public communities and we let you host on your
| domain like: https://archive.pulumi.com/
| https://linen.prefect.io/ https://slack-chats.kotlinlang.org/
| urbandw311er wrote:
| [flagged]
| wg0 wrote:
| 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.
| MichaelZuo wrote:
| 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.
| wg0 wrote:
| This isn't a game of reputation, fundamentally.
|
| 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.
| Aeolun wrote:
| That wouldn't mean anything the moment they get bought.
| kamranjon wrote:
| If you want you can just host your own no? It's open
| source: https://github.com/linen-dev/linen.dev
| rvcdbn wrote:
| It's also open source under a permissive license so personally
| I see that as mostly upside.
| IceWreck wrote:
| I love that its google searchable which fixes the "knowledge-loss
| after afew days" problem.
| gigel82 wrote:
| 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.
| alexdanilowicz wrote:
| 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!
| cheeseblubber wrote:
| 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.
| vrglvrglvrgl wrote:
| [dead]
| orthoxerox wrote:
| How big is the backend bundle?
| est wrote:
| I remember mIRC was just few hundred kbs as well
| TheFreim wrote:
| 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.
| weird-eye-issue wrote:
| Oh I remember this tool. I submitted a form to be notified of
| their Discord integration months ago and never received anything.
| Is it working now...?
| yieldcrv wrote:
| modern web development:
|
| find small packages for pagespeed metrics
|
| serve 100mb of ads and analytics
| Eduard wrote:
| Ah yes, highlight.js. One innocent import hljs
| from 'highlight.js';
|
| 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(); });
| capableweb wrote:
| 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.
| Eduard wrote:
| 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).
| capableweb wrote:
| Sure, but it's far away from "pulls in over a Megabyte of
| hundreds of programming language syntax definitions" as you
| said: 76K
| node_modules/highlight.js/lib/core.js 20K
| node_modules/highlight.js/lib/languages/javascript.js
|
| 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.
| c-hendricks wrote:
| 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.
| ParetoOptimal wrote:
| 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 :)
| listenallyall wrote:
| 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.
| user3939382 wrote:
| Wouldn't it be possible to make an IRC client+server that's a
| perfect clone of Slack? I guess you'd need a SIP plugin for
| huddles.
| Minor49er wrote:
| 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
| ESQBOJaguar wrote:
| 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.
| dpcx wrote:
| 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.
|
| [0]: https://cancel.fm/ripcord/
| mdaniel wrote:
| > Ripcord is a desktop chat client for group-centric service
|
| 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
| raphman wrote:
| 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.
| dpcx wrote:
| I misunderstood both the title of this post _and_ the
| headline of the article. I thought linen.dev was a chat
| client!
| palijer wrote:
| 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.
| RicoElectrico wrote:
| Honestly "alternative" should be a taboo word for most OSS
| projects, as it is overselling stuff. Manage expectations.
| mdaniel wrote:
| the Show HN: https://news.ycombinator.com/item?id=33248488 and
| there was another thread last year for their main domain
| https://news.ycombinator.com/item?id=31494908
|
| 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
| tomrod wrote:
| Tell me more about Zulip?
| stavros wrote:
| 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.
| breck wrote:
| Recently I saw that the Rust dev community is using Zulip:
| https://rust-lang.zulipchat.com/
|
| 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)
| est wrote:
| also the leanprover.zulipchat.com
| ctvo wrote:
| https://www.google.com/search?q=Zulip
| tomrod wrote:
| 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.
| ctvo wrote:
| 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.
| tomrod wrote:
| > 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.
| ctvo wrote:
| > 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.
| dsr_ wrote:
| It's everything you want in a threaded chat server except
| federation.
|
| 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.
| switch007 wrote:
| It's also a clean, large, modern, type hinted Django
| project which is useful for learning Django
| dsr_ wrote:
| And the killer is this:
|
| 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.
| jamesfinlayson wrote:
| 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.
| mdaniel wrote:
| > Easy-ish to self-host, cheap to buy hosted.
|
| 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 :-(
| ghostpepper wrote:
| 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.
| ghostpepper wrote:
| 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)
| stavros wrote:
| I disagree, the UX definitely is very polished, and much
| better than Slack. The UI, yes, I agree, though I find it
| very clean and functional.
| chefandy wrote:
| 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.
| PoignardAzur wrote:
| I don't know what to tell you, I've never had any
| difficulty parsing a zulip page. And I definitely
| appreciate the sobriety.
| chefandy wrote:
| 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.
| terpimost wrote:
| I heard Zulip team is working on UI improvements https://
| github.com/zulip/zulip/issues?q=is%3Aissue+is%3Aopen...
| chefandy wrote:
| That's great to hear.
| kodah wrote:
| 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.
| pcthrowaway wrote:
| > here are so many nuggets of bug-fixery buried in Slack that
| will age off or never be found in the horrors of Slack search
|
| Do people consider Slack search subpar?
|
| I haven't used a chat app with a better one. Discord is abysmal
| by comparison
| moffkalast wrote:
| 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.
| chatmasta wrote:
| We're happy with Mattermost, and search is quite good.
| dexterdog wrote:
| Even worse than slack's search?
| thex10 wrote:
| 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.
| MuffinFlavored wrote:
| > tree-shaking their dependencies
|
| What tool did they use: Browserify, Webpack, Gulp, Rollup,
| Babel, Parcel, ESBuild, etc.
| billiam wrote:
| It appears that they used Webpack, which I found interesting
| given other alternatives.
| SparkyMcUnicorn wrote:
| The UI package appears to use Rollup.
|
| And this looks like the PR for the icons update:
| https://github.com/Linen-dev/linen.dev/pull/1001
| MuffinFlavored wrote:
| 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?
| reesonz wrote:
| 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:
|
| https://webpack.js.org/guides/tree-shaking/#mark-the-
| file-as...
|
| All popular bundlers (webpack, rollup, esbuild) respect
| that field.
| __ryan__ wrote:
| 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?
| MuffinFlavored wrote:
| 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).
| thaumasiotes wrote:
| I don't think the bus will get fixed unless somebody
| fixes it either.
| WorldMaker wrote:
| It may not be a "bug" in rollup.
|
| 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)
| _fat_santa wrote:
| 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.
|
| [1]: https://heroicons.com/
| badestrand wrote:
| Another one: Material Design Icons,
| https://pictogrammers.com/library/mdi/
| felixthehat wrote:
| Icones is my go to https://icones.js.org/
| docmars wrote:
| Remix Icons are also solid: https://remixicon.com/
| ignoramous wrote:
| ditto for https://iconduck.com/
| riidom wrote:
| Additional shoutout to https://github.com/tabler/tabler-icons
| rickette wrote:
| Used https://lineicons.com the last time around.
| rizky05 wrote:
| Radix icon also good: https://icons.radix-ui.com/
| [deleted]
| abhibeckert wrote:
| If we're listing icons, I use these ones:
| https://ionic.io/ionicons/
|
| They provide a full framework but you can also download SVGs.
| 3D30497420 wrote:
| Phosphor icons are also great: https://phosphoricons.com
| andrewxdiamond wrote:
| 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.
|
| ex, an s3 only Java sdk:
|
| https://stackoverflow.com/questions/35591248/aws-sdk-for-s3-...
| capableweb wrote:
| 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.
| thayne wrote:
| 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.
| endgame wrote:
| 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).
| capableweb wrote:
| 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.
| Karrot_Kream wrote:
| What about retries, status code handling, timeouts, and
| backoff? (It's not a lot of code to add that stuff in but I
| still call it a "client".)
| earthboundkid wrote:
| AWS doesn't do that for you either.
| tbcj wrote:
| yes it does, to some extent e.g., retries https://boto3.a
| mazonaws.com/v1/documentation/api/latest/guid...
| aobdev wrote:
| You linked the Python SDK, just FYI. Here's the
| JavaScript version: https://docs.aws.amazon.com/AWSJavaSc
| riptSDK/v3/latest/clien...
| jve wrote:
| > 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!
|
| For one particular microsoft product, this is brought to
| attention by documentation: https://learn.microsoft.com/en-
| us/power-apps/developer/compo...
| dns_snek wrote:
| > 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.
| throwaway14356 wrote:
| 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...
| niedzielski wrote:
| I use source-map-explorer to see what's inside. Lighthouse
| Treemap provides a similar view.
|
| [source-map-explorer]: https://github.com/danvk/source-map-
| explorer
|
| [Lighthouse Treemap]: https://umaar.com/dev-
| tips/270-devtools-lighthouse-treemap/
| MichaelZuo wrote:
| > 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.
| groestl wrote:
| > tree-shaking
|
| Always fascinated when I hear that JS term for what's
| essentially dead code elimination.
| scott_w wrote:
| 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.
| m00dy wrote:
| I also think terming something in JS culture is much more
| welcoming than the one that thinks dead code elimination is
| the way it should be.
| groestl wrote:
| Ah, wasn't aware of this, thanks for clarifying.
| teddarific wrote:
| 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.
| justinclift wrote:
| Oh, we're using FontAwesome here.
|
| Any possibility of you sharing your "codemod script" so
| others can potentially implement it too? :)
| lagrange77 wrote:
| Looks really cool and promising, i think i will give it a try!
|
| 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
| s1k3s wrote:
| Another one: Rocket, a self hosted open source alternative:
| https://github.com/RocketChat/Rocket.Chat
| anyfactor wrote:
| 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.
| sideproject wrote:
| I've recently launched HN+
|
| https://www.hn.plus
|
| For anyone interested in HN-type forums (with lots of other
| features we've built)
| Aeolun wrote:
| Hmm, I feel like this could do with a different colored top
| bar. Making it look exactly like HN makes me feel more like
| 'why not use HN then'?
| nonethewiser wrote:
| Well for one, you can't moderate hackernews
| Aeolun wrote:
| That is a feature, not a bug.
| capableweb wrote:
| > 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
| [deleted]
| anentropic wrote:
| > we went with discourse as we are going for a forum type
| community platform
|
| congrats on making the right choice
| cheeseblubber wrote:
| Sorry about that. It was a vestige of Linen's first version
| being very Enterpise sales heavy and we haven't updated it. At
| the moment it is 150/month for 5000 members for our paid tier
| and 50/month more for every 5000. Will update it this week!
|
| We just shipped our self checkout flow last week:
| https://github.com/Linen-dev/linen.dev/commit/61c482cab5d5aa...
|
| Just hadn't got the chance to update it on the landing page yet
| tomrod wrote:
| Reasonable for enterprise, but that's pretty high for my
| tranche in small business. Any possibility of matching Slack
| pricing for super small (<20)?
| cheeseblubber wrote:
| Oh yeah we're planning on introducing pricing for teams
| soon. Right now we've been focusing on communities. So will
| have something out for teams soon!
| [deleted]
| Aeolun wrote:
| Does that count active users? Or total users? Be a bit sad if
| you were perpetually paying for some rando that posted a
| message 5 months ago.
| sandGorgon wrote:
| this is very cool! what things of slack does it NOT have -
| genuine question here. Like private channels, etc etc ?
|
| can it replace slack basically ? what will i have to do ?
| 2h wrote:
| seems private chats are not a thing. which is a dealbreaker for
| me coming from Discord. I asked in support so I guess we will
| see.
| rbanffy wrote:
| Commendable, but I am sure there are alternatives that ran on
| machines with less than 500KB of memory.
|
| Slack is mostly IRC with persisted history and threads.
| [deleted]
| fatfox wrote:
| 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.
| wsgeorge wrote:
| > a few seconds later you realise, you're already using the
| product.
|
| I only realised this after reading your comment. That was an
| unexpected/pleasant surprise.
| rado wrote:
| The "Join" modal should trap focus.
| omeysalvi wrote:
| I'm of half a mind to use this as a self hosted note taking app
| csense wrote:
| 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?
| gnrlst wrote:
| 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)
| wkat4242 wrote:
| 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.
|
| Still, optimised code is cool.
| rahimnathwani wrote:
| 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.
|
| Which is it?
| Aeolun wrote:
| Yeah, I had the same questions. Is it a chat app, or an
| indexing app?
|
| After spending some more time it seems to be a chat app that
| allows importing.
| CSSer wrote:
| 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...
| rhyssullivan1 wrote:
| 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)
| accrual wrote:
| Yeah, the "Google searchable" copy specifically is a red flag
| for me. Does that mean I need to let Google index my corporate
| conversations?
| greenimpala wrote:
| 100%, I just closed the tab straight away. No thanks.
| zamnos wrote:
| 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).
| KennyBlanken wrote:
| They are positively _fixated_ on being "google searchable"
| in a way that is really bizarre.
| yunohn wrote:
| That's because they started as a static indexable host for
| Slack/Discord. The real-time chat features appear to be
| brand-new (to me atleast).
| zamnos wrote:
| 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.
| asmor wrote:
| 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.
| anentropic wrote:
| It's hard to express how much I dislike Discord as a user
|
| 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.
| KronisLV wrote:
| > 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.
| waboremo wrote:
| Forums are still used a lot, you would think this would
| result in forum software that's great, but no Discourse
| is a horrible experience by default.
|
| Discourse is so horrible people would rather use Discord
| or Reddit - that's how horrible it is.
| anentropic wrote:
| In what way?
|
| 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
| waboremo wrote:
| 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.
| holler wrote:
| 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.
| asmor wrote:
| I think that's more down to "Google" being a stand-in for
| any search engine. Had they written "indexable" the
| intent would have been less clear.
| joshxyz wrote:
| which is a big plus for open-core companies and open-source
| projects.
|
| god it's HARD to search on discord.
| wilg wrote:
| I won't run any apps over 480 KB unfortunately.
| nonethewiser wrote:
| Why 480?
| esafak wrote:
| Because 480kb ought to be enough for anyone.
| justinclift wrote:
| It's likely them attempting to be funny. ;)
| wilg wrote:
| [flagged]
| peoplearepeople wrote:
| I'm pretty happy to run anything below 640 KiB myself
| ronsor wrote:
| That should be enough for anyone, anyway
| a3w wrote:
| Found the time traveling Bill Gates on HN
| SLWW wrote:
| thanks for the laugh! :) <3
| [deleted]
| bee_rider wrote:
| For me, it will happily fit into L3 cache and it isn't very
| close to fitting into L2, so I guess it is fine.
| exabrial wrote:
| Can we run this locally and _not_ on the cloud?
| freeqaz wrote:
| I'm pretty sure it's Open Source here:
| https://github.com/Linen-dev/linen.dev
| cassianoleal wrote:
| Yeah but there are no instructions on how to deploy and
| operate. No user docs whatsoever that I could find, either on
| their website or on Github.
| asar wrote:
| 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.
| robot wrote:
| show me the demo
| otterley wrote:
| Feature request: Can we get sign-in with Apple, please? It's the
| only single-click auth integration I trust for privacy.
| Manjuuu wrote:
| The size is only one of the factors, it can be small but slow,
| especially when the history grows.
| cheeseblubber wrote:
| Definitely. This is why we also do things like optimistic
| updates, setting query performance alerts, and when possible
| reducing as much DOM elements.
| KMnO4 wrote:
| I agree.
|
| while(1) malloc(1000);
|
| Is only 0.02kb and will bring your computer to a crawl.
| connordoner wrote:
| This made me giggle more than it should have.
| einpoklum wrote:
| 500 KB + Tens of millions of lines of code of a browser + a bunch
| of backend code.
|
| Want a lean Slack alternative? Use IRC. Want a fancy Slack
| alternative? Use Matrix.
| ptman wrote:
| Yeah. Matrix, your choice of client (e.g. gitter.im),
| view.matrix.org if you care about search engine crawlability.
| oblio wrote:
| I don't want to host a server and I want my messages to be
| synced between multiple devices including mobile ones.
|
| I want rich messages, images, links.
|
| I want threads.
| einpoklum wrote:
| > I don't want to host a server
|
| 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.
| notpushkin wrote:
| Linen looks kinda neat though. I wonder if it could be
| morphed into a good Matrix client. :thinking:
| snvzz wrote:
| Matrix does support threads.
| nottorp wrote:
| > I want threads.
|
| Anyone has usable threads yet? For the life of me I can't
| follow Slack threads.
| ComputerGuru wrote:
| Zulip does. But you can't ignore them, you need to embrace
| them and use them all the way.
| doodlesdev wrote:
| What about a Google-searchable alternative to any of these? I
| think this would be one of the main selling points of Linen.
| einpoklum wrote:
| 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:
|
| 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.
| notpushkin wrote:
| 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.
|
| It's not too pretty though, but definitely usable:
| https://view.matrix.org/room/!SzcRUxcpYurpoctOzk:matrix.org
| Eumenes wrote:
| 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).
| einpoklum wrote:
| 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.
| zimpenfish wrote:
| There's also Mattermost which seems a reasonable Slack
| alternative (and self-hostable.)
| steve_adams_86 wrote:
| 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.
| vio wrote:
| 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
| tommoor wrote:
| I recommend RelativeCI for this, have used them for several
| projects - https://www.relative-ci.com
|
| 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
| steve_adams_86 wrote:
| This is really sleek, thanks for linking it! I've always
| rigged these up myself, and this is quite a bit nicer.
| throwaway892238 wrote:
| 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.
| uehfudg wrote:
| where did you even find the source/license?
|
| 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".
| cahoot_bird wrote:
| 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.
| [deleted]
| zvolsky wrote:
| The linked blogpost is a message in the blog channel,
| https://www.linen.dev/s/linen/c/blog. Brilliant!
| what-no-tests wrote:
| Wow I was thinking "slackware" and was amazed it would be only
| 500kb.
___________________________________________________________________
(page generated 2023-04-27 23:02 UTC)