Yup. It’s privately held, not a community or non-profit-held registry.

Anything ran by Microsoft is a privacy concern (includes Windows, Teams, npm, GitHub)

You’re in a privacy-related space that values keeping data away from the corporations—that’s why your response has a worse ratio. If you don’t want your messaging data with data with Meta or Google, why would you be okay with Microsoft for your code? I like that instead of acknowledging the multitude of options you would have that puts your project in better position for contributor privacy, you chose to attack the one you disliked the most, mailing lists, & dismissed everything else. It’s really not any more difficult to pick up something like Codeberg & the UI loads faster too.

If someone said “WhatsApp is what I know, why should I care about your $MESSAGING_APP?” would you not, like, send them the output of your project to explain how their digital privacy is at risk? Consider building another list comparing code forges & see that you get little extra from MS GitHub being closed, proprietary, centralized, for-profit/publicly-traded, requires accepting Microsoft ToS to create an account, search locked behind auth, slow to load, slow to fix bugs, has outages constantly, locks out all users from Yemen et al. due to US sanctions, plays ball with capitalists (such as following record label demands to take down youtube-dl), pushes ‘social’ features (massive can of worms), tries to monopolize the developer space on the network effect, etc.

This is how the capitalists & oil barons will sell your government on Global Warming like: “actually it’s a good thing the world is warming”

Define covers… With something like Mumble for instance, you can host a server (real server, not Discord ’servers“), have low-latency real-time chat with noise cancelation algorithms, directional audio, etc. & it comes with a chat you can use, it’s just not very robust. But there’s also a decent chance your group or whatever isn’t using all of the features & could be happy with IRCv3 & XMPP since you can share text, image, videos. My biggest gripe tho is that some communities use it as a replacement for forums or Atom like you were supposed to read & follow every thread because they want to shoehorn Discord as the one-size-fits-all tool. The other issue is not treating that sort of chat as ephemeral–opting to assume users want or need the entire history (which reminds me that I should do a better job with my bookmarks & note taking than relying on search); but also while the history is ‘permanent’ it’s not publicly accessible in the cases where community decisions should be seen (such as making roadmap for an open source programming language) where those not present for the conversation may have missed it, have trouble referring to it, & the search engines can’t find it since it was locked behind Discord’s walled garden.

In a lot of communities historically & still operate in a manner where important discussions & long-lived threads live on the forums, and real-time chat is treated as social or one-off questions/tips. Operating your community with two different tools here is okay… even a third for say video conferencing if it’s not something you do often, especially if it means one or more cogs in that wheel of communication can be non-proprietary.

Additionally I missed adding mailing lists as an option as well as Zulip for forums/chat.

In my opinion SPAs are simply a progressive enhancement for MPAs which allow even faster page navigation.

While I agree that there is a spectrum (hinting at that with the last paragraph), this is where I hard disagree. To construct something like this, you are making an application massively complex by trying to re-implement everything on both ends. Using something like Astro is only hiding that complexity but it’s still there, & probably full of bugs & tons of JavaScript that most developers wouldn’t even understand their stack or know how to jump into the Astro code. The amount of time saved is largely minuscule in most cases with the assets cached when navigating to a new page. In fact, I just tested two of their showcased sites which loaded slower with JavaScript enabled & the content was pretty obviously 95% static. There’s probably some niche use cases for this, but it’s not a good default IMO.

If you manage the WordPress installation, can’t you disable the ability or create/install a plugin that removes that ability? This hurts usability.

I admitted it was a spectrum, but this recent article in particular does a good job explaining the axes of static vs. dynamic : online vs. offline. I think you will appreciate it. :)

I’m not anti-Wayland… I’m anti-saying-it-good-enough-when-the-featureset-doesn’t match. I know it’s being worked on & I’ve followed the work pretty closely for over 4 years fingers-crossed there would be less bike-shedding & having things come out in easy-to-digest phases instead of holding back the monolith that they are building.

Knowing sRGB vs. DCI-P3 vs. AdobeRGB might not be immediately known as marketing teams like to hide the names behind marketing terms, but users very much understand ‘this displays a more vibrant range of color’. The whole ASUS laptop line is basically banking on having these great, color-calibrated 100% P3 OLED panels up all the price ranges because when a casual buyer walks in a shop, that those dominates the showroom & will sell better because it’s easy to compare even at a distance without looking at the spec sheet or touching the device; users are also used to it because smart phones have followed Apple’s P3 lead & expect better from laptops & monitors where the market can actually cater to this crowd (which is great since for years it seemed it was only dominated by how many frames you could get for the gamer crowd). Folk are getting QD OLED & other such monitors / TVs which have support. Imagine you buy that monitor, looks great, then move to Linux & now it doesn’t–which will become even more obvious when HDR is more mainstream, as you definitely noted. You don’t need to know the names of every technology or how they work to have a validated ‘bad feeling‘ about something not working as intended.

Conversly a lot of static websites break new tab by incorrectly slapping target="_blank" on anchors. Luckily Lemmy doesn’t mess this up.

What some folks are missing is that SPAs are great for web applications & unsuitable for web pages. There is more nuance than “SPA bad”.

Then dealing with a lot of dynamic content, piping thru a virtual DOM DSL is 100× nicer for a developer than having to manually manipulate the DOM or hand write XML where it’s easy to forget all the closing tags (XML is better as a interchange format IMO & amazing when you need extensibility… also JSX just makes it worse). That developer experience (DX) often can lead to faster iteration & less bugs even with a cost to the user experience (UX). But it’s not always a negative impact to the UX–SPAs can be used to keep things like a video or music player on while still browser & using the URL bar as a state reference to easy send links to others or remember your own state.

It’s equally silly that a landing page whose primary purpose is to inform users of content takes 40s to load & shows “This applications requires JavaScript” to the TUI browser users & web crawlers/search indexers that don’t have the scale of Google to be executing JavaScript in headless browser just to see what a site has to say.

The trick is knowing how & when to draw these lines as there’s even a spectrum within the two extremes for progressive enhancement. React isn’t the solution to everything. Neither is static sites. Nor HTMX. Nor LiveView. Nor Next/Nuxt/Náxt/Nüxt/Nœxt/Nอxt.

VS Code

It’s the Church of Emacs or Cult of vi (or Neovim) in these parts! You don’t need a Microsoft text editor with proprietary plugins to write JavaScript. When your display manager inevitably breaks while you learn Linux or administer a remote system, having skills with an editor that works in the terminal will prove invaluable.

Adding to sibling… Discord is used in a couple of different ways at present for communities. If you mean voice coms for gaming or otherwise, Mumble should be in your repository. If it’s more of a of a Slack-like business chat, self-hosted Mattermost is actually pretty nice. If it’s just text chat, IRCv3 & XMPP have that covered & scale massively even on a home PC. If it’s voice calls, Jitsi or Jami can work. If you are posting updates or things that should be forum topics, you shouldn’t be using chat anyways where Mastodon, Misskey, Lemmy, & other Fediverse options or even Atom feeds can suffice. If you want integrated chat, community updates/posts, voice/video calls (unsure if conference calls are support) Movim is a good option–and if you don’t mind the rough UI edges, Libervia can do similar but also integrates a calendar for events. Bear in mind as well that a lot of these technologies can be bridged between one another to avoid some of the lock-in, but I would hesitate to force everyone’s chat to be piped & logged thru Discord’s servers. It’s also not bad to say “we use these 2 services” rather than requiring a kitchen sink communications application.

Things are about to get worse for onboarding those from other platforms. There’s been this massive push the last year to get every window manager to switch to Wayland & drop X11 support… meanwhile Wayland doesn’t support color profiles or color management (just sRGB). How are you going to convince someone with an awesome screen to drop down to sRGB? How will you convince someone with a poor screen that has been color calibrated to make it usable to go back to off colors? How do you expect content creators to migrate & still create content if they can’t have access to all the color tools they use in their workflow to come to Linux when Wayland won’t support them? A lot of Linux folk act like this doesn’t matter, but to a lot of people, a computer is a magic box that they interact with via a screen + keyboard + mouse, & if non-niche peripherals aren’t supported (which DCI-P3 is becoming the norm & saving a screen from a landfill can often be fixed to ‘good enough’ thru calibration), users will think it’s trash & unfinished.

Are you using a device without an emoji font installed on the system at all? The web works just fine without browsers shipping an emoji font.

Everything has to be new & shiny or it’s bad. XML bad, JSON good. /s

With an FPGA or special CPU instruction set, the encryption algorithms could run on a toaster—which would give access to whatever low-spec handheld you wanted without making it chug to have strong encryption. That also still isn’t covering the future hope of a Linux phone, or someone that just wants to register an account on their laptop.

Using forks puts stress on other teams to keep up with breaking changes, & 90%+ of folks won’t be looking for forks or be willing to trust their unofficial status. I saw the code for UnifiedPush as a Mattermost plugin & it was like 50 lines or something small which is much less than the rest while allowing users to keep control of their metadata which is a big deal if you care about privacy. A fork for SMS support would encounter similar issues, & now you either need to compete with Molly or copy its featureset otherwise users have to choose, SMS or UnifiedPush. That said, I agree with the SMS situation since it was easy to convince relatives to use this new “text app” where encryption magically came to a chunk of their contact list.

Saying emoji was the most important was tongue-in-cheek, but it makes the application feel non-native (& I think Apple’s emoji are particularly ugly). You would think at least the Google set was shipped to Android, or—now hear me out—not ship emoji, don’t override the user experience, let the user’s fontconfig display the one they set. Shipping a whole font (or images) for emoji is why the application size is so bloated for a chat app.

Being “passionately against something” is my whole modus operandi.

If you use your mouse more than your numpad, you are doing your joints a disservice by not optimizing the ergonomics of your desk setup. I’m really glad we have a lot of options now to get anyone their custom setup unlike the ’90s & earlier. Recent years, separate numpads with good switches are easy to come by as well—heck, if you like mechanical switch over the alternatives, maybe you just want light linear switches for your numbers for your numpad so you can punch those numbers faster & without restraint while having a different switch an your main board.

Replicating all chat history + attachments provides a lot of resilience to the network from a node going down, but at the cost preventing to the home lab user from practically hosting a server which just means everything centralizes around Matrix.org, & when anyone on Matrix.org chats with you or your group, that metadata gets synced back to the central hub server once outwardly funded by Israeli intelligence.

I made the mistake of getting my family to switch to Signal. It works great for messaging, but it has other issues—beyond the typical SIM-required complaint. I hate that you have to register with a ‘primary’ device on either iOS or Android fueling that duopoly (SoL if you are on a postmarketOS or KaiOS or Capyloon phone… or just don’t want a internet-capable phone). Notifications are sent thru Google’s FSM (news 1–2 months ago that of course Apple & Google send all the metadata to the feds) & refuse to support UnifiedPush (thank goodness the Molly fork does). They’re also not too happy to support alternative clients meaning you are stuck with the shitty, resource-sucking Electron client while not having a web client or native or TUI client. And the worst cherry on top is shipping those iOS emoji to Android & Linux …eww.