Suggestion: Organize root folder / optimization of release size?

[xCaradhras]

Hello,

not really an issue, but it might give the application a more clean / professional appearance if all the files would be organized into subfolders with only exe and license file residing in root?

A more practical thing: Is it possible to shrink the release container a bit? 100 MB for a viewer seems to be a bit much. My guess is that most of it comes from Electron? I am not familiar with how much is realistic, but maybe there is a bit room for improvement.

Best regards and thanks for the effort!

[c3er]

Thanks for filing this issue!

A more practical thing: Is it possible to shrink the release container a bit? 100 MB for a viewer seems to be a bit much. My guess is that most of it comes from Electron? I am not familiar with how much is realistic, but maybe there is a bit room for improvement.

That's something that bothers me too for a while -- especially since the Electron framework gets bigger with each release. I look from time to time for solutions and even alternatives but didn't found anything satisfactory yet.

An alternative framework has to offer these features to be considered by me:

1. It has to be able to render HTML since this application supports embedding HTML into Markdown
2. Building and packaging for Windows, Linux and macOS should not just be possible but not too difficult (theoretically, one can write build and setup/deployment scripts for everything but that would be too time consuming)
3. It should be smaller than Electron, obviously

not really an issue, but it might give the application a more clean / professional appearance if all the files would be organized into subfolders with only exe and license file residing in root?

IMO a non issue😉

Most Windows applications, I'm aware of, don't have a file structure in their installation directory that one would consider as clean. I think, Markdown Viewer's file structure is very typical for Electron applications. Below a screenshot of the files of Markdown Viewer and some other applications:

[xCaradhras]

I did a quick web search. I actually did not spend too much effort, which is the best alternative (there are really many!), maybe there is still some room for optimization with Electron?

Maybe you can remove some unnecessary dependencies and stuff.

Some links:

• https://medium.com/gowombat/how-to-reduce-the-size-of-an-electron-app-installer-a2bc88a37732
• https://github.com/pojala/electrino
• Expected app bundle size? electron/electron#2003
• https://deskgap.com/
• https://blog.logrocket.com/why-use-electron-alternative/
• https://tauri.app/
• https://neutralino.js.org/
• https://github.com/sudhakar3697/electron-alternatives
• Python + PyQt? :D
• ...

[c3er]

Thanks for the suggestions!

My comments on the links:

---

https://medium.com/gowombat/how-to-reduce-the-size-of-an-electron-app-installer-a2bc88a37732

This is about the JavaScript dependencies (i.e. React in this article). The file resources/app.asar, that contains all the JavaScript (including the dependencies) has only just over 10 MB. The Markdown Viewer.exe, that is actually the electron.exe with another file name, has over 150 MB itself!

---

https://github.com/pojala/electrino

First, I wondered, why I was not aware of this, but then I remembered (emphasis mine):

An experimental desktop runtime for apps built on web technologies, using the system's own web browser engine. The project is still young and accepting contributions.

So, this runtime depends on the Browser that is built into the OS.

1. I don't like this approach. Rendering engine and other features are not controllable and differ between operating systems.
2. What about Linux? Is there even some kind of standard that makes PWAs feasible?
3. The last commit is three years ago. Something that should be the basis for the whole application, should be updated more regularly.

---

Expected app bundle size? electron/electron#2003

See also the issue Idea of runtime mode

There is really not much to do about except performing tree shaking on the dependencies. But in this case, it wouldn't help very much -- see above.

---

https://deskgap.com/

Same problem as electrino:

DeskGap is a framework for building cross-platform desktop apps with web technologies (JavaScript, HTML and CSS).

---

https://tauri.app/

Same problem as electrino and DeskGap:

Bundle Size

By using the OS's native web renderer, the size of a Tauri app can be less than 600KB.

---

https://neutralino.js.org/

Again:

Neutralinojs doesn't bundle Chromium and uses the existing web browser library in the operating system

---

Python + PyQt? :D

Actually, my first idea was to implement this application via Python and tkinter and implementing the whole Markdown parsing myself. I discarded this idea very fast, because embedding HTML had to be also possible and parsing HTML is anything but trivial. And before I use a browser component for some framework, I rather use a framework that is basically a browser itself.

Also, as far as I understand, Qt can only be used with GPL licensed applications, which would force me to change the license of Markdown Viewer. If one wants to use another license, one has to pay a very high yearly fee.

---

https://github.com/sudhakar3697/electron-alternatives

Most of these alternatives aren't really alternatives for Markdown Viewer. But Sciter.JS looks pretty interesting. I'll have a deeper look in the future. If the runtime is really only around 5 MB, then other size optimizations may also be worthwhile.

[c3er]

I looked a little deeper into Sciter.JS and unfortunately, there are reasons against it:

• It is not open source. The public repository contains only the code for the Sciter SDK
• I didn't found tools or even a toolchain for deployment. So I had to implement scripts for building setup files myself.

So either, I'd decide to make Markdown Viewer dependent on the operating system's browser (apparently and in contrast to my earlier statement, this is also practical with Linux) or just continue to use Electron for now.