It looks like you made a web version! - I wish everyone that made electron “apps” had the foresight to make web version (do they even need to be different repo?!). There is a lot more potential for your app now that it isn’t encumbered by electron! Someone can turn it into a service or run it on a BSD!
I’d also like to nip something in the bud.. electron (and anything built on top of it) is not “mimimal”. It might have taken you very little code to produce said thing.. but electron is very very not minimal.
Here is some data to chew on:
Electron (66846bff975f92dd721d5ca29f332edf3795f1c0)
qbit@slip[0]:chromium-61.0.3163.100λ cloc .
209609 text files.
189475 unique files.
Out of memory!800
panic: POPSTACK
qbit@slip[1]:chromium-61.0.3163.100λ
I got 33 million with cloc earlier but don’t want to run it again to try to figure out what I’m either getting wrong or they’re ignoring. Was using my own thing: https://github.com/cgag/loc/
Oh, I see you posted the output of cloc in another comment. I see I’m counting 7.6 million lines of plain text. I don’t know why I do that, but subtracting that out gets me down to 34 million which is reasonably close. Also finding far more HTML .
I did use depot-tools, I think I’m at head.
edit: I get a very similar count to tokei when I respect .gitignore like it does so I think mines reasonably accurate.
So Electron (144,614) and Chromium (28,103,031) mean that electron’s “code base” is 28,247,645 lines of code long. 13.9 million more than a fairly feature complete OS!
What is your point? You’re comparing a browser and an operating system (which is orders of magnitude larger and more complex).
Electron is fast to run (even on older hardware and laptops) and easy to build apps with, Slack is a terribly built application but is still the only one people mention when talking about Electron.
Granted, I would probably use a Gecko version of electron if I could, but I am not aware of any projects like that.
(which is orders of magnitude larger and more complex).
The point is that the browser is “magnitude larger and more complex” than a complete operating system.
Electron is by no means fast to run, the memory usage is over the top and its not portable to systems they don’t support because of the enormous complexity.
The way how electron is designed makes it impossible to have a shared runtime, which would reduce the amount of work to add electron based programs to distributions package managers or ports systems.
Its not feasible to build a whole browser for each electron app.
I’m confused, you say that Electron is larger, but the numbers you posted don’t follow that:
Electron: 1610 files, 144614 LOC
OpenBSD: 51464 files, 13931085 LOC
Electron is by no means fast to run, the memory usage is over the top
I’ll say it again, that is the individual application’s responsibility. Most JS devs don’t know how to be memory safe.
not portable to systems they don’t support because of the enormous complexity
This is a legitimate complaint, but is a solvable problem. It’s possible to support FreeBSD and OpenBSD in the near future (as far as I know).
I’ll admit that a shared runtime would be advantageous from a package managment standpoint, but then you need the latest runtime for one app, but that breaks another and it becomes a big mess.
Oh, I misunderstood your first post, I didn’t understand that the tables were the output of cloc (I’ve never used it before). I see what your saying now, but my point still stands, JS devs are the problem, not Electron.
Yeah, my point is that an entire OS* src tree is orders of magnitude smaller than the chromium source (which is included when you build electron apps!!)!
I personally use Marked2, which is kind of like a sidecar app – you edit in your editor of choice, and marked just renders the markdown for you in a floating window.
+1 - I find the lack of GitHub Enterprise full screen in-browser editing support annoying, so I tend to write up a comment using MacDown so I don’t have to flip between Edit and Preview in GHE.
Isn’t the point of markdown the ability to see ‘formatted’ text without rendering it as HTML? I’ve never really understood the value of these markdown editors, given that the most complex thing in MD seems to be lists
Never saw this, but I guess that comes from all the different markdown flavors.
But ok, use electron for this and call it minimal, I don’t have to care if I don’t use it.
Edit: But using some webkit view from gtk or qt would make it less of a problem for me as someone who packages software for a linux distribution.
Packaging electron apps is just not feasible because we need patches for it to support musl libc and building it over and over again for each electron app is just wrong.
Your original post was a lowbrow dismissal of someone’s work couched with irony to provide plausible deniability. Even then, you knew it wasn’t the right thing to do.
You then showed that you hadn’t even bothered to understand the field before dismissing the project.
You then did another lowbrow dismissal comment, but then followed it up with an edit, in which you suggested:
the developer take a hard dependency and rewrite their entire software in one of two perennially buggy, flaky, fast-moving and platform-locked desktop linux frameworks, just because it would make your life as a linux software packager easier
it’s impossible to package electron apps because you have to do work to compile it and that makes you sad
I’m trying to imagine scenarios under which you could express more entitlement or lack of respect for people who actually do work, but they’re not coming to me. Additionally, if the job of packaging software is too hard for you, maybe stop doing it.
After your edit this is a much more informative post than your top level one dissing the project. Perhaps you could lead with something more like this next time?
To my understanding, though, there’s no good quick solution to package GTK and QT applications to OS X/Windows, which - to my understanding - is one of the main reasons people pick electron?
+100 points for sync scrolling! I’ve been using MarkDown Pro on Mac for a couple years and it still doesn’t have this feature. Will give this a try.
Thanks! Do let me know your feedback about it.
Can I get a “Hates Electron” hat?
It looks like you made a web version! - I wish everyone that made electron “apps” had the foresight to make web version (do they even need to be different repo?!). There is a lot more potential for your app now that it isn’t encumbered by electron! Someone can turn it into a service or run it on a BSD!
I’d also like to nip something in the bud.. electron (and anything built on top of it) is not “mimimal”. It might have taken you very little code to produce said thing.. but electron is very very not minimal.
Here is some data to chew on:
Electron (66846bff975f92dd721d5ca29f332edf3795f1c0) Chromium (61.0.3163.100) Entire OpenBSD src tree (includes clang and gcc)If someone else wants to run
clocon the chromium tree - I would love to see the complete output!whoa, I got 28,103,031 on chromium 61.0.3163.100! I wonder what the difference is - did you run depot-tools?
I got 33 million with cloc earlier but don’t want to run it again to try to figure out what I’m either getting wrong or they’re ignoring. Was using my own thing: https://github.com/cgag/loc/
Oh, I see you posted the output of cloc in another comment. I see I’m counting 7.6 million lines of plain text. I don’t know why I do that, but subtracting that out gets me down to 34 million which is reasonably close. Also finding far more HTML .
I did use depot-tools, I think I’m at head.
edit: I get a very similar count to tokei when I respect .gitignore like it does so I think mines reasonably accurate.
[Comment removed by author]
So I got the output from chromium!
So Electron (144,614) and Chromium (28,103,031) mean that electron’s “code base” is 28,247,645 lines of code long. 13.9 million more than a fairly feature complete OS!
What is your point? You’re comparing a browser and an operating system (which is orders of magnitude larger and more complex).
Electron is fast to run (even on older hardware and laptops) and easy to build apps with, Slack is a terribly built application but is still the only one people mention when talking about Electron.
Granted, I would probably use a Gecko version of electron if I could, but I am not aware of any projects like that.
The point is that the browser is “magnitude larger and more complex” than a complete operating system. Electron is by no means fast to run, the memory usage is over the top and its not portable to systems they don’t support because of the enormous complexity.
The way how electron is designed makes it impossible to have a shared runtime, which would reduce the amount of work to add electron based programs to distributions package managers or ports systems.
Its not feasible to build a whole browser for each electron app.
I’m confused, you say that Electron is larger, but the numbers you posted don’t follow that: Electron: 1610 files, 144614 LOC OpenBSD: 51464 files, 13931085 LOC
I’ll say it again, that is the individual application’s responsibility. Most JS devs don’t know how to be memory safe.
This is a legitimate complaint, but is a solvable problem. It’s possible to support FreeBSD and OpenBSD in the near future (as far as I know).
I’ll admit that a shared runtime would be advantageous from a package managment standpoint, but then you need the latest runtime for one app, but that breaks another and it becomes a big mess.
while running cloc on chromium, it never finished.
Why don’t you try running it on OpenBSD?
What? The post from @qbit includes cloc of the OpenBSD source tree and includes the attempt to run it on the chromium source.
The point is that chromium is too larger to even run cloc on it, while you can completely scan the OpenBSD tree.
https://www.quora.com/How-many-lines-of-code-is-Google-Chrome
Oh, I misunderstood your first post, I didn’t understand that the tables were the output of cloc (I’ve never used it before). I see what your saying now, but my point still stands, JS devs are the problem, not Electron.
Are you taking about electron or cloc of chromium? - because I have tried electron and that cloc cmd above was run on OpenBSD.
See above.
Yeah, my point is that an entire OS* src tree is orders of magnitude smaller than the chromium source (which is included when you build electron apps!!)!
(*) With awesome things like:MacDown is a good macOS native alternative to this.
I personally use Marked2, which is kind of like a sidecar app – you edit in your editor of choice, and marked just renders the markdown for you in a floating window.
+1 - I find the lack of GitHub Enterprise full screen in-browser editing support annoying, so I tend to write up a comment using MacDown so I don’t have to flip between Edit and Preview in GHE.
[Comment removed by moderator pushcx: don't make "hate posts"]
And Direct3D. But for an electron app it really is minimal: only 145.3 MiB on disk.
I mean, you sort of need a browser to render markdown.
Isn’t the point of markdown the ability to see ‘formatted’ text without rendering it as HTML? I’ve never really understood the value of these markdown editors, given that the most complex thing in MD seems to be lists
What makes you think you need a browser for simple text formatting?
Markdown has full support for inline HTML.
It’s even so central to the language that it’s literally the second section in the original markdown document
Never saw this, but I guess that comes from all the different markdown flavors.
But ok, use electron for this and call it minimal, I don’t have to care if I don’t use it.
Edit: But using some webkit view from gtk or qt would make it less of a problem for me as someone who packages software for a linux distribution. Packaging electron apps is just not feasible because we need patches for it to support musl libc and building it over and over again for each electron app is just wrong.
I find your comment particularly infuriating.
Your original post was a lowbrow dismissal of someone’s work couched with irony to provide plausible deniability. Even then, you knew it wasn’t the right thing to do.
You then showed that you hadn’t even bothered to understand the field before dismissing the project.
You then did another lowbrow dismissal comment, but then followed it up with an edit, in which you suggested:
the developer take a hard dependency and rewrite their entire software in one of two perennially buggy, flaky, fast-moving and platform-locked desktop linux frameworks, just because it would make your life as a linux software packager easier
it’s impossible to package electron apps because you have to do work to compile it and that makes you sad
I’m trying to imagine scenarios under which you could express more entitlement or lack of respect for people who actually do work, but they’re not coming to me. Additionally, if the job of packaging software is too hard for you, maybe stop doing it.
After your edit this is a much more informative post than your top level one dissing the project. Perhaps you could lead with something more like this next time?
To my understanding, though, there’s no good quick solution to package GTK and QT applications to OS X/Windows, which - to my understanding - is one of the main reasons people pick electron?
I maintain the OpenBSD port for ghostwriter, it’s pretty minimalistic and uses qt5 webkit view.
There are much nicer ways to make a technical point than this. Please use one of them in the future.
A “minimal X app” generally means an app with a simple and straightforward interface, not an app that fits in 64kb.