Hacker News Reader

Comment by ivan_gammel | Hacker News Reader

>Electron allows the world's most popular layout system (HTML+CSS) to be used with one of the world's most popular programming languages

Just wanted to name the most obvious alternative: embedded browser component like QtWebKit, which allows to code most of the application logic on the language of your choice. Embedded browsers are the way people have been doing it since circa 2000 (by then, Windows was dominating platform and you could use embedded IE for rendering - the typical app size was much smaller than 200 Mb btw). I remember earning some money on a side project around that time - the CD catalog of bathroom equipment, which I implemented by borrowing huge part of my customer's website and embedding it in CBuilder app with few improvements for richer UX.

View on HN

I'm fairly certain electron could easily be modified to be installed once and used as the launcher for its applications. I'm also fairly certain we'll see this in the future.

Therefore all claims that electron bloats 200Mb are just temporary. Its still a relatively young technology with huge potential (which also means huge potential for misuse!)

I spent 5+ years writing native GUI apps in half a dozen frameworks, I hope to never do so again unless the project's requirements ask for it, which I don't see happening for most use-cases out there.

Besides, almost nobody writes true native applications anymore - its all C# now which is ironic as its also extremely bloated with huge pools of average developers at best.

Even if the app is smaller on drive, it still takes ~200mb in ram for even the smallest apps.

Dropbox itself takes 200Mb and its a simple python app. Google drive takes 300Mb. VSCode takes about 100Mb of ram with a project opened right now. Even my Emacs takes 250Mb and I literally live inside it.

All of them have at least 2Gb of virtual memory being mapped to them. Yet I still have 9Gb of free ram.

If you want to go against bloat, you might just as well uninstall every single software from your computer, including its OS.

Literally? I demand a photo of you inside emacs

Each of those apps does a lot more than the most common use for electron: "online messengers"

Also, you're arguing in typical FYGM fashion. Not a good look.

I was merely comparing an Electron app (VSCode, not at all an "online messenger") to average apps running on the desktop because your original comment implied "200Mb for the smallest apps" which isn't true.

You could've said that clearly instead of making people guess what you're talking about.

No idea why VSCode is being sparing for you, but i've seen plenty of electron-based online messengers use that much just by running.

Meanwhile my webserver that serves 8 websites (some static sites, some sophisticated web apps) sites at 80 MB used RAM. For everything. You can't make this up.

Your web server also doesn't run X11 or any window managers nor any gui apps.

That's true, but I don't see anything in that list that needs to use multiple hundreds of MB of RAM. To witness, we had GUI apps in 1995. They look a bit nicer these days, but not multiple-100-MB nicer. :)

Emacs is far older than 1995 and still eating 250Mb :)

And there was a time when "Emacs" expanded to "eight megabytes and constantly swapping". :)

>VSCode takes about 100Mb of ram with a project opened right now.

I call bullshit on that one.

I currently have VS Code running with 7 files open, and it's using 83Mb. Like a browser, I imagine the RAM goes up with each tab, so it all depends on how many files you have open.

Well I just closed all files, disabled all extensions, restarted it and it's consuming 508MB.

>I'm fairly certain electron could easily be modified to be installed once and used as the launcher for its applications.

That's fine, we can return to this topic when it will become a mature launcher app. The thing is that today it's not in that state yet.

>Besides, almost nobody writes true native applications anymore

True native applications are not just the applications written using some native API and platform-specific low level language. Native app is the app that comfortably exists within the operating system environment, follows the UI guidelines and integrates with native UX and performance enhancing functions of the OS. For example, some universal Windows app written on C# is native on Windows.

Didn't Chrome already used to have that feature where you could install an application and it would put an icon on your desktop and open it in a browser window without tab/url bar?

But then you can't share the same code between your web application and desktop application. As a company you would have to pay two separate teams to develop each - developer time is expensive. Yes - electron apps are slower and eat more ram - but someone else is paying for that.

Should you be sharing that code? Should there be any business logic in the UI, or should it be pushed back into services that can be shared across both?

Maybe not all the code, but you can share lot of the UI behaviour, which is usually quite complicated. This kind of sharing allows you to to have a very similar experience in both places too.

Valid argument, but only in case if that web app exists. But if it exists and you want to share the code, there's no point in using Electron or building a desktop app at all: you can just create a shortcut on the desktop or even turn it into offline web app in Chrome.

not really, there can be lots of reuse of code between the two apps without them being exactly the same. Reuse of major parts of your codebase have been a business case for many years, without requiring that you reuse all that codebase.

> Yes - electron apps are slower and eat more ram - but someone else is paying for that.

I hope you're being facetious here. If you develop any kind of desktop application and truly believe this, honestly this is disappointing to read.

well if the developers or company don't actually use the app then their users are the ones paying for the ram, aren't they?

Doing something quick and dirty in electron takes N hours. Doing a 'proper' cross platform native app the right way takes N+P hours. If people are willing to pay for those extra P hours then I'd be more than happy to do things the 'right' way. However almost nobody is.

I've spent a lot of time on team web-apps-suck, and in many ways I'm still a casual fan. But the truth is I can go from zero to good enough much faster with web apps than anything else, and unfortunately most people only want to pay for good enough.

> Doing something quick and dirty in electron takes N hours. Doing a 'proper' cross platform native app the right way takes N+P hours.

Source?

Really, I'm not at all convinced that whipping up an Electron app is inherently quicker than whipping up a native app. Especially when we have robust, mature RAD tools for native toolkits, and things like Qt Quick, WPF, and Java FX let you go the whole "write your GUI in some markup language" route, if that's your bag.

>Yes - electron apps are slower and eat more ram - but someone else is paying for that.

Not that there aren't a lot of posts here defending Electron that basically say the same thing but don't you feel embarrassed in the slightest for saying that?

Yes, there's a lot of things we, as coders, can do to make our lives more convenient by treating bandwidth, RAM, and CPU wastage as an externality that can be shoved off onto the end-user to pay for. That doesn't mean we should.

I'm playing devils advocate here. It doesn't mean this is my way of thinking.

Qt now just embeds an outdated version of blink and v8. Not really a better solution.

Reply on news.ycombinator.com