toastal

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. :)

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.

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.

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.