Comment by natik | Hacker News Reader

Comment by natik | Hacker News Reader

Parent Full thread

I agree it quite outrageous all the RAM & Size on disk & CPU an electron app requires. But on the other hand what are the other alternative for a one codebase multiplatform app ?

Real OS native UI requires a re-write on each platform unless using libui which is limited to a button, a checkbox and a slider (okay for little app but you won't build a full blown UI editor out of that)

Then there is GTK but it has lots of problems when you want to maintain a multiplatform app, looks ugly on other platform than linux, and performance is not amazing (but with GTK4 and the vulkan renderer it might improve I guess)

At last the only real solution is QT (so it's not like there are zillions of solutions on the native side, there's only QT basically). And with QT if you use C++ then there's no package manager, all that prehistoric qmake stuff , etc... Also visually speaking QT is no more native than HTML, it has to emulate the style of the OS but is not using native OS widgets

Also Electron might feel super heavy, but in the future we might one day have Servo (which seems even more efficient that QT by doing everything on the GPU (just as an example it does glyphs rasterisation on GPU unlike QT)) with either javascript (in this case it will be kind of the same as QT + QML&JS) or with WebAssembly. And concerning the size on disk we could provide it as a dependence common to all app using it (for eg as a FlatPack Runtime on linux).

So right now Electron is outrageous but in the future the situation might improve a lot (with an alternative based on Servo if it ever happens)

Like we used to do in the good old days, before this Web 2.0 craziness, and many comercial apps still do.

Create a small wrapper layer for the supported OSes, which is the option used by most comercial software actually, like Adobe or Office, and many others.

Electron apps basically put the confort of developer in front of the user they are supposed to serve.

There is one more thing. Developing in HTML5/JS (with all its ecosystem) is freaking fast in terms of developer productivity. You will probably build full fledge app in shorter time using JS than with C++. So you can deliver MVP to the market faster = profit $$$

And initial group of users are early adaptors anyway. They are usually eager to try new applications even if they are not perfect.

The problem is: "what next?", when users will start complaining about speed or other things.

Should company rewrite original HTML5 based MVP to C++ to gain speed?

Or should they optimize existing HTML5 solution? (many HTML5 apps are running with nearly native responsiveness).

Or something else? Or maybe HTML5 even for MVP is a bad idea?

How did you make the conclusion that JS is faster than C++? An experienced C++ developer, or better yet, an experience C++ developer team, moves “freaking” fast. The only advantage to the HTML/JS stack is you can get cheap labor from dime a dozen web “devs”. That’s it.

Case in point, look at Atom. Let’s assume your “MVP”, “profit $$$” and what not is somewhat correct. Yet, the amount of engineering time and effort it has taken to optimize that tech to fix things that are trivial in the native world is staggering. How does that fit in your “profit $$$” equation, as an initial core team of experienced C++ developers would have developed with these issues in mind and created a product that is viable in the same scenarios.

Ok, maybe I will reconsider C++.

But if you were building such app in C++ what third part solutions would you recommend for building multiplatform GUI? Qt? GTK? What is used now and what will be working/looking good on all three main platforms? (Mac/Linux/Windows)

Fuck user experience! All that matters to “developers” these days is “hackablility” and “velocity”. The user suffers? It’s his fault he is not using a better device.

I agree it quite outrageous all the RAM & Size on disk & CPU an electron app requires. But on the other hand what are the other alternative for a one codebase multiplatform app?

If the program fulfills their needs well enough, users don't care what it's written in or how fat it is.

And multi-platform matters. I've seen blog posts on how to get Sketch running on Windows using a Mac VM. Talk about using system resources.

I think Atom gave bad fame to the Electron (it's ironically because Electron was made for Atom).

Atom is bloated and slow and people think that each Electron(or Chromium) app is bloated and slow.

But for example VSCode is a lot faster (and consumes less RAM, from what I just checked) than Atom. So it's not Electron to blame...

Not only Electron to blame. Electron still gets a decent share of the blame, simply because it's a memory and CPU hungry runtime.

Many consumer laptops are still shipping with only 4 gigs of ram - that's not a lot of space for Electron apps.

I noticed you've been downvoted. I find it amusing the expectations some people have about the hardware consumers should be running. While many on here, being a geek community and all, will have relatively decent systems; most normal people would rather keep a system as long as they can. Not to mention those in poorer communities or countries who cannot afford newer tech.

In fact it was only this year when I upgraded a work colleagues personal laptop from 2GB to 4GB.

Meta:

Downvoting is an accepted method of disagreement on HN. It's a problematic stance IMO since downvotes grey out the text, making dissenting opinions impossible to make out if they're unpopular enough.

Back on topic, 4GB laptops are incredibly common, especially in retail stores. Getting a laptop with 8 GB of memory frequently requires looking online (most folks still buy their computers from retail stores) and customizing your order.

For example, I just visited both Dell and System76, and except for the gaming laptops, all of them default to 4GB of ram, and adding more (while not terribly expensive) requires thought and action on the consumer's part.

It's interesting. What browsers do people use on this machines? Though according to wikipedia most popular browser is Chrome: https://en.wikipedia.org/wiki/Usage_share_of_web_browsers

but it seems weird, because Chrome is such a memory monster (it usually takes almost all RAM memory you have on your machine and additionally disk space if you are running of RAM). I have 16GB ram and Chrome takes me 10GB of it and ~1GB of disk space.

I've been downvoted because HN has Dislike Button which encourages people to downvote things they personally don't like instead of making constructive arguments ;)

If it's any consolation I did provide a counterargument and got downvoted for it.

As for the 'flag', that's not the same as downvoting. Or at least shouldn't be used in the same way although I have lately seen a disappointing number of comments marked as "flagged" which shouldn't have been. (There's some guidance about flagging posts here: https://news.ycombinator.com/newsguidelines.html). Downvoting is something that's only available to members above a specific karma threshold (2000 IIRC).

I upvoted you.

BTW how to downvote comments on HN? I sometimes "flag" them to mark as downvote, but I'm not sure if flag is the same as downvote.

You need karma > 500 to downvote. And even then, you cannot downvote replies to your own comments etc.

> I think Atom gave bad fame to the Electron And GitHub “desktop” client, and Slack “desktop” “app”, and Git Kraken… The list goes on.

I've found every Electron app I've used to be terrible. This includes VSCode. In fact compare VSCode to Adobe Brackets - both of which are using web technologies as their framework but Brackets is a node.js application while VSCode is Electron, and you'll see just how badly Electron performs when even compared to similar technologies.

I used Brackets maybe 2 years ago and it was very slow back then. Maybe now they have optimized it, I don't know.

Oh it's definitely slow compared to the likes of Sublime Text or vim. But compared to Atom, VSCode, etc Brackets feels a lot snappier and less memory hungry.

This is what I've experienced on 4 different hardware platforms however all running ArchLinux so YMMV.

VSCode is visibly slower than Emacs on my Ubuntu travel netbook.

I only use it due to its Rust's support.

Reply on news.ycombinator.com