Hacker News Reader

Comment by zarzavat | Hacker News Reader

> Is "just stick Chromium into all your apps" seriously the best we can do as an industry?

Yes. What other rendering engine are you going to use? If your answer is anything but a web browser rendering engine, then consider that any serious UI toolkit in 2022 is certainly going to need a WebView UI component: so if you want the WebView UI component to be consistent across platforms (you want this), then you will have to bundle a web rendering engine anyway. In that case, why not just use the web rendering engine as your main rendering engine?

There’s nothing wrong with Electron as a concept. The issue is with either: blink being under optimized for this use case, or bad Electron apps.

View on HN

> What other rendering engine are you going to use?

the native window environment?

> any serious UI toolkit in 2022 is certainly going to need a WebView UI component

citation needed. why do slack and discord - communication applications - need a web view component?

> In that case, why not just use the web rendering engine as your main rendering engine?

because, aside from the frankly obscene memory usage, it adds so much to the binary (mIRC used to fit on a floppy), it’s slow, is bad for battery usage, it doesn’t look in line with native apps, and it’s a huge attack vector.

> it’s a huge attack vector.

I'm confused by this phrase. Wouldn't it have a 'huge attack vector space' ? I never really understood that phrase.

vector is like an angle and a magnitude, perhaps you mean attack surface, which is the integral of known attack vectors.

Vector is being used here in the epidemiological sense, not the mathematical sense.

> the native window environment?

I'd rather build an app that doesn't require me to start with the question "which OS and window environment are you using?" followed by "sorry, we couldn't afford to build for that".

The idea that app developers have resources, skills and manpower to build ~3-7 UIs using ~2-3 different stacks – for exactly the same app – is imo more preposterous imo than assuming most users have enough ram to run a chrome+node instance.

The failure of standardizing UI has led to this. Electron is a stop-gap, a good one. As a Linux user, I am very happy that Electron exists, otherwise I would have far fewer apps.

Yes, Electron hogs resources. I am personally using Tauri, which has a much lower footprint. Importantly, I can write my app once.

> I'd rather build an app that doesn't require me to start with the question "which OS and window environment are you using?" followed by "sorry, we couldn't afford to build for that".

i can’t help but feel your catastrophising a bit here. in any case, you have options that would greatly ease pains of this sort, wx, QT, SDL, etc. there are many. the point is that the problem with electron isn’t UI abstraction in general, just this particular implementation of it.

> [it’s safer to assume] most users have enough ram to run a chrome+node instance.

so in an effort to avoid saying that you “couldn’t afford some feature”, you’re presuming that users can afford the resources for another multi-gigabyte ram hog, which is most likely, for all intents and purposes, a pretty wrapper around JSON getters and setters?

> The failure of standardizing UI has led to this. Electron is a stop-gap, a good one. As a Linux user, I am very happy that Electron exists, otherwise I would have far fewer apps.

strong disagree here. i’d bet that electron and it’s ecosystem exists strictly only because of the abundance of engineers proficient in javascript. electron absolutely did not standardise UI.

sorry if that’s come across as inflammatory, it’s not intentional. i guess i get a bit irrationally upset when i see i can trigger a full page refresh of what should be a native application when i hit CTRL+shift+R.

> i’d bet that electron and it’s ecosystem exists strictly only because of the abundance of engineers proficient in javascript. electron absolutely did not standardise UI.

Bingo. We have a glut of developers who only really know web tech, and when they decide they want to do something for the desktop they just go with what they know instead of learning something different. The argument about portability that people make in support of Electron-based stuff doesn't hold up when you see that there exist cross-platform tools for other languages. At the end of the day, the tech world is crawling with JS developers who appear to be unmotivated to learn something other than JS (or one of its transpiled cousins).

> they decide they want to do something for the desktop they just go with what they know instead of learning something different

Shouldn't the burden of proof be reversed? If the stack works, why relearn in a different stack? The HN crowd loves to shit on web developers for not being good enough even at their own domain, yet at the same time encourage them to learn new tech. Proficiency takes time.

As for the environment itself, web has the best inspect/debugging experience by far, an extremely capable and flexible layout engine and accessibility built in. It's also not controlled by a company, and has ubiquitous platform support.

Obviously there's a network effect, which to a large extent led to this situation. But it also makes sense to learn today. If I was advising a junior it'd be criminally myopic to suggest learning Qt instead of web.

> sorry if that’s come across as inflammatory

No worries at all. If everyone shared my opinions I'd go somewhere else (or question my sanity). Also, I'm triggered by unnecessary bloat as well.

> electron absolutely did not standardise UI.

Of course not!

> you have options that would greatly ease pains of this sort, wx, QT, SDL, etc

Yes, but they really need to work on web too, if you have a web app that shares code with the native one. Otherwise you still have two UI stacks. I was seriously considering flutter, but dart is a small ecosystem and most importantly if Google pulls their support it will almost certainly die.

Web tech isn't perfect, but it's very mature and standardized. Sure, you can bloat your app/page, but if you are just moderately responsible things are very snappy. Today, you don't even have to use JS with wasm. Tauri allows me to use web tech with much lighter weight OS webviews and no Node.

> you’re presuming that users can afford the resources for another multi-gigabyte ram hog

If your crud like app is anywhere near 1GB in ram, there are other issues. Electron adds maybe 200Mb overhead, the rest is the web app itself. App bloat is a separate issue.

> the native window environment?

This means you’ll be limited to the intersection of features of each platform native rendering engine.

On the other hand you get the union of all bugs and performance issues over each native rendering engine on each platform.

Text will be a particular nightmare, what browsers do in terms of pixel consistent yet native-feeling text rendering and input is a miracle.

> citation needed. why do slack and discord - communication applications - need a web view component?

Perhaps those apps specifically don’t use it, but it is a standard component and all modern UI toolkits are expected to have one because many apps do need this functionality.

> This means you’ll be limited to the intersection of features of each platform native rendering engine.

> On the other hand [...]

we already live in this world. electron utilises the same APIs you would use. it doesn’t have a back way around these, and is subject to the same bugs and issues from the windowing system would be.

it might be tempting to suggest here that electron devs can mitigate issues themselves and remove the need for that work on your part, but now you need to update your app: shared libraries aren’t exactly in fashion right now, so every electron based app needs updated.

that in itself has a bunch of issues/consequences. if nothing else, it’s incredibly wasteful.

> citation needed. why do slack and discord - communication applications - need a web view component?

YouTube/SoundCloud/Spotify/etc embeds would need a webview component if Discord was a native desktop app.

so we can lose local browse history, have to maintain two separate login session to each respective service (repeat for slack too, where appropriate), all just to have the video or song play in the same window..?

well, fine, if that’s what’s required. all of the platforms have webview components, i believe.

> There’s nothing wrong with Electron as a concept.

I'm mainly avoiding it because I want to make an app I can use (after all, I'm primarily making this for myself), and not just have a desktop app for... someone. My laptop only has 4GB of RAM, so Electron is off the cards for what I need.

This always frustrated me with Slack. It has often been the thing running on my computer using the most RAM, yet Slack is never the primary tool I'm using the computer for. That is, communication is always a secondary thing to support my work doing something else or to allow me to do that something else in a team. Its about that other work though, not the communication. Maybe some day soon I'll have a laptop with 32 GB of RAM and there will be more spare resources available for Slack to eat, but until then, I really dislike running Slack.

So yeah, I still greatly prefer desktop applications to use native UI's and prefer to avoid browser applications where I can. But its becoming increasingly hard.

Of course, I, too, am building browser things, since that's what the industry seems to demand, so I'm not really helping the situation. I do keep meaning to learn Flutter though.

> This always frustrated me with Slack. It has often been the thing running on my computer using the most RAM, yet Slack is never the primary tool I'm using the computer for. That is, communication is always a secondary thing to support my work doing something else or to allow me to do that something else in a team.

Same with me, but s/Slack/Microsoft Teams. I personally find it absolutely horrendous to use and wouldn't recommend it.

> Of course, I, too, am building browser things

Same. That's what I'm primarily familiar with, especially React. I hope some day we have something like React Native for desktop, where it integrates with the native widgets of the platform (Qt, perhaps?) and you just integrate them with your app through components... like React Native on mobile. It's such a shame this space isn't being properly explored yet.

I'm not even sure that laptops are still sold with 4GB of RAM? You have a very niche usecase.

It lists 37 here [1]. Pretty sure people are still buying them.

https://www.mediamarkt.nl/nl/category/_windows-laptops-64106...

I can say a lot of people only uses computer for typing papers or watching movies - bigger display and storage. My cousin does everything else on her phone.

I wish I wasn't poor. Hoping to get a laptop with a bit more later on.

How is 4GB RAM installed a niche use case?

If this is the route software development is intended to take where every app is going to consume +4GB RAM good luck running multiple apps at the same time or running it on a smaller form factor.

It is truly bizarre that we are moving away from the desktop PC to smaller form factor but at the same time pushing technology that requires a desktop PC.

What range of memory usage are you going for? You could maybe look into using Electron solely for the GUI and using C/Rust/Go for the backend. Haven't done anything like that myself but from what I've read it's a decent compromise.

I'll take anything under 300/500MB as a win, though I admit under the circumstances that's going to be very tight.

The Web is semantically consistent across platforms. There's no need to use the exact same rendering code on every platform.

Look I get the idealism but being able to target a single version of a single browser at a time is vastly simpler than dealing with every browsers quirks and missing features.

> There’s nothing wrong with Electron as a concept.

There is nothing wrong with Communism as a concept.

Nack in the real world, open Whatsapp desktop and scroll though any chat dense with images, it takes me over 40 minutes to acroll back 1 year on a 12-core ryzen.

On Telegram Desktop, native client, this takes 30 seconds.

If you think this spitefull disregard of end users is justified, you live in cloud coocoo land

I would say, use native webviews, eg. WKWebView on macOS.

But unfortunately it comes with occasional bugs that are impossible to fix for app developers, so if you want complete control you can't use it

You could use a webview shared at the system level, so you don't have in memory 4 different browser engines.

Browsers themselves don’t do this for security snd sandboxing reasons. Each tab is another instance.

Each tab is a partial instance. There are still many resources that are shared globally for performance and memory use reasons.

But operating systems are free to map the same read only memory pages (e.g. program code) into different process address spaces. This is an optimization that running processes are generally completely oblivious of. But it only works when e.g. the program code is mapped into memory from the same file. If every program has a private copy of the same library (even if it's bit for bit identical), the operating system doesn't have enough information to pull this off.

I think the part "if you want the WebView UI component to be consistent across platforms (you want this)" is a reference as to why a built in webview won't be good enough.

Reply on news.ycombinator.com