Integrate OpenAsar

[jacksongoode]

There's an interesting project (which you may know about already?) that optimizes some of Discords initial load and blocks trackers. https://github.com/GooseMod/OpenAsar It might be interesting to integrate within this Project? I've tried to replace it within WebCord but I get an error.

[SpacingBat3]

Ugh, I don't think you understand the differences between the OpenAsar and WebCord…

So, WebCord is basically a standalone alternative to Discord, it does not share any part of its code with their codebase (unless some Discord dev noticed my project and stealed my code lol). And all stuff it offers is like we already have that in WebCord, like I try to load stuff as fast as I can while keeping the smooth transition between the splash screen and Discord content. And given WebCord doesn't really do much on its load (we do not download any modules or updates them, we straight go to the load the locally-saved splash screen and then to load Discord just so make WebCord look like it is actually loading). For tracing, I guess WebCord also takes care of that on the adequate level, no guarantees are for tracing outside of Discord but given I designed CSP to allow only for pages that are required to load at least in some cases, it might actually be blocked quite efficiently.

OpenAsar on the other hand is meant to be a replacement to at least part of official Discord client – I guess it still doesn't mess up too much with the userData meaning that Discord as a whole is partially closed-sourced. So it isn't really a whole client re-implementation, mostly just of their loading scripts and eventually some of their assets… At least native modules are surely closed-source, I guess it would be a major breakthrough if someone would make it open – that most likely means we could have Discord on unsupported platforms and architectures like Linux ARM or even FreeBSD! I guess then the limitation would be to actually build Electron for it or use prebuilt upstream releases (even though Discord uses their own fork of Electron it's still possible to run it with the upstream ones in most cases).

[jacksongoode]

Thanks for your explanation. I think I understand from a wider perspective how the projects differ, however WebCord still uses an app.ascar file as a fundamental part of Electron's packaging. OpenAsar is just a project to optimize the size and speed of loading this piece, which is something you could do without "integrating" OpenAsar, but just by building the app.asar with the same minimizing techniques in their workflow.

I only bring this up because the speed increase in opening Discord with the stripped app.ascar is a significant draw and also because the app.asar bundled in WebCord is twice the size of Discord's (20mb vs. 10mb - I could be wrong about this).

[SpacingBat3]

Thanks for your explanation. I think I understand from a wider perspective how the projects differ, however WebCord still uses an app.ascar file as a fundamental part of Electron's packaging. OpenAsar is just a project to optimize the size and speed of loading this piece, which is something you could do without "integrating" OpenAsar, but just by building the app.asar with the same minimizing techniques in their workflow.

I don't think you still understand the differences. OpenAsar as complete reimplementation uses no weird stuff Discord does – I've noticed it has much less libraries. I both couldn't find any other magic you believe OpenAsar does.

And given ASAR is the archive format exclusively used across all Electron applications for optimizing module loading, mostly on Windows, at least Electron Docs states that Windows has some trouble when loading modules with long paths. Technically the one could even optimize the file ordering within the WebCord's app.asar, but that would require the collection of the ASAR reads with ELECTRON_LOG_ASAR_READS env var and repackaging ASAR. That would make building process much more complicated than it is now and OpenAsar doesn't seem to optimize that anyway neither most Electron apps (depending on how modules are loaded, there's a chance there wouldn't be much of the time gain on the loading).

It should be also worth saying ASAR archives are uncompressed, there's no support through for any compression format and even if that would be implemented it most likely would make stuff load slower as it would have to be decompressed before loaded.

WebCord can't obviously strip nothing from itself (we don't depend on Discord stuff at all, hence this is a standalone client), maybe I could consider avoiding internal fonts or creating my own package for them – they take a bunch of space, if not the most and it, however I got some reports from some users they have some troubles with the font (missing even some basic ASCII characters!) if there's no font that could be used as a fallback. So I dunno if I should strip it from the main builds, maybe creating my own set of fonts for Latin chars would be enough.

I also want to refactor the WebCord's code, I dunno how that will end up but hopefully I might end up with more lightweight code and implement some stuff using methods I didn't know about when I encountered some Electron bugs or implemented some features. I also will partially move to EcmaScript Modules – it's a bit experimental module in Electron, but it could give some optimizations related to module loading as ESM seem to be loaded asynchronously in contrast to synchronous require in CommonJS. I might actually freeze current development on WebCord v4.x.y to focus on v5.x.y. I dunno how long it will take me to finish it or if I won't give up in the middle (I don't think I will, I am happy from at least a few of the current changes on my local repo and I want them to be pushed to remote as soon as that would be possible), currently I still haven't implemented any window to show or anything, at least I hope what I worked on will shape the future WebCord development.

I only bring this up because the speed increase in opening Discord with the stripped app.ascar is a significant draw and also because the app.asar bundled in WebCord is twice the size of Discord's (20mb vs. 10mb - I could be wrong about this).

I believe the last time I checked it was a bit more than 10MB and mostly because of internal fonts? I might do something about that as I mentioned earlier through.

[jacksongoode]

That sounds good. I was just thinking that maybe some of the approaches in stripping back resources from an Electron application might apply to WebCord for the sake of initialization speed. Thanks for the long response, I'll be following WebCords progress!