Hacker News Reader

Comment by Klonoar | Hacker News Reader

Most people don't seem to grasp that in this day and age, any GUI program (at least on OS X) is going to be minimum 20MB due to the retina display. Add in that realistically you need to use Webkit (or some HTML renderer), at which point... 100MB is pretty good.

For reference, an RSS reader I threw together using standard Cocoa widgets will hit 50-60MB with no issues, and that's with my being annoyingly judicious with how it's built.

View on HN

Telegram, which I believe uses Qt, currently sits at 90MB on my macbook. It's not great either, but how much would a "Hello world" Electron app need?

Telegram is native code (Swift/etc), not Qt* - at least, depending on which version you're using, and it largely eschews webviews short of one or two places as far as I know.

* - Unless you're using the (older, I believe) Telegram Desktop client, which is different from... Telegram.

Telegram Desktop is the current client for all major desktop platforms. The last commit on the repo was yesterday. It does use Qt. And how is Qt not native code? It's C++. The Android client is mostly Java, the iOS client is mostly Objective-C, and there's also an actively maintained web client.

https://github.com/telegramdesktop/tdesktop

Mmmm incorrect. See: https://macos.telegram.org

Which clearly links source as: https://github.com/overtake/TelegramSwift

Nobody I know on OS X would use the Qt one as it feels really out of place... I guess if you cared about ricing out your desktop or something.

Or have consistent experience across platforms.

edit: 200MB installer compared to 30MB for the "Telegram Desktop".

> Add in that realistically you need to use Webkit (or some HTML renderer), at which point... 100MB is pretty good.

Why do you need an HTML renderer? Slack uses Markdown.

emacs-slack is pretty lightweight …

>Why do you need an HTML renderer?

Because it's objectively easier to do cross-platform GUI development using a single, well-defined and portable API that someone else maintains.

That that API is nowadays de-facto WebKit supporting a HTML/CSS/JS stack is a natural, but unfortunate choice, and it's got a much lower barrier of entry and much less maintenance overhead than, say, Gtk+ or Qt.

Slack uses Markdown, yes, but supporting everything under the sun that Slack does (especially as they add new things) is just much easier inside a Webview.

The job of programming isn't to reinvent the wheel everywhere, it's just to deliver a product that doesn't suck - with native code, you're implementing a native solution for each feature Slack has or adds. Slack's content is web content.

You're really arguing that an insane amount of extra engineering time should be spent to conserve, at best, an extra 40-50MB of RAM... and this is disregarding how modern RAM works anyway.

> Slack's content is web content.

That's the underlying issue. If the "protocol" uses HTML, all clients will need to embed a web view.

And to think the first WWW browser just used Next's Text view.

Consider compressing your graphics (pngnq et al), or use resolution-independend image formats, like SVG.

I think ultimately the image has to be represented as a bitmap in memory somewhere, right?

Reply on news.ycombinator.com