[Announcement+Poll] The status of WebCord: Ain't dead yet.

[SpacingBat3]

👋 Hi all!

This post is an update to what is happening around WebCord and to keep you informed what I plan to do around this project, still in my (less than before but limited) free time.

1. It's been a while…

As you may have noticed, a few changes got recently into WebCord project management – one thing is that due to how long it might take to came with something that is worth replacing WebCord and due to waiting of some changes in Electron like support for ESM to become stable (ESM will be quite useful and large change in Electron, it'll make module loading async, await working at top-level among other stuff known in modern Node.js / JavaScript development).

2. WebCord's alive, for now

That being said, until there's no alternative to WebCord made on my side, the project stays alive and will be somewhat unfrozen for some development. However, do not expect too much, there might not come any major updates (well, client rewrite is expected to be next major update) and a lot of changes might also be done outside of WebCord's source code (e.g. I plan to support producing Arch Linux packages via GitHub releases by developing it in ReForged or maybe even implemening RPC by using my own discord-ipc-proxy for capturing API and implementing it in Disconnection project).

3. Fresh ideas

As of the beginning of the client rewrite, I've been also working on some plans, task lists and a name… For the last one, I've even made a logo! Currently, the it is a codename of the client but you can make it land as final app name – just vote for it! Yeah, for a reason that I'm basically working on a new client that is going to be unassociated to WebCord in most parts (I might reuse some code and ideas from it, but it's still will work in completely different way) as well as WebCord name in general being quite preoccupied, I decided to announce 2nd name change.

A lot of that was actually presented before on Discord channel, but as I want to keep my development publicly accessible (and Discord might be a bit of the pain to use accountlessly due how they treat frequent account creations and even enforcing sharing phone number with them in some cases), so I guess GitHub Discussions might be a better place. Anyway, here's the logo I've shared on Discord server as a small recap:

3.1 Rules

While the pools on GitHub cannot be extended by any users for now, you can still make suggestions in the comments section! I'll try then to keep the pool updated with the most popular names. You might also vote on existing proposes with ↑, although I do not guarantee for now I will count all reactions from comments, especially after they were added onto the poll. You're also free to use comments as normally you do (just make it clean for everyone whenever you suggest a name, otherwise I'll treat it as a regular comment).

Of course, name suggestions (as everything you post here) should be kept of proper standard – there should be nothing that makes them NSFW, racist, controversial or harmful in any way. I don't think my role is to educate what's proper or not specifically and write an A4 format of paper that includes rules, so please just use the common human sense.

That being said, see you all soon!

---

[strawbberrys]

When will the rewrite go open source?

[SpacingBat3]

It might take a while, currently I'm mostly waiting for Electron to merge ESM modules (support). I guess it might come with Electron 27, maybe it will be backported if it doesn't break anything… But I'll try to open source it once I'll came with something usable and there will be a core module that won't need any major rewrites, by design most of the features in client should be implemented by external modules and these should have fully predictable types for TypeScript (i.e. extend/use the same class for implementation).

In the meantime, I might actually use WebCord for experimenting with the modularity around some components. I'll also try to implement Discord RPC, I've already made a tool for capturing entire communication between Discord and applications in order to reimplement it. I might also do some prototype of modules (possibly based on global vars and nothing I plan for PieCord)…

And ESM on Electron side is really important change for me, it might actually be a reason to drop CommonJS entirely for all my libraries and just switch to ESM for everything… Which would be great, it could make some libraries that don't use Node at all to also work in browsers or other frameworks/backends (EcmaScript module loading is supposed to be supported everywhere, as they're part of EcmaScript spec)… Also async module loading might actually improve the application loading times – with CommonJS modules are loaded once they're referenced in code (i.e. require() is used), but with ESM loading is non-blocking and application might do other stuff than wait for modules to load, at least as far as I understand the implementation and spec. Previously I've tried mixing ESM and CJS with the next branch, but using two module loaders just makes things much more complicated and has a lot of limitation, especially when the main process has to be CJS and with anything running asynchronously (e.g. in another threads or in async function) there's a risk of having the race condition if there's stuff that has to be initialized before Chromium fully loads…

[strawbberrys]

Electron issues make sense lol. This rewrite seems like it's gonna be pretty powerful though. Thanks for the detailed response 👍.