Hacker News Reader

Comment by voltagex_ | Hacker News Reader

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".

View on HN

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.

I'd say that with Lazarus (http://www.lazarus-ide.org/) it even easier - just drag/drop the controls to forms to build your GUI, double click on buttons/checkboxes/radiobuttons/whatever or click on menus or double click on the event editor to automatically write the event handling boilerplate code and you just write the actual code in-place. Creates native executables without need for runtimes or big DLLs (you can use Qt as a backend if you like though and in Linux you have to choose between Gtk and Qt).

Here is an old video i made 2-3 years ago where i write a small 2D tilemap editor with Lazarus (the first 5-6 minutes are downloading and installing Lazarus and a tile editing tool i wrote since i used Windows 7 for that vidoe and the Win7 paint program sucks) https://www.youtube.com/watch?v=_3JgeIUo1X0

In my previous life as a cubicle drone in the late 90s I have worked with Delphi under Windows and always dreamed about it being ported/cloned/whatever on Linux. After seeing a demonstration of Kylix many years ago I almost lost any hope (slow as molasses and buggy), then one day I saw this new project called Lazarus which promised high compatibility with Delphi code and to allow building of native apps. Admittedly it was very buggy then, but eventually it matured over time and I'd say it has been damn ready to be used for production for some years. Give it a try and you won't be disappointed.

I've tried to use Lazarus five or six times now, as a one-time Delphi developer: the main issue is that the lazarus ide likes to crash on the slightest provocation (and the 64bit mac versions don't work very well either)

Which version did you use and when? 10 years ago the IDE would crash at you sneezing at it and it wasn't until 7-8 years ago that things became stable. However i cannot remember the last time i saw the IDE crash (and wasn't my own fault with a component i was making that caused it to crash, but even that that is rare).

Note that there are a few versions flying around that are unofficial builds, some with addons that break it. Sadly one of them is the one from getlazarus.org which is both unofficial and often comes with unfinished and buggy features from development versions that cause it to crash and be generally more unstable. Combine this with the fact that the guy behind getlazarus.org tries his utmost to promote Lazarus (his version from his site) and there is a chance people who first learn about Lazarus will use the buggy one. He obviously means well, but i really wish he would link to the official site (http://www.lazarus-ide.org/) instead. The builds there are much better tested and there are many week-long release candidate builds that are tested by many people in the mailing lists, forums, etc before an actual final release is made.

Also note that the native Mac version is really in a worse state than the Windows and Linux versions. Thanks to Apple discontinuing Carbon (which is what Lazarus uses on Mac by default), a ton of work has to be done to rewrite the backend in Cocoa and there are very few programmers working on the Mac version so this progress is slow (also AFAIK this was delayed to implement the "Objective Pascal" extension to the compiler that would allow using Objective C classes directly without needing an intermediate C layer). Today you can use both Carbon and Cocoa as backend targets, but between the two the Carbon one is still the most stable. As an alternative you can use the Qt backend though that is more stable and featureful (thanks to it being also worked by the Linux devs), but you'll need to bundle a bunch of shared libs and are throwing all notions of minimalism out of the window :-P. Still it is the only way to get full featured stable 64bit apps with Cocoa made in Lazarus, at least until the Cocoa backend improves. And it isolates the bloat to a single platform, which while not ideal, is better than nothing (and IMO even the Qt+LCL combo is still better than bundling an entire web browser with your program).

So, I do most of my work on Mac, so that's what I'm using. It took me forever to figure out how to rebuild it as a 64bit app using Qt (I built the Qt5 version, maybe that's part of my problem?). Anyways, once I did that, it started fine but I ran into several issues where changing properties of Data Access components would crash the IDE. (postgresql-related things in particular). If I find time, maybe I'll submit some sort of bug report with a reproducible scenario.

You are one step ahead of me, i never managed to build the Qt version myself :-P. Although i didn't try much, i rarely use Macs these days and mostly wanted to see if some minor issue i had with the Carbon build would go away with the Qt backend (the Cocoa backend was basically unusable at the time, although i think today it would work ok).

TBH i'm not sure if it would be Qt5 or the data access components as personally i don't use either :-P. I use Lazarus to make tools mainly for game development (and mainly for 3D stuff) so i don't use the database features at all. Also i tend to use the Gtk2 backend on Linux, mostly because it is the default but also because it tends to fit better the minimalistic window managers i am using (mainly window maker).

This is strange. The IDE once surely had stability problems, but I've never encountered them since years. I even installed Lazarus on small NanoPI and OrangePI boards and although definitely not fast it runs natively there and produces native code for them.

Don't you need to be using Lazarus' language (Delphi?) for that? In most cases, that's very prohibitive, since a language with a large ecosystem is usually what you'd want to be writing stuff in.

Yes, but there is a ton of functionality already out there, Object Pascal is popular enough to have almost everything available and for the stuff that aren't available it is trivial to call into other native languages (and there are many bindings already available). If you have a C header you can even use a conversion program that comes with Lazarus to create a binding for it.

Of course it all depends on what you want to do, but for me at least that was never a problem.

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.

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.

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.

Yes, much. And if that's too heavy for you, WxWidgets should be even lighter.

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

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

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.

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.

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?

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

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.

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.

> 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.

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.

> 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.

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.

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.

Reply on news.ycombinator.com