6 ms·

I've been thinking about this a lot, mainly due to being grumpy about the proliferation of Electron apps and the effect that's having on my available RAM. When

I've been thinking about this a lot, mainly due to being grumpy about the proliferation of Electron apps and the effect that's having on my available RAM. When I'm not being so grumpy, I'm glad it's easier to write apps than ever before. I think someone on here posited that it's a choice between something written in Electron or not written at all. I think that's fair enough - maybe we just need to make it easier to write tiny apps. Rust and Go look great, even with a very steep learning curve coming from C# and Python. And yes, I know as a C# developer sitting on top of hundreds of megabytes of runtime, I'm "part of the problem".

lsh 9y ago
I'm a python and clojure dev, and part of the reason for going in search of tiny apps with source code was to see how they managed it. I know I'm part of the problem too, I like working at a very high level, but I, too, am getting old and grumpy and detest how 16GB ram isn't enough these days. I was actually, partly, looking for a community who built or curated lists of apps with artificial constraints, for example: app must not use more than N MB of ram, must be open source, etc. there is the demo scene, but I want to build practical apps, and there is suckless, but I found their community and philosophy a bit ... hardcore and unaccommodating.
- voltagex_ 9y ago
  I'd definitely like to talk about this more - I don't have time for any more side projects but it's an interesting idea. "app must not use more than N MB of RAM" is a tricky one - how would you measure usage in all cases?
  - roryisok 9y ago
    I think its less about a hard limit and more about comparing to other apps out there that do the same thing. Music players for instance. 1by1 < foobar < VLC < Songbird / Spotify
    - lsh 9y ago
      absolutely. I see a lot of css and js frameworks marketing themselves on how very small they are, both before and after minimization. I guess the first step is to accurately measure what is important.
  - lsh 9y ago
    it's a good point and something I'm still investigating. with the jvm you can set the maximum memory available to the instance. I once did all the fundamental C and C++ type stuff, writing a memory manager and my own implementations of certain datastructures and algorithms, it doesn't seem unreasonable to write something that would enforce program limits in a transparent way.
- dahoramanodoceu 9y ago
  This is a wonderful trend. I've been griping about bloated apps for ages. There's a huge accessibility issue for people in Latin-America and Africa, where most people's computers still have no more than 2G of ram.
danieldk 9y ago
I'm glad it's easier to write apps than ever before. But it was easy before. If you are willing to forego completely native UIs (which you are when you are using Electron), it's always been easy to make GUI apps with Qt. Drag together an UI in designer, use (py|whatever)uic to generate classes, hook up signals/slots, and you are done. I can only pin it on intellectual laziness of front-end programmers not wanting to learn anything else than HTML/CSS/JS and companies wanting replaceable developers. There is virtually no benefit for the end user over native applications or cross-platform applications written with e.g. Qt.
- voltagex_ 9y ago
  Is a PyQt app really more lightweight than Electron? To be fair, Qt is a lot trickier than Electron - you've mentioned slots and signals which are not something you'd encounter every day (at least in webdev world). Edit: I also don't buy any argument that relies on "intellectual laziness". There's enough elitism around already.
  - shakna 9y ago
    Well, I can't speak for today, but back in the early 2000s, I put together a simple web browser in Qt, which is easy because it already includes a simple web engine, added a simple JS engine, and the web browser was up and running. I recall being disappointed it wouldn't run nicely on '98 for some people, because it used about 25mb of RAM, and many only had 128mb for their entire system.
  - danieldk 9y ago
    Is a PyQt app really more lightweight than Electron? I just tried, because it's only 5 minutes of work. The demo apps (including a movie player and an image viewer) are generally in the 30MB of memory ballpark on OS X. you've mentioned slots and signals which are not something you'd encounter every day It's something that you can pick up in a few minutes. Widgets emit signals. You can connect signals of choice to slots to handle those signals. In Python, a slot is just a Python method. In C++ is slot is also a method, but you have to add a small 'annotation' that is processed by moc.
  - 9y ago
roryisok 9y ago
The thing about electron is, there's a time and a place for it. VsCode is an excellent use case for electron - a complex cross platform app with a very quick release cycle, a large plugin ecosystem and a requirement for display and processing of a lot of different types of markup. But I've also seen a tray notification app worn in electron. It didn't even have a UI. There's also an sd card formatter, and a "quick" launcher. Devs who wasn't to release some tiny single function app like this should rightly be ridiculed for using electron, but more complex stuff (gitKraken etc) should get a pass. Building a large, complex editor is hard work
- roryisok 9y ago
  typos - "app worn in electron" = "app written in electron" and "devs who wasn't to release" = "Devs who want to release".
TeMPOraL 9y ago
> And yes, I know as a C# developer sitting on top of hundreds of megabytes of runtime, I'm "part of the problem". This should be a solvable problem, IMO. I mean, C/C++ apps are not inherently tiny - they sit on top of a large runtime too, but one that usually comes with the OS. What makes Python or Lisp apps (in binary form) multi-megabyte by default is that they can't depend on users having the runtime installed, unlike C/C++ apps. JVM managed to cross that gap too - most users, at some point, will install a JRE, which allows .jar files to be small. I wonder why generalized solution for managing programming language runtimes OS/user-side didn't materialize.
- makapuf 9y ago
  Python runtime also uses that same C runtime so it's not as if you can replace one with another. Besides, stripped static binaries in C or even C++ can be relatively small. JRE is not installed by default on many desktops, let alone embedded.
- astrobe_ 9y ago
  You are deeply confused. What makes managed/VM based languages big is that those runtimes are general purpose, and therefore have to embark what most people need. A C/C++ app embarks (mostly) only what's necessary. I can compile a hello world for bare metal, replace puts with a routine that sends the characters to the serial output, add the necessary UART initializations, and the final program will still be a bunch of order of magnitudes smaller that a Python install. The comparison is unfair of course, but it proves one thing: no multimegabyte runtime in C.
yoodenvranx 9y ago
> I'm glad it's easier to write apps than ever before. I believe that it is Delphi which sits right at the sweet spot of 'native code', 'easy gui development' and 'easy deploy' and I am sad that it is not really in use anymore.
- fiddlerwoaroof 9y ago
  As others have mentioned there's Lazarus, an open source ide that duplicates the Delphi experience. Although, it still needs quite a bit of polish.
- deleted 9y ago
  [deleted]

lsh 9y ago

I'm a python and clojure dev, and part of the reason for going in search of tiny apps with source code was to see how they managed it. I know I'm part of the problem too, I like working at a very high level, but I, too, am getting old and grumpy and detest how 16GB ram isn't enough these days. I was actually, partly, looking for a community who built or curated lists of apps with artificial constraints, for example: app must not use more than N MB of ram, must be open source, etc. there is the demo scene, but I want to build practical apps, and there is suckless, but I found their community and philosophy a bit ... hardcore and unaccommodating.

voltagex_ 9y ago
I'd definitely like to talk about this more - I don't have time for any more side projects but it's an interesting idea. "app must not use more than N MB of RAM" is a tricky one - how would you measure usage in all cases?
- roryisok 9y ago
  I think its less about a hard limit and more about comparing to other apps out there that do the same thing. Music players for instance. 1by1 < foobar < VLC < Songbird / Spotify
  - lsh 9y ago
    absolutely. I see a lot of css and js frameworks marketing themselves on how very small they are, both before and after minimization. I guess the first step is to accurately measure what is important.
- lsh 9y ago
  it's a good point and something I'm still investigating. with the jvm you can set the maximum memory available to the instance. I once did all the fundamental C and C++ type stuff, writing a memory manager and my own implementations of certain datastructures and algorithms, it doesn't seem unreasonable to write something that would enforce program limits in a transparent way.
dahoramanodoceu 9y ago
This is a wonderful trend. I've been griping about bloated apps for ages. There's a huge accessibility issue for people in Latin-America and Africa, where most people's computers still have no more than 2G of ram.

danieldk 9y ago

I'm glad it's easier to write apps than ever before. But it was easy before. If you are willing to forego completely native UIs (which you are when you are using Electron), it's always been easy to make GUI apps with Qt. Drag together an UI in designer, use (py|whatever)uic to generate classes, hook up signals/slots, and you are done. I can only pin it on intellectual laziness of front-end programmers not wanting to learn anything else than HTML/CSS/JS and companies wanting replaceable developers. There is virtually no benefit for the end user over native applications or cross-platform applications written with e.g. Qt.

voltagex_ 9y ago
Is a PyQt app really more lightweight than Electron? To be fair, Qt is a lot trickier than Electron - you've mentioned slots and signals which are not something you'd encounter every day (at least in webdev world). Edit: I also don't buy any argument that relies on "intellectual laziness". There's enough elitism around already.
- shakna 9y ago
  Well, I can't speak for today, but back in the early 2000s, I put together a simple web browser in Qt, which is easy because it already includes a simple web engine, added a simple JS engine, and the web browser was up and running. I recall being disappointed it wouldn't run nicely on '98 for some people, because it used about 25mb of RAM, and many only had 128mb for their entire system.
- danieldk 9y ago
  Is a PyQt app really more lightweight than Electron? I just tried, because it's only 5 minutes of work. The demo apps (including a movie player and an image viewer) are generally in the 30MB of memory ballpark on OS X. you've mentioned slots and signals which are not something you'd encounter every day It's something that you can pick up in a few minutes. Widgets emit signals. You can connect signals of choice to slots to handle those signals. In Python, a slot is just a Python method. In C++ is slot is also a method, but you have to add a small 'annotation' that is processed by moc.
- 9y ago

roryisok 9y ago

The thing about electron is, there's a time and a place for it. VsCode is an excellent use case for electron - a complex cross platform app with a very quick release cycle, a large plugin ecosystem and a requirement for display and processing of a lot of different types of markup. But I've also seen a tray notification app worn in electron. It didn't even have a UI. There's also an sd card formatter, and a "quick" launcher. Devs who wasn't to release some tiny single function app like this should rightly be ridiculed for using electron, but more complex stuff (gitKraken etc) should get a pass. Building a large, complex editor is hard work

roryisok 9y ago
typos - "app worn in electron" = "app written in electron" and "devs who wasn't to release" = "Devs who want to release".

TeMPOraL 9y ago

> And yes, I know as a C# developer sitting on top of hundreds of megabytes of runtime, I'm "part of the problem". This should be a solvable problem, IMO. I mean, C/C++ apps are not inherently tiny - they sit on top of a large runtime too, but one that usually comes with the OS. What makes Python or Lisp apps (in binary form) multi-megabyte by default is that they can't depend on users having the runtime installed, unlike C/C++ apps. JVM managed to cross that gap too - most users, at some point, will install a JRE, which allows .jar files to be small. I wonder why generalized solution for managing programming language runtimes OS/user-side didn't materialize.

makapuf 9y ago
Python runtime also uses that same C runtime so it's not as if you can replace one with another. Besides, stripped static binaries in C or even C++ can be relatively small. JRE is not installed by default on many desktops, let alone embedded.
astrobe_ 9y ago
You are deeply confused. What makes managed/VM based languages big is that those runtimes are general purpose, and therefore have to embark what most people need. A C/C++ app embarks (mostly) only what's necessary. I can compile a hello world for bare metal, replace puts with a routine that sends the characters to the serial output, add the necessary UART initializations, and the final program will still be a bunch of order of magnitudes smaller that a Python install. The comparison is unfair of course, but it proves one thing: no multimegabyte runtime in C.

yoodenvranx 9y ago

> I'm glad it's easier to write apps than ever before. I believe that it is Delphi which sits right at the sweet spot of 'native code', 'easy gui development' and 'easy deploy' and I am sad that it is not really in use anymore.

fiddlerwoaroof 9y ago
As others have mentioned there's Lazarus, an open source ide that duplicates the Delphi experience. Although, it still needs quite a bit of polish.
deleted 9y ago
[deleted]