5 ms·

Native desktop apps are far superior to Web/Electron

73 points by me551ah 6y ago

polote 6y ago
The name of the post should be "We need a better alternative to Web(& Electron) apps". As the article doesn't talk about the current title at all, and only encourage flame war discussions
- deleted 6y ago
  [deleted]
julius_set 6y ago
I mean it’s pretty obvious, any abstraction that aims to consolidate multiple platforms will come at the cost of performance
osrec 6y ago
From a previous comment of mine: There is a need for native apps, however that need is shrinking and, in my opinion, will continue to do so. I also happen to think that's a good thing. The issue is that developing for a particular OS is, generally, more difficult than developing for the web. The app delivery mechanism is also more convoluted (for native apps) than simply entering a web address in the browser. The web also seems to have more ubiquitous standards that abstract away the differences between OSs - you can, with a high degree of certainty, ensure that your app is usable by 99% of computer users, given the current software they have on their device - with native apps, there is no such guarantee, especially if you're relying on shared libraries. Browsers are also becoming more feature rich. This has had a negative impact on their memory consumption, but given it's 2020, some may retort "memory is cheap" (I totally disagree with this way of thinking personally). And while some browsers (Chrome, looking especially at you) do a very poor job of memory management, I believe the competitive nature of the browser market will force a reawakening soon, where a lot of the inefficiencies in memory management will have to be eradicated (or vendors risk losing market share). Think back to 2014/15 when Node.js was really becoming established - the PHP team suddenly felt a need to re-optimise their engine for PHP7 (and with dramatic results)... Point is, only after ~20 years at the top did something spur PHP's team on enough to do something about their inefficiencies. Finally, I can see a future where the line between web and native apps is even more blurred. WebAssembly is the first step, however things could get even more elaborate. Perhaps we could end up with the ability to start docker-like containers from within web apps (given the right permissions, of course) to spin up servers for audio/video/image processing on the client itself, and interact with them via a web page. If we get to this point, native apps may feel even more obsolete. I know this post relates primarily to the current state, but I felt the need to talk about the future to highlight the marked difference in the rate of innovation in the web ecosystem (fast) vs the native ecosystem (slower). It would not surprise me if the web ecosystem ends up winning in the end. If I was building an app today, and it only requires features I can deliver via the browser, I would almost certainly go the web app route. Now, if I was building a video processing app today, I'd almost certainly go native, but in a couple of years, my answer may be very different.
- arexxbifs 6y ago
  > that need is shrinking I'd say the "need" is shrinking because the number of viable options are shrinking. I'd throw out every single Electron app and replace them with native if it was possible. They're almost always either frustratingly slow or poorly designed. Oftentimes they're both.
  - osrec 6y ago
    I don't disagree, but I think there may be better alternatives to Electron in the not so distant future. I don't think the concept of Electron is bad (i.e. one API regardless of the target platform), but the execution of that concept is. I strongly believe we will see some major improvements in the performance of Web apps/Electron, since (a) there is a lot of incentive (b) there are many easy wins to be had in terms of performance.
- andrekorol 6y ago
  I can see this containerized future that you've envisioned solving a lot of the current performance problems of web apps.
  - osrec 6y ago
    Wouldn't it be amazing?! You could even have the browser allocate a volume or two for the container to use (with the user's permission, of course) to store data locally. And users could be allowed to adjust how much space the volume may use (from some default minimum to unlimited). And with containers, the client should be reasonably safe even if executing malicious software.
scottmcdot 6y ago
I really don't like the lack of responsiveness that some Web apps have. I remember coming from Teradata SQL Assistant to Cloudera's Hue and being so frustrated by the latency of editing code (pushing the keyboard and seeing the letters appear). It would often result in me inserting random characters.
sanxiyn 6y ago
JavaScript is not slow. Python is slower than JavaScript, but if you compare a native desktop app written in PyGTK against an app written in Electron, you will see JavaScript being slow is not the problem.
- pmlnr 6y ago
  JS is not slow. Every effin JS framework is. If there was a real stdlib for JS it might work as an actual language.
pier25 6y ago
Electron apps aren't made because the end result is superior but because of budgets and schedules. Not even a company like Slack wants to get into the headache of maintaining a couple of native desktop apps, even if they probably have the money to do so.
- pmlnr 6y ago
  Slack is API calls. I have a hard time believing a few thin client interfaces - win, darwin, ios, android, gtk, qt - would be that hard with a company size of slack.
  - MattGaiser 6y ago
    The question is not whether they are hard, but whether they are harder and whether that harder is worth it. Has Slack lost a single paying customer of this? I doubt it.
- Qasaur 6y ago
  I've never really understood this way of thinking. In my experience, it is trivial to maintain cross-platform applications if you encourage code-reuse in the logic layer and tailor the UI/UX experiences for the platform you are targeting. In practice this usually means writing the client business logic in a high-performant language that can target multiple platforms (I've only used Rust for this, but there are other languages out there that would work well with this approach as well), and using FFI when interacting with the UI layer. Combine this with good message passing practices (to homogenise serialisation/deserialisation and avoid the complexity of having hundreds of different FFI functions with various parameters) and you've got something that is easily integrated in platforms with little headache. I've seen great success with this approach for most platforms including mobile as it provides the end-user with a great user experience (you can use all the native UI APIs which provides an experience that the user is already familiar with) as well as extremely high performance with a high degree of code reuse.
  - MattGaiser 6y ago
    But why bother even setting up different build environments for the different platforms? Even that part makes it already more work than Electron and I can't think of any meaningful business benefit to not using Electron.
muthdra 6y ago
It's always been. But the web stack is the most widely supported, low development effort target we know and even though it's bad, there's value in integrating and expanding it.
deleted 6y ago
[deleted]
giovannibonetti 6y ago
A good alternative that is coming to fruition is a modern alternative to Qt called libui [1]. Description from the project page: "Simple and portable (but not inflexible) GUI library in C that uses the native GUI technologies of each platform it supports." There are bindings for it in many languages, like Node.js, Rust, Swift, Kotlin and more. [1] https://github.com/andlabs/libui https://github.com/andlabs/libui
thethethethe 6y ago
Seems like the only argument here is: “web apps are slow and use a lot of resources” This isn’t a great argument by itself. There are many reasons that web apps are superior and more convenient than desktop apps. If this wasn’t the case, then why are web apps winning? I don’t want to download and execute a binary just to read my email, make a video call, or read the news. Web apps are also cross platform. You can pretty much guarantee that gmail will work the same on windows, Mac, Linux, Chrome OS, and even iOS and android (with some idiosyncrasies). Web apps also update themselves, they take up no space on your computer, and can be customized using browser plugins. I’d take these advantages over saving a few gigs of ram, which I have plenty of.
- taeric 6y ago
  Objectively, web apps seem to be winning as they let the companies keep control over application and data. With a bonus that they can monitor/track usage. That is, few, if any, technical advantages for users. Just fewer choices, as well.
- pmlnr 6y ago
  > that gmail will work the same on windows, Mac, Linux, Chrome OS, and even iOS and android Nope. This is the Java Virtual Machine promise all over again. It didn't work. It doesn't work the same in Safari or Firefox as it does in Chrome.
  - thethethethe 6y ago
    Is chrome not consistent across operating systems?
    - pmlnr 6y ago
      Is it not. For example hardware acceleration is terrible under linux.
- deergomoo 6y ago
  > If this wasn’t the case, then why are web apps winning? Because that’s usually all that’s being provided? I don’t think it’s valid to say web apps are “winning” when in many cases they’re the only 1st party option. I don’t have any figures to back it up but I would not be surprised if the native app versions of Twitter, Facebook, Instagram etc. see far more use than their equivalent web app versions. > I’d take these advantages over saving a few gigs of ram, which I have plenty of. That’s all well and fine until everyone decides to make the same decision, and suddenly every application needs its own instance of Chromium to run.
underdeserver 6y ago
You actually can use sqlite, compiled with Emscripten, in a browser (storage is done via IndexedDB).
eludwig 6y ago
Gosh, I’m really sick of this argument. Sure, everyone loves hand-crafted, beautiful, native apps. But I will tell you this: it is possible to build a great app using any technology. It’s just a matter of taste & effort. My favorite tool that helps me get my day job done is VSCode. Do I care whether or not the damn thing is native or not? NO! Do I care that it gobbles some meager gigs? NO! Memory not being used is memory being wasted. Use my RAM, dammit. I can buy more. Use whatever you have to do to keep making this lovely thing that saves me so much time everyday and practically reads my mind as a JS developer! It has a elegant, raw beauty to it that totally fits my needs. If it uses some hybrid web technology stack, what do I care? Is it great? To me, yes! Make great apps. I don’t care how you do it.
- blondin 6y ago
  you have to understand one thing. if you have been using computers and applications that come with them for a while you have an intuitive sense how how big, how fast, and how much resources some of them should take. that's what is happening here. most people who are disagreeing with you know intuitively that it is not right, for a chat app -- going for an easy target here -- to grab all your available resources.
on_and_off 6y ago
> When apps are built for mobile, battery usage is a major area to optimize on. I worked on some heavy duty mobile apps like music streaming and unfortunately battery usage is the last thing we optimize for. The platform even provides us with some ways to measure it, but it is just so remote from the metrics we do optimize for that except for major problems, we don't focus on it in the slightest. >Mobile apps run at 60fps out of the box without much effort. Technically fps is not the best way to measure this (we tend to focus on dropped frames instead, unlike most video games engines; mobile will not recompose your UI if nothing moves, saving cycles and heat) Lots of efforts have actually been made to optimize mobile apps. We are starting to reach a point where we do have a top to bottom approach for reasonable performances (try to scroll any app insanely fast .. you will drop frames, but in regular usage; dropped frame are not too noticeable on recent top of the line phones). Agreed on the article though. Nothing more irritating than running a legitimately demanding application, seeing that it does not have enough resources and realize that a small web app in the background is using 37 cores and 50% of your cpu while you are not even using it (that was whatsapp just now).
k__ 6y ago
They are, just not in the ways most users care about. Sure, Ableton Live and Final Cut Pro are pretty rad, but how much percent of the population uses such tools? I even switched from Photoshop to Photopea and from Sketch to Gravit Designer, because they are good enough and much less hassle.
Bnshsysjab 6y ago
As someone who agrees that every electron app appears bloated, but wants a minimal fuss, feature rich, attractive, cross platform UI, what are my other options?
- samwillis 6y ago
  QT
andrefuchs 6y ago
There are pretty good Chrome Desktop PWAs like photopea.com (a free Photoshop alternative) I also like that PWA and Electron made more tools on Ubuntu available. Postman and Gravit Designer are great examples. Memory consumption and performance are problematic though for a lot of them - Electron apps especially.
redleggedfrog 6y ago
I'd take it even further. Browsers and things like Electron are just run-times. The browser's main advantage is cross-platform compatibility. But only kinda-sorta as any web developer can tell you. Your code is usually targeting 3 different run-times at a minimum and there are always problems with anything non-trivial. It is easy to imagine something much better, where your code runs on a nice tidy runtime native to the OS, with relatively easy layout tools and a language that is better than JavaScript (and really, what language isn't?). It'd be nice and fast, and rewarding to develop in. If we are starting anew, with fresh eyes, and we were handed browsers, with JavaScript, CSS, and the DOM, we'd be like, "This is complete BS. Visual VB for DOS has this beat." But because it grew organically, with instantly built in lock-in, and we're now thoroughly indoctrinated, the Stockholm Syndrome lives on. If you can just take 3 steps back it's fairly obvious. But people would rather just keep making the next React or Bootstrap and digging the hole deeper than make something better. Someday, make my words, there will be a cross-platform runtime that doesn't suck, that doesn't use JavaScript, and won't the stupid mistakes of the JRE, and developers will abandon web browsers as a platform in droves. I mean, can you really see this as the state of affairs in 2030? 2040? That'd just be sad. Edit: typo
- arkanciscan 6y ago
  > It is easy to imagine something much better, where your code runs on a nice tidy runtime native to the OS Yeah, cause that's how every native platform has been since the begining. Yet the web still needed to be invented. Why?
  - Spivak 6y ago
    Because no two platforms can agree on anything so now we have "hosted platforms."
  - thayne 6y ago
    The biggest reason is probably that you don't need the user to explicitly download and install your app. Also, a web app works on all the major OSes with a single GUI environment. And then of course the fact that webapps run in a more secure sandbox. A standard cross API and sandbox could potentially solve the second two. But I'm not sure how to solve the first outside of a browser.
deleted 6y ago
[deleted]
jwilliams 6y ago
This is an interesting debate, but I don’t think this is useful framing: “And it’s laughable how weak the browser platform itself is.” Which begs the question of why then do developers use web/electron? Ubuiqity, cross-platform, distribution, updates... and, yes, some developers also prefer web api. Perhaps the question is how do we bring a web/election experience to native apps?
- sanxiyn 6y ago
  I think Flutter is an attempt to answer that question. Whether it succeeds is not yet clear, but what is clear is that it is trying to answer the right question.
felixrieseberg 6y ago
Look, I get it, "less web apps" is an easy post to write these days, but all I ask is that we tone down the FUD. Let me just pick off the inaccuracies that will likely stick the most: > But building for the web(and electron) forces you to HTML/Javascript(and derivates). This is incorrect. Electron supports Objective-C, C++, Rust, and obviously WASM (amongst others). If you want to build native code (and native UI) in any of these languages, go for it. Countless Electron apps have native components. > It has no type safety, memory leaks are common and it’s slow due to its dynamic nature. TypeScript has been a thing for a while now. [Citation needed] for the statement that memory leaks are more common than in, say, C++. Slow: Yes, it's slower, but probably by _a lot_ less than you think[1]. > And it’s laughable how weak the browser platform itself is. SQLite is available on raspberry pi, embeddable systems, mobile platforms and just about every other platform on the planet. I agree, SQLite is fantastic. We don't really have to argue whether IndexDB will get thee job done, because native bindings to use SQLite with Electron exist. Just... use it. And lastly... > These days to send a text message over Slack I need over 1GB of RAM. [...] Even basic apps with all of their trackers, external javascript scripts and doms take up 100s of MBs in memory. We're always working on performance and we're quite far from the place I'd like us to be at, but it'll send your message just fine if you have less than one GB of memory installed in your whole machine. Even if you're a heavy user, your memory _should_ be below one GB. To be clear, I'll say it again: Yes, things should be better and we'll keep working on performance. The post mentioned Instagram earlier, which I'd say goes a bit beyond the most basic app, and it's using a humble 40MB on my machine. Disclaimer: I'm one of the maintainers of Electron and an engineer at Slack. I'm not here to argue opinions or which tool is better for which job, but we should get the basic facts right. [1]: https://www.youtube.com/watch?v=81CECdKCJNc https://www.youtube.com/watch?v=81CECdKCJNc
- thayne 6y ago
  > TypeScript has been a thing for a while now. Yes, and typescript is great. But you do need a rigorous approach with it to get type safety on parr with languages like java and c++. And since that type information is lost by the time it gets to the interpretor, it provide any benefit to performance. For example, the js interpretor has to check the types if operands at runtime to perform addition. JIT compilation helps a lot, but if the interpreted language had stronger typing, the JIT compilation could probably do an even better job, since it could make more assumptions.
Schnitz 6y ago
Native apps always win, except in the race to the bottom.
- arkanciscan 6y ago
  Always bet on JavaScript
dang 6y ago
When there's a major thread on a topic, like https://news.ycombinator.com/item?id=23211851 https://news.ycombinator.com/item?id=23211851 which is currently at #9, it's better to post follow-up links in the thread rather than as separate submissions. Otherwise the front page gets repetitive. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20follow-up&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... Also, please don't rewrite titles to make them more baity - this is in the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
- me551ah 6y ago
  Author of the article here and the one who made this post. I did post this as a comment on the post you mentioned, but given that I'm already late I haven't seen any upvotes to it. So I decided to make a submission. Sorry about adding to the clutter. Sorry if the title now appears to be more baity, I was actually intending this to be a response to the Ask HN post on the front page. I figured it would be okay for post Authors to change the title since I can always change it in my original post. EDIT: I have changed the title of my original post.
arkanciscan 6y ago
> Trolly click bait titles get a lot of comments/replies Fixed your title!!
thegreatpeter 6y ago
Check out Revery UI: https://github.com/revery-ui/revery https://github.com/revery-ui/revery This is the replacement for Electron/Web. Built on top of ReasonML which offers a JavaScript like syntax (and supports your favorite libraries too) Revery UI can successfully target web, native desktop for Mac, windows & Linux with mobile coming soon. The case studies are great!
MattGaiser 6y ago
Very little matters for most pieces of software besides time to ship. If the average user isn’t technical/is forced to use it, there is no business reason to care about user battery life. There is no business reason to care about user cpu usage. Any reduction in user resource use would require greater business resource use (i.e one of their engineers needing to learn native). Are users willing to pay more for software that saves their battery life? Generally not, as most don’t even know why their battery is draining or their computer is slow. They just blame it on viruses, Windows, or general belief that their computer is getting old.
watersb 6y ago
I believe that Microsoft has tried to build a better Electron for at least the past ten years. The latest attempt is WindowsUI hosting React Native. I think. This past week, I have tried to walk through a "Hello World" for this pre-release platform, but I have failed to get a build system actually working. Its the "keep installing software until it works or until your system breaks, whichever comes first" problem. For now, I have chosen to preserve my ignorance of Visual Studio's build targets and project structure. I can only learn five new tools at a time.
vkhn 6y ago
This is such a silly article. Of course they are technologically superior. This is like saying bare metal is better than a virtual machine. Of course. But they are not universal for several reasons you fail to account for. I won't bother categorically defending anything in this article, but I will leave a single statement: good, fast, cheap - pick two.

73 points by me551ah 6y ago

The name of the post should be "We need a better alternative to Web(& Electron) apps". As the article doesn't talk about the current title at all, and only encourage flame war discussions

deleted 6y ago
[deleted]

julius_set 6y ago

I mean it’s pretty obvious, any abstraction that aims to consolidate multiple platforms will come at the cost of performance

osrec 6y ago

From a previous comment of mine: There is a need for native apps, however that need is shrinking and, in my opinion, will continue to do so. I also happen to think that's a good thing. The issue is that developing for a particular OS is, generally, more difficult than developing for the web. The app delivery mechanism is also more convoluted (for native apps) than simply entering a web address in the browser. The web also seems to have more ubiquitous standards that abstract away the differences between OSs - you can, with a high degree of certainty, ensure that your app is usable by 99% of computer users, given the current software they have on their device - with native apps, there is no such guarantee, especially if you're relying on shared libraries. Browsers are also becoming more feature rich. This has had a negative impact on their memory consumption, but given it's 2020, some may retort "memory is cheap" (I totally disagree with this way of thinking personally). And while some browsers (Chrome, looking especially at you) do a very poor job of memory management, I believe the competitive nature of the browser market will force a reawakening soon, where a lot of the inefficiencies in memory management will have to be eradicated (or vendors risk losing market share). Think back to 2014/15 when Node.js was really becoming established - the PHP team suddenly felt a need to re-optimise their engine for PHP7 (and with dramatic results)... Point is, only after ~20 years at the top did something spur PHP's team on enough to do something about their inefficiencies. Finally, I can see a future where the line between web and native apps is even more blurred. WebAssembly is the first step, however things could get even more elaborate. Perhaps we could end up with the ability to start docker-like containers from within web apps (given the right permissions, of course) to spin up servers for audio/video/image processing on the client itself, and interact with them via a web page. If we get to this point, native apps may feel even more obsolete. I know this post relates primarily to the current state, but I felt the need to talk about the future to highlight the marked difference in the rate of innovation in the web ecosystem (fast) vs the native ecosystem (slower). It would not surprise me if the web ecosystem ends up winning in the end. If I was building an app today, and it only requires features I can deliver via the browser, I would almost certainly go the web app route. Now, if I was building a video processing app today, I'd almost certainly go native, but in a couple of years, my answer may be very different.

arexxbifs 6y ago
> that need is shrinking I'd say the "need" is shrinking because the number of viable options are shrinking. I'd throw out every single Electron app and replace them with native if it was possible. They're almost always either frustratingly slow or poorly designed. Oftentimes they're both.
- osrec 6y ago
  I don't disagree, but I think there may be better alternatives to Electron in the not so distant future. I don't think the concept of Electron is bad (i.e. one API regardless of the target platform), but the execution of that concept is. I strongly believe we will see some major improvements in the performance of Web apps/Electron, since (a) there is a lot of incentive (b) there are many easy wins to be had in terms of performance.
andrekorol 6y ago
I can see this containerized future that you've envisioned solving a lot of the current performance problems of web apps.
- osrec 6y ago
  Wouldn't it be amazing?! You could even have the browser allocate a volume or two for the container to use (with the user's permission, of course) to store data locally. And users could be allowed to adjust how much space the volume may use (from some default minimum to unlimited). And with containers, the client should be reasonably safe even if executing malicious software.

scottmcdot 6y ago

I really don't like the lack of responsiveness that some Web apps have. I remember coming from Teradata SQL Assistant to Cloudera's Hue and being so frustrated by the latency of editing code (pushing the keyboard and seeing the letters appear). It would often result in me inserting random characters.

sanxiyn 6y ago

JavaScript is not slow. Python is slower than JavaScript, but if you compare a native desktop app written in PyGTK against an app written in Electron, you will see JavaScript being slow is not the problem.

pmlnr 6y ago
JS is not slow. Every effin JS framework is. If there was a real stdlib for JS it might work as an actual language.

pier25 6y ago

Electron apps aren't made because the end result is superior but because of budgets and schedules. Not even a company like Slack wants to get into the headache of maintaining a couple of native desktop apps, even if they probably have the money to do so.

pmlnr 6y ago
Slack is API calls. I have a hard time believing a few thin client interfaces - win, darwin, ios, android, gtk, qt - would be that hard with a company size of slack.
- MattGaiser 6y ago
  The question is not whether they are hard, but whether they are harder and whether that harder is worth it. Has Slack lost a single paying customer of this? I doubt it.
Qasaur 6y ago
I've never really understood this way of thinking. In my experience, it is trivial to maintain cross-platform applications if you encourage code-reuse in the logic layer and tailor the UI/UX experiences for the platform you are targeting. In practice this usually means writing the client business logic in a high-performant language that can target multiple platforms (I've only used Rust for this, but there are other languages out there that would work well with this approach as well), and using FFI when interacting with the UI layer. Combine this with good message passing practices (to homogenise serialisation/deserialisation and avoid the complexity of having hundreds of different FFI functions with various parameters) and you've got something that is easily integrated in platforms with little headache. I've seen great success with this approach for most platforms including mobile as it provides the end-user with a great user experience (you can use all the native UI APIs which provides an experience that the user is already familiar with) as well as extremely high performance with a high degree of code reuse.
- MattGaiser 6y ago
  But why bother even setting up different build environments for the different platforms? Even that part makes it already more work than Electron and I can't think of any meaningful business benefit to not using Electron.

muthdra 6y ago

It's always been. But the web stack is the most widely supported, low development effort target we know and even though it's bad, there's value in integrating and expanding it.

deleted 6y ago

[deleted]

giovannibonetti 6y ago

A good alternative that is coming to fruition is a modern alternative to Qt called libui [1]. Description from the project page: "Simple and portable (but not inflexible) GUI library in C that uses the native GUI technologies of each platform it supports." There are bindings for it in many languages, like Node.js, Rust, Swift, Kotlin and more. [1] https://github.com/andlabs/libui https://github.com/andlabs/libui

thethethethe 6y ago

Seems like the only argument here is: “web apps are slow and use a lot of resources” This isn’t a great argument by itself. There are many reasons that web apps are superior and more convenient than desktop apps. If this wasn’t the case, then why are web apps winning? I don’t want to download and execute a binary just to read my email, make a video call, or read the news. Web apps are also cross platform. You can pretty much guarantee that gmail will work the same on windows, Mac, Linux, Chrome OS, and even iOS and android (with some idiosyncrasies). Web apps also update themselves, they take up no space on your computer, and can be customized using browser plugins. I’d take these advantages over saving a few gigs of ram, which I have plenty of.

taeric 6y ago
Objectively, web apps seem to be winning as they let the companies keep control over application and data. With a bonus that they can monitor/track usage. That is, few, if any, technical advantages for users. Just fewer choices, as well.
pmlnr 6y ago
> that gmail will work the same on windows, Mac, Linux, Chrome OS, and even iOS and android Nope. This is the Java Virtual Machine promise all over again. It didn't work. It doesn't work the same in Safari or Firefox as it does in Chrome.
- thethethethe 6y ago
  Is chrome not consistent across operating systems?
  - pmlnr 6y ago
    Is it not. For example hardware acceleration is terrible under linux.
deergomoo 6y ago
> If this wasn’t the case, then why are web apps winning? Because that’s usually all that’s being provided? I don’t think it’s valid to say web apps are “winning” when in many cases they’re the only 1st party option. I don’t have any figures to back it up but I would not be surprised if the native app versions of Twitter, Facebook, Instagram etc. see far more use than their equivalent web app versions. > I’d take these advantages over saving a few gigs of ram, which I have plenty of. That’s all well and fine until everyone decides to make the same decision, and suddenly every application needs its own instance of Chromium to run.

underdeserver 6y ago

You actually can use sqlite, compiled with Emscripten, in a browser (storage is done via IndexedDB).

eludwig 6y ago

Gosh, I’m really sick of this argument. Sure, everyone loves hand-crafted, beautiful, native apps. But I will tell you this: it is possible to build a great app using any technology. It’s just a matter of taste & effort. My favorite tool that helps me get my day job done is VSCode. Do I care whether or not the damn thing is native or not? NO! Do I care that it gobbles some meager gigs? NO! Memory not being used is memory being wasted. Use my RAM, dammit. I can buy more. Use whatever you have to do to keep making this lovely thing that saves me so much time everyday and practically reads my mind as a JS developer! It has a elegant, raw beauty to it that totally fits my needs. If it uses some hybrid web technology stack, what do I care? Is it great? To me, yes! Make great apps. I don’t care how you do it.

blondin 6y ago
you have to understand one thing. if you have been using computers and applications that come with them for a while you have an intuitive sense how how big, how fast, and how much resources some of them should take. that's what is happening here. most people who are disagreeing with you know intuitively that it is not right, for a chat app -- going for an easy target here -- to grab all your available resources.

on_and_off 6y ago

> When apps are built for mobile, battery usage is a major area to optimize on. I worked on some heavy duty mobile apps like music streaming and unfortunately battery usage is the last thing we optimize for. The platform even provides us with some ways to measure it, but it is just so remote from the metrics we do optimize for that except for major problems, we don't focus on it in the slightest. >Mobile apps run at 60fps out of the box without much effort. Technically fps is not the best way to measure this (we tend to focus on dropped frames instead, unlike most video games engines; mobile will not recompose your UI if nothing moves, saving cycles and heat) Lots of efforts have actually been made to optimize mobile apps. We are starting to reach a point where we do have a top to bottom approach for reasonable performances (try to scroll any app insanely fast .. you will drop frames, but in regular usage; dropped frame are not too noticeable on recent top of the line phones). Agreed on the article though. Nothing more irritating than running a legitimately demanding application, seeing that it does not have enough resources and realize that a small web app in the background is using 37 cores and 50% of your cpu while you are not even using it (that was whatsapp just now).

k__ 6y ago

They are, just not in the ways most users care about. Sure, Ableton Live and Final Cut Pro are pretty rad, but how much percent of the population uses such tools? I even switched from Photoshop to Photopea and from Sketch to Gravit Designer, because they are good enough and much less hassle.

Bnshsysjab 6y ago

As someone who agrees that every electron app appears bloated, but wants a minimal fuss, feature rich, attractive, cross platform UI, what are my other options?

samwillis 6y ago
QT

andrefuchs 6y ago

There are pretty good Chrome Desktop PWAs like photopea.com (a free Photoshop alternative) I also like that PWA and Electron made more tools on Ubuntu available. Postman and Gravit Designer are great examples. Memory consumption and performance are problematic though for a lot of them - Electron apps especially.

redleggedfrog 6y ago

I'd take it even further. Browsers and things like Electron are just run-times. The browser's main advantage is cross-platform compatibility. But only kinda-sorta as any web developer can tell you. Your code is usually targeting 3 different run-times at a minimum and there are always problems with anything non-trivial. It is easy to imagine something much better, where your code runs on a nice tidy runtime native to the OS, with relatively easy layout tools and a language that is better than JavaScript (and really, what language isn't?). It'd be nice and fast, and rewarding to develop in. If we are starting anew, with fresh eyes, and we were handed browsers, with JavaScript, CSS, and the DOM, we'd be like, "This is complete BS. Visual VB for DOS has this beat." But because it grew organically, with instantly built in lock-in, and we're now thoroughly indoctrinated, the Stockholm Syndrome lives on. If you can just take 3 steps back it's fairly obvious. But people would rather just keep making the next React or Bootstrap and digging the hole deeper than make something better. Someday, make my words, there will be a cross-platform runtime that doesn't suck, that doesn't use JavaScript, and won't the stupid mistakes of the JRE, and developers will abandon web browsers as a platform in droves. I mean, can you really see this as the state of affairs in 2030? 2040? That'd just be sad. Edit: typo

arkanciscan 6y ago
> It is easy to imagine something much better, where your code runs on a nice tidy runtime native to the OS Yeah, cause that's how every native platform has been since the begining. Yet the web still needed to be invented. Why?
- Spivak 6y ago
  Because no two platforms can agree on anything so now we have "hosted platforms."
- thayne 6y ago
  The biggest reason is probably that you don't need the user to explicitly download and install your app. Also, a web app works on all the major OSes with a single GUI environment. And then of course the fact that webapps run in a more secure sandbox. A standard cross API and sandbox could potentially solve the second two. But I'm not sure how to solve the first outside of a browser.

deleted 6y ago

[deleted]

jwilliams 6y ago

This is an interesting debate, but I don’t think this is useful framing: “And it’s laughable how weak the browser platform itself is.” Which begs the question of why then do developers use web/electron? Ubuiqity, cross-platform, distribution, updates... and, yes, some developers also prefer web api. Perhaps the question is how do we bring a web/election experience to native apps?

sanxiyn 6y ago
I think Flutter is an attempt to answer that question. Whether it succeeds is not yet clear, but what is clear is that it is trying to answer the right question.

felixrieseberg 6y ago

Look, I get it, "less web apps" is an easy post to write these days, but all I ask is that we tone down the FUD. Let me just pick off the inaccuracies that will likely stick the most: > But building for the web(and electron) forces you to HTML/Javascript(and derivates). This is incorrect. Electron supports Objective-C, C++, Rust, and obviously WASM (amongst others). If you want to build native code (and native UI) in any of these languages, go for it. Countless Electron apps have native components. > It has no type safety, memory leaks are common and it’s slow due to its dynamic nature. TypeScript has been a thing for a while now. [Citation needed] for the statement that memory leaks are more common than in, say, C++. Slow: Yes, it's slower, but probably by _a lot_ less than you think[1]. > And it’s laughable how weak the browser platform itself is. SQLite is available on raspberry pi, embeddable systems, mobile platforms and just about every other platform on the planet. I agree, SQLite is fantastic. We don't really have to argue whether IndexDB will get thee job done, because native bindings to use SQLite with Electron exist. Just... use it. And lastly... > These days to send a text message over Slack I need over 1GB of RAM. [...] Even basic apps with all of their trackers, external javascript scripts and doms take up 100s of MBs in memory. We're always working on performance and we're quite far from the place I'd like us to be at, but it'll send your message just fine if you have less than one GB of memory installed in your whole machine. Even if you're a heavy user, your memory _should_ be below one GB. To be clear, I'll say it again: Yes, things should be better and we'll keep working on performance. The post mentioned Instagram earlier, which I'd say goes a bit beyond the most basic app, and it's using a humble 40MB on my machine. Disclaimer: I'm one of the maintainers of Electron and an engineer at Slack. I'm not here to argue opinions or which tool is better for which job, but we should get the basic facts right. [1]: https://www.youtube.com/watch?v=81CECdKCJNc https://www.youtube.com/watch?v=81CECdKCJNc

thayne 6y ago
> TypeScript has been a thing for a while now. Yes, and typescript is great. But you do need a rigorous approach with it to get type safety on parr with languages like java and c++. And since that type information is lost by the time it gets to the interpretor, it provide any benefit to performance. For example, the js interpretor has to check the types if operands at runtime to perform addition. JIT compilation helps a lot, but if the interpreted language had stronger typing, the JIT compilation could probably do an even better job, since it could make more assumptions.

Schnitz 6y ago

Native apps always win, except in the race to the bottom.

arkanciscan 6y ago
Always bet on JavaScript

dang 6y ago

When there's a major thread on a topic, like https://news.ycombinator.com/item?id=23211851 https://news.ycombinator.com/item?id=23211851 which is currently at #9, it's better to post follow-up links in the thread rather than as separate submissions. Otherwise the front page gets repetitive. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20follow-up&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... Also, please don't rewrite titles to make them more baity - this is in the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.

me551ah 6y ago
Author of the article here and the one who made this post. I did post this as a comment on the post you mentioned, but given that I'm already late I haven't seen any upvotes to it. So I decided to make a submission. Sorry about adding to the clutter. Sorry if the title now appears to be more baity, I was actually intending this to be a response to the Ask HN post on the front page. I figured it would be okay for post Authors to change the title since I can always change it in my original post. EDIT: I have changed the title of my original post.

arkanciscan 6y ago

> Trolly click bait titles get a lot of comments/replies Fixed your title!!

thegreatpeter 6y ago

Check out Revery UI: https://github.com/revery-ui/revery https://github.com/revery-ui/revery This is the replacement for Electron/Web. Built on top of ReasonML which offers a JavaScript like syntax (and supports your favorite libraries too) Revery UI can successfully target web, native desktop for Mac, windows & Linux with mobile coming soon. The case studies are great!

MattGaiser 6y ago

Very little matters for most pieces of software besides time to ship. If the average user isn’t technical/is forced to use it, there is no business reason to care about user battery life. There is no business reason to care about user cpu usage. Any reduction in user resource use would require greater business resource use (i.e one of their engineers needing to learn native). Are users willing to pay more for software that saves their battery life? Generally not, as most don’t even know why their battery is draining or their computer is slow. They just blame it on viruses, Windows, or general belief that their computer is getting old.

watersb 6y ago

I believe that Microsoft has tried to build a better Electron for at least the past ten years. The latest attempt is WindowsUI hosting React Native. I think. This past week, I have tried to walk through a "Hello World" for this pre-release platform, but I have failed to get a build system actually working. Its the "keep installing software until it works or until your system breaks, whichever comes first" problem. For now, I have chosen to preserve my ignorance of Visual Studio's build targets and project structure. I can only learn five new tools at a time.

vkhn 6y ago

This is such a silly article. Of course they are technologically superior. This is like saying bare metal is better than a virtual machine. Of course. But they are not universal for several reasons you fail to account for. I won't bother categorically defending anything in this article, but I will leave a single statement: good, fast, cheap - pick two.