One thing that makes me use a web-app rather than a native one on PC is that I know for a fact that the browser app will be very limited in tampering with my computer, something I'm not so sure about when installing native applications.
Often I see Nvidia's or Microsoft's or Discord's own services snooping in my installed applications, but it can go much further with, e.g., applications like grammarly that have access to my current buffer and clipboard virtually everywhere.
Another example, if I use Discord's web it has no real way of knowing what I'm doing on my PC, but when I used the desktop client, it showed and notified publicly half the world I was on Fortnite (even though, I was trying the Verse programming language in Fortnite's editor) which means that Discord tracks all of my activities on my computer.
Thus, honestly, I'd rather choose the web version of most applications 9 times out of 10, I simply have no clue what native applications know, do, and it's hard for me to debug what data they are sending and receiving, something that's quite transparent if I open the dev tools.
Absolutely. For anything internet-based (social media, chat, meetings etc.) web apps are vastly superior for this reason. In fact, anything which doesn't explicitly need the richness of a true desktop GUI (e.g. Photoshop or games) should probably be a web app.
In addition to the massive benefit of running browser-sandboxed, web apps are also:
1. Easier to start and stop (open/close a tab)
2. Less permanent (clear your browser's local storage and no data is left to stagnate on your hard drive)
3. Portable - no installation required
4. Cross-platform by nature of being a website
And you're totally right about companies pushing desktop apps because they're more invasive. It's outrageous that a desktop app can access virtually anything on your system in a totally opaque way.
Desktop computing needs a massive push towards finely-grained privacy/security controls in a similar way to how browsers work.
> Desktop computing needs a massive push towards finely-grained privacy/security controls in a similar way to how browsers work.
Sure. That’s iOS app sandboxing. And people perpetually complain about the inconvenience of having each application in its own file space and having to click a button (or, gasp, go to the files app) to make data appear in another sandbox.
If you can’t make the UX seamless, as in “the OS can read your mind and know which things to make available in the sandbox” then people will complain. And if you weaken that and start letting more through then you lose the benefits of sandboxing. It’s the same battle that seclinux has faced - secure configurations are often quite inconvenient.
> In fact, anything which doesn't explicitly need the richness of a true desktop GUI (e.g. Photoshop or games) should probably be a web app.
I'm going to throw a bit of shade at Photoshop... remember how up through CS3 they actually did have a native interface? From CS4 and beyond it turned into cross-platform web gunk.
Always disappointing to see. CS2 and CS3 felt so fluid on Mac OS X.
This misses that the browser sandbox doesn't include sandboxing internet access. I can't be sure that the application will never send what I enter into it out to the server that's hosting the app. Also any changes to the app's code are not obvious. I could be served different code each time I refresh the page, or it could be pulled in the background and evaled.
Even mobile apps have much more finely grained privacy and security controls and sandboxing. It feels like we should have multiple classes of browser apps - consumer apps (Discord, Slack, Spotify, Steam, etc) that are more mobile-like in their explicit permissions and dev tools that carry warnings for their largely unbounded behavior. Or perhaps even have “dev mode” on your machine that opens up access to system processes etc, that is both opt in and timeboxed (I.e. enable dev mode for 8 hours).
It’s also weird how I still go to, to me, random websites to download these apps (I trust Spotify.com, but having users google “Spotify” to find an app is ripe for supply chain attacking). The only time I ever visit some of these websites is to download their desktop app. In some sense, gaming has sort of figured this out as most everything comes through one of a handful of platforms nowadays (steam, gog, epic, etc).
I’m sure there are lots of solutions here but I think the current state definitely could be significantly improved.
Unless you want to touch USB (WebUSB sometimes work, sometimes don't) or Bluetooth - Good luck on iOS where Apple is not supporting BLE interface on purpose, but on Windows and Android situation is not much better. Even ChromeOS can't run Web Bluetooth properly. Supported on paper, does not work anyway.
> One thing that makes me use a web-app rather than a native one on PC is that I know for a fact that the browser app will be very limited in tampering with my computer, something I'm not so sure about when installing native applications.
I see this as more of a failing on the part of desktop OSes than anything. I know a lot of more technically inclined folks are used to the programs they run having access to all the same things they do and may even prefer that, but it’s been proven countless times over that large commercial devs will abuse this access however they can.
It’s because of this that I’m not nearly as upset by things like macOS app sandboxing as some seem to be. It’s nice to have the assurance that these apps can’t poke their noses anywhere that I haven’t explicitly allowed them to.
Unfortunately I don’t know when sandboxing will become the norm on the dominant desktop platform (Windows) where it’d make the most positive impact. Sandboxing breaks all sorts of dev assumptions and thus backwards compatibility, which is something of a sacred cow in the Windows world.
It's a failure of our security model still being based on room-sized machines from half a century ago. There, many users shared the same machine, so protecting them from each others' files was the main focus. But it was assumed that any program run by the user was fully trusted - either they were an expert programmer, or an office worker who had been given a prescribed set of trusted programs for their duties
Smartphones have been beneficial as they've shown an alternative model built essentially from a clean slate (their non-original kernels are of little relevance here), proving that a more fine-grained permissions model does work in the "real world" for most "ordinary person" use cases, though advanced users will likely always need to make use of escape hatches at times. And now we have technologies like Flatpak and distributions like Fedora Silverblue which are slowly but surely bringing it to desktop
Also for Windows I think the transition can be done. It doesn't need to be a big bang. Imagining something like Flatpak-style isolation, just introduce it as an enterprise feature, requiring explicit enabling by the admin for each program. These first users will therefore be sysadmins who know what they're doing more, and will also see the most benefit of it. Then roll it out for general users, perhaps allowing developers to add their own programs to a default-enable list (incentive to do so undetermined). Then eventually move to a fully opt-out model where you just disable it on problematic programs (and have another list of known ones). And also have a registry flag to globally disable it, for the peace of mind of skeptics
> I see this as more of a failing on the part of desktop OSes than anything.
I agree, and the reasons are ones that I think are also a failing:
- Sandboxing is used by OSs to take control back from users (whether that’s stopping them from building their own non-brand system or stopping them from ripping bit-perfect copies of copyright audio)
- Proper sandboxing is not implemented because it can be used to circumvent the anti-piracy measures that app developers use (specifically offline-friendly native apps). If all data can be wiped, so can the record of the trial expiration, for example.
- The commercial OS makers want a “no one can do it except us” policy and it’s been shown time and time again that any amount of “except us” becomes an attack vector.
- Clawing back permissiveness either requires a lot of expensive dev time or breaks older software (or both) and they don’t seem to be prioritizing users when going down that road.
And as much as iOS is becoming the standard for how to sandbox apps, did everyone know that iOS apps can communicate with each other (and persist data even after an uninstall) through Safari’s local storage/cookies?
I support the idea of using a web app over a native app to avoid tampering, but it’s a bit of a leap to say “Discord tracks all of my activity on my computer”.
Typically, that type of game notification is the game reporting it. Games want to have that Discord integration.
Frankly, I have more confidence that a web app will actually work, which is why I usually default to them if I can.
I can't tell you how many times I've installed an Android app by a big company and it was fundamentally broken in some way. This would happen even if I was using a non-rooted phone, though on my current rooted phone the problem is slightly worse when an app somehow detects that I'm rooted and prevents me from using it. Say what you want about the "clunkiness" of webpages, but I've used tons of native apps that aren't even using webviews that are extremely clunky and slow. The web loads plenty of unneeded crap, but native developers don't seem to give a f*** if their app bundles are half a gigabyte. Maybe it's because they all need to ship AI models now or whatever.
> There are just too many levels, and JavaScrip is an interpreted language, not a compiled one, so by default, it will be orders of magnitude slower than an app written in Swift, Rust, or C++.
JavaScript isn't as fast as C++ or Rust, but it's pretty fast. Around the speed of Java and Go in some cases, which are compiled.
For a web app the speed of the language is rarely the bottleneck anyway, other than some exceptional cases like WebGL-type stuff.
What's also not mentioned is that because JavaScript is single-threaded and garbage collected, classes of issues that you'd see in C++ are completely avoided (of course at the cost of absolute performance potential). I'd argue that TypeScript is probably the easiest language to grok, but I'm biased.
Anyway, Electron is its own circle of hell as it redundantly ships a ton of stuff and eats memory due to its own inefficiencies (though some of this is necessary sadly as letting you Bring Your Own Browser would create complexity of its own). I'm honestly surprised the Chromium team hasn't already addressed this with the Electron team somehow by now, given the popularity of the apps.
Though, I guess with newer apis such as the File System one Electron is slowly becoming unnecessary (but I doubt it'll ever go away because it's doubtful Chrome will include all of the APIs necessary).
The other issues mentioned in the article, such as UI could easily be addressed if Google and Apple cared to. They could release a CSS framework and style guide and people would quickly adhere to it. Google kind of did this with Material, but it doesn't go far enough, which is why you see 3rd parties picking up the slack.
> For a web app the speed of the language is rarely the bottleneck anyway
I think there’s some selection bias in this; the apps that get built as web apps tend to be the ones that are not bottlenecked by JavaScript. For exceptions that are pushing the limits of performance, you’ll more often than not find Rust/C++ compiled to Wasm in the stack.
We build a full game creation IDE and game engine which is entirely browser-based and almost entirely written in JavaScript (including all the performance-sensitive stuff), and the performance is ridiculously good[1]. You don't need WASM for good performance[2].
I've always wondered what kind of apps these are. The vast majority of web apps I use are all CRUD. I can't think of a single webapp or electron app I use which performs heavy computation. Maybe VSCode? But I don't know if any of the computation is happening on the frontend. People have been extolling the virtues of WASM to me for a while but I have yet to find a use for it where it improved the speed of development, since that's the only metric that matters to me working on CRUD apps
> JavaScript isn't as fast as C++ or Rust, but it's pretty fast. Around the speed of Java and Go in some cases, which are compiled.
Sorry, not even remotely close. I want to see some serious evidence.
JS id as unoptimizable as can be, thanks to its hyper dynamic nature. And js developers without any clue about memory will happily allocate hundreds of thousands of unnecessary objects to save a line of code. Completely unknowingly of course.
> Sorry, not even remotely close. I want to see some serious evidence.
There was this blog post of a company trying improve their clients' webpage performance by incrementally migrating them from JS to WASM/Rust: https://zaplib.com/docs/blog_post_mortem.html
In short, their idea failed. Those rewrites did not yield the "orders of magnitude" perf improvements that they were hoping for. A quote from the article:
> Rust is faster than JS in some cases, but those cases are rarer than we expected, and the performance gain is on the order of 2x some of the time, not 10x most of the time.
Having had a good deal of experience programming in JS, this doesn't surprise me. JS engines are extremely good at JIT optimizing, especially if you know what you're doing and give them code that's suitable for optimization (e.g. using mostly primitives and arrays, simple loops, avoid creating tons of intermediate data structures, etc).
IDK if any of this counts as "serious evidence". It's purely anecdotal really. But it's on par with the "evidence" presented as a counter to this.
Yes, it's a 30 year old game but the typical CRUD web app doesn't have close to the complexity of quake. Good C++ code is significantly faster than JS, that's true, but JS is also much, much faster than you'd think.
I did a double take when I read this too. However, I’d wager that in 99% of cases the bottleneck isn’t at the language level for most desktop apps or GUI apps in general.
I have an app that has one pretty frequent cpu intensive call (it computes the lcs for diffing). I decided to benchmark a rust wasm bindgen implementation against the js one I was using and found that ironically enough, node did perform better than rust. To be fair to the rust version, I think the JS implementation was slightly better optimized. I then looked into parallelizing LCS, (which is possible) but bindgen and almost all node:rust ports don’t support multithreaded calls, I can think of a myriad of ways to overcome this but not in a browser context. At that point I gave up on worrying about porting to lower level languages for cpu intensive work because if you’re forced into a single threaded context the gains of a memory managed language are going to be trivial at best and add ipc overhead at worse.
The main culprit of poor JS performance in native contexts is almost always bridges and the serialization/deserialization that comes with them. Electron apps don’t really suffer from the bridge problem. While, I’d never claim that JS is as fast as GO or Java (objectively it isn’t), it’s seems equally naive to suggest that using memory managed languages without exploiting multicore is going to lead to significant performance gains in a native app or web app.
I think the real power of wasm is the power of virtualization, it won’t be performance unless web APIs decide to break the single thread paradigm.
The key words here are: "around", which is to say same order of magnitude for performance, and "in some cases" which is to say for certain applications. I've already posted evidence for this claim specifically in sibling posts.
Also, why do you compare JS written by amateurs with Go/Java experts? There are JS experts too.
I once wrote an image generation program that used every color in a provided palette exactly once, then ported it to a few different languages. The main data structure was a kd-tree to store RGB points, with each point being marked as used after returning it.
Rust and C++ were both within about 10% of each other. Python was about 3 orders of magnitude slower. The surprising result was that JavaScript was only about 7-8x slower than the C++ version, which was much faster than I had expected.
The Javascript JIT arms race was the most heavily funded dynamic language arms race since forever - involving three major players (Apple, Google, Mozilla), dedicated teams, tons of benchmarks, constant tracking of performance improvements, total rewrites of the engines and additional JIT stages added, and public boasts in the official company blogs and marketing material!
That being said, the specific performance characteristics isn't really the point. Even if you accept JavaScript and Go being similarly fast (same order of magnitude), JavaScript uses way more memory (which I'd argue doesn't really matter, but it's worth mentioning) and the DOM is the main bottleneck in the browser, so WASM won't save you completely there.
"In some cases" seems reasonable to me. Google poured a lot of money into V8 performance for 15 years. There's also situations like AWS's Lambda environment where more time was spent getting node/JS optimized for the environment.
I think that one of JavaScript’s biggest problems is that on average, the quality of code written in it is somewhat low due to its lower barrier to entry, its relatively loose nature, and the less-engineering-inclined nature of many who write it enabled by that looseness. It doesn’t matter how fast your runtime is if it’s running crappy code.
That’s not to say that all code written in Rust or Swift is all AAA grade or anything, but to write those to the point of being able to publish a product that functions reasonably well, a deeper level of understanding is required which acts as something of a filter.
It would be interesting to see what would happen if all browsers added support for a sort of “JavaScript Next Gen” that were much more strict, sitting somewhere between TypeScript and Swift without the various escape hatches that TS currently has. My bet is that sites and web apps written with this would be on average of higher quality than their legacy JS counterparts.
> I guess with newer apis such as the File System one Electron is slowly becoming unnecessary
Last time I tried, it was still a pain point. For one, the API felt... alien. Also, the performance was not good. I'm not sure why, maybe it's my Javascript-FU that's bad, but all in all I'd still use another language for this if possible.
Sure it is - the vast majority of webapps are glorified CRUD. I'm not saying there are not high performance use cases. I'm saying if you list every app, most of them would be fine with exclusively JavaScript, and for the rest you have careful use of WASM or backend delegation to a faster language.
And to the author's point, something slow in JavaScript is better than nothing at all.
"and JavaScrip is an interpreted language, not a compiled one, so by default, it will be orders of magnitude slower than an app written in Swift, Rust, or C++."
This statement is misleading and false.
The distinction between "interpreted" and "compiled" isn't as clear-cut as it once was, especially in the context of modern languages and runtimes. However, when it comes to JavaScript, here's the general understanding:
-Interpreted: JavaScript is traditionally known as an interpreted language. This means that it is typically executed line by line, on-the-fly, without a preliminary compilation step to machine code. When web browsers first supported JavaScript, they essentially had interpreters that read and executed JavaScript code directly.
- Just-In-Time Compilation (JIT): Modern JavaScript engines like V8 (used in Chrome and Node.js), SpiderMonkey (used in Firefox), and Chakra (used in older versions of Microsoft Edge) use Just-In-Time (JIT) compilation to execute JavaScript code. With JIT, the JavaScript code is compiled into machine code just before it is executed, rather than being interpreted line by line. This approach can greatly improve performance because the machine code can be optimized for the current machine and can be executed much faster than interpreted code. So, in this sense, JavaScript is compiled at runtime.
- Ahead-of-Time Compilation (AOT): There are also tools and technologies that allow you to compile JavaScript (or languages that transpile to JavaScript) "ahead of time" into machine code or other languages. Examples include the asm.js subset of JavaScript and WebAssembly (although WebAssembly isn't strictly JavaScript, it's a target for languages including C/C++ and Rust, among others).
Yes, Javascript is used in browsers and has a few different competing runtimes, and as such, there are a lot of resources invested in making it faster than the other runtimes.
As a result, except in only very trivial cases, Javascript is only slower than C++ by about a factor of 2-4. This is a much smaller difference than the "orders of magnitude" mentioned above.
The only exception is "hello world", which is about one order of magnitude slower in JS, but that's probably explained by the runtime startup / teardown.
Those are microbenchmarks, and as such are misleading when it comes to evaluating JIT-ed languages. They also don’t involve ever touching the DOM, which is a major source of slowdowns in real-world JS apps.
JITting alone will just make code slower. Even with many optimizations V8 eventually changed the "unoptimizing JIT" to an interpreter and now only JITs hot functions.
Seems like a technicality to me, although I'd be happy to update the statement in the post.
It's still not compiled in advance and while the technologies you described (asm.js, WebAssemly) exists most web apps discussed don't use them at all.
Compiled JIT can be pretty similar to AOT, if the application runs for any real period of time. Generally, a JIT will try to compile any given block of code only once; so it winds up working towards the same state as something AOT.
That being said, there is a caveat that the code _can_ change for something compiled JIT, and there are inefficiencies related to that.
There are benchmarks/cases were JS is faster then C++
Yes obliviously C++ is faster then JS, but complexity/time of programmer may cause you to write slower code then v8/JIT.
I can't sadly find a link for that benchmark
I hate to agree with this. Web is the best way to cram loads of features into a limited amount of dev time.
But still, whenever I use Teams, something like this happens: I click a button, nothing happens. I wait 10 seconds, because teams sometimes just needs a little longer. Nothing happens. I click the button again, it finally starts doing something. 5 seconds later, the thing I wanted appears.
Teams has to be the poster child of “enterprise software”. I’m currently on contract at a large healthcare company and I’m starting to understand how an app as abominable as Teams could be built.
The issue isn’t really with the tech stack, though electron is not the best, other companies like Discord have managed to build much better apps on top of it. The issue I see is organizational.
What happens is you have a top down product vision where the features all come from the top and the engineers just have to figure out the implementation, they have no say in which features get pushed.
So you get a scenario where every quarter, there are ever more features you need to cram into the app. All of this is feature work, no rework, no performance fixes. Once a team is done with this feature they don’t have time to go back and fix the tech debt because they have a new feature to implement. For any bug fixes and performance fixes the feature is shipped to another (probably offshore) team for maintenance, another quarter passes and more stuff gets thrown in to the app, a never ending cycle.
It’s a vicious cycle where the app seems to be feature filled but every feature feels half baked with no attention paid to the details. Features are only added to and seldomly removed.
Contrast this to smaller shops like Discord. I would imagine they follow a similar process but you have the same teams managing the building and maintenance of feature and more importantly, it’s not just adding new features but going back and reworking things to be more performant.
In my mind these apps are actually ugly organizational problems that rear their head in the technology that the org creates.
> other companies like Discord have managed to build much better apps on top of it
Not to mention Microsoft themselves! VS Code is probably the shining example of what performance you can get out of Electron - with the caveat that it did take more engineering effort than I'd expect out of a chat app, and it's still more resource hungry than equivalent native editors/IDEs
This is what happens when there is no competition. If microsoft wasn't able to force their way into companies by bundling teams with all the other office crap that non-technical people want, I doubt anyone would seriously pick it over anything else. The amount of issues it has (and therefore the amount of work it causes) is insane. I have yet to see a streak of 5 calls without issues that require an interruption to fix.
I keep hitting the RAM ceiling on my 16GB dev machine with the amount of electron crap I have to have open just to send messages to colleagues. Maybe it isn't noticeable when your app is the only one developed on your machine, but on a typical user machine these days the RAM guzzling is real.
We could have it better, we had it better and I hate this.
I remember using Adium on my iMac G5 with 2GB of RAM, with its ability to connect to numerous networks, tons of features, and deep customizability of every aspect of the program with themes, icons, sound sets, etc and it only ever took up a small portion of that 2GB, even though its message view was implemented with a webview.
You can program junk in any language. I've built a pretty neat real time web application using nothing but JavaScript and a little thinking. Could it be better? Yes, no doubt. I could have written it as a native application for all of the platforms that it currently supports (Desktop on Windows, Mac, Linux, mobile phones Android and iPhone). But I really don't have the time or the resources for that so this helped me to scratch my itch, helps a ton of other people as well and keeps the future options open. If you can do it as a web app you probably should do just that.
I've a bunch of ideas on how to improve it that would require much more speed for raw computation, so for now that's off the table. Maybe one day it'll catch up, maybe there are some performance tricks that I'm simply not aware of that could make it happen today. But it's plenty useful as it is.
Teams is typical bloatware. We had video-in-the-browser in 1995 and it worked, by 1998 we had audio as well plus a whole pile of people hanging off high volume events (Shuttle launches, F1 etc). Since then computers have become considerably faster. That there are alternatives to Teams that do not suffer from the same drawbacks makes me think that this is implementation dependent and that MS would really love you to download their native stuff. The web based Teams clients doesn't seem like it was ever priority #1. And because in any Teams meeting with more than five participants there always is at least one person using the web the impression is that the system as a whole just doesn't work.
The web version of teams works much better than the "native" one. Pressing F5 when it stops working is much faster than restarting an entire browser.
But then microsoft just decides to kick its users in the balls again by adding a feature that allows outgoing calls only on chrome and edge while blocking firefox. Meetings work, so that's obviously bullshit.
I guess electron isn't what makes teams terrible, but rather microsoft.
> And because in any Teams meeting with more than five participants there always is at least one person using the web the impression is that the system as a whole just doesn't work.
That's me. Like with Slack, both native and web versions are junk, but the web version is leaner and snappier. And no, generally me using the web version didn't cause any issues to anyone on corporate calls.
NetMeeting managed live conferencing over 56k lines and on Pentium IIs. A tragically underappreciated piece of software, Skype before Skype with directories and the lot.
It's funny that Teams web app works flawlessly for me in Edge browser, but I can't get the native client to even start properly. I can't say whether the web client is a parity match for the native client, but it suits my needs, so I just always use it instead.
This definitely happens. At the same time, Superhuman (which is a web app) is insanely fast, and Apple managed to make the desktop version of Apple Music (which is supposed to be mostly native) insanely slow.
Sadly, Microsoft and Electron seem to be magnetic to that type of software though. I experience seconds of lag between pressing a key and a character appearing in vanilla VSCode writing plain-text files. Forget plugins, I can't even use it to write text files. This laptop seems to run Dwarf Fortress and Factorio just fine, so I have no clue why specifically Teams and VSCode conk out other than the fact that both are Microsoft products built for the web and shipped with a security-lax stripped web browser. Have no issues with full Visual Studio either, so it's just that VSCode runs much, much, much heavier than actual Visual Studio. Isn't it meant to be light-weight in comparison?
Did this 'article' make anyone else's antenna twitch?
Firstly, there's something about the combination of saying nothing new and adding very little opinion, plus a few writing/editorial oddities, makes me wonder if this is GPT-generated? Or at best, it's just comms copy from a non-specialist, banging something out in a hurry. (Noting that the author is COO of a 'communication agency'.)
Secondly, given how uninteresting the article to (at least, to a typical HN reader, IMO) why has it popped up onto the front page?
I'm genuinely interested what's going on here - just an anomaly, or HN gaming, or a sign of things to come?
This is an extremely typical HN article. It's blogspam. The author makes a half-hearted attempt to explain some minor thought they just had and then hopes it gets traction so they can later monetize it. Pump out enough of them and at some point it'll make it to the front page where you can get subscribers. HN upvotes any clickbait headline because strong opinions get traction.
It's typical HN fodder. It's low quality, but some don't upvote the article, they upvote the headline.
It's been 3 hours on one of the slower hours on HN. The algorithm is loosely engagement / time^2, so something that pops up at the right timing can stand out against really good news 14 hours ago.
But typically the high comment vs upvote ratio triggers the low quality filter and it's likely to fall off soon.
GPT-generated articles are extremely common now. It doesn't surprise me one bit. It's just a cheap way for the "author" to build his online presence with minimum effort.
If it's GPT4, it would fool me.
It IS bland in tone and quality, but to me it looks like human-generated for voicing over some clickbait Youtube video.
>Why deceptively package the javascript as an app when you can just put it on a website?
A desktop app based on Electron-Chromium runtime has more integration options with the operating system. E.g. file system access, taskbar/Dock icon and notifications, runs in the background, etc.
If a developer were to create a 100% pure web url app running locally on https://127.0.0.1/foobarapp.html -- ... they'd quickly run into browser's limitations. For example, the sandboxed security model won't let the Javascript inside of foobarapp.html iterate all files of the local file system. And Mozilla's new filesystem api isn't really available yet: https://caniuse.com/native-filesystem-api
Not sure if there's any "deception" here. Developers just want to write desktop apps leveraging their existing Javascript knowledge instead of learning C++/C#/Swift for each platform and trying to manage feature parity in separate code bases.
That's great, but I don't know any Electron app that needs file system or task bar access. Notifications are a solved problem already and installing web apps from the browser is just a click away in all browsers (except Firefox), after which they run completely offline.
Chrome added a file system API for some reason, but every Electron based application I've used just used the standard <input type=file> prompt and it worked absolutely fine. Even things like live screen recording and P2P VoIP can be done from the browser now.
I'm sure there are plenty of applications that need Electron, but I'm having a hard time coming up with any.
> If a developer were to create a 100% pure web url app running locally on https://127.0.0.1/foobarapp.html -- ... they'd quickly run into browser's limitations. For example, the sandboxed security model won't let the Javascript inside of foobarapp.html iterate all files of the local file system.
If a developer has the app run locally on 127.0.0.1, they already have the capability to enumerate files (without the Web browser's cooperation).
Electron has always had capabilities that websites don't have. VS Code, e.g., has shell integration, uses file watchers, lets you connect to remote servers or your container runtime, interacts with other installed programs, etc. I don't want to miss these features, which is why I don't want to use the web version.
I would explain it in a way that electron has API and access to stuff that a browser should not/does not/never will have.
Browser should be much more sand boxed and never have access to the file system with privileges of a user running browser.
Yes, someone can install malicious electron app but that is totally different than randomly stumbling upon malicious website while browsing/clicking around.
There're few benefits that comes with packaging it into an electron wrapper, including:
- making sure it works on all platforms independently of the browser you use (because it comes packages with chromium)
- having access to more API from the platform. Although the UI is rendered through a WebView, there's still native code running, that you can hook back into your app. That can be useful to either offload some logic to native, or access native API that you pilot from the WebApps
- having a shortcut icon to open you app in the system (although this is getting obsolete now that Chrome and Safari offer "Add to Desktop" functionally)
Just took a look, because 400MB seems low for Slack. It is in fact almost 1GB of memory across six processes, while providing a terrible and non native UI.
Google Chat has a similar issue in that it uses a lot of memory for what it does and has a shitty UI, except it's actually a PWA.
I do get the cross platform benefit, but how many developers do you actually need to build an awesome native application, when much of the interaction is done on the backend anyway? Slack does seem a little complicated, but I have the feeling that you could do Google Chat with perhaps five developers per platform.
the website mechanism has so many flaws, an abitrary code size restriction for once, constant access to the internet for another. And you can't really tell if the code you run today is the same as that yesterday.
> Why deceptively package the javascript as an app when you can just put it on a website?
Because they appear separately on the user’s task switcher. Honestly there’s not a lot more to it than that. And users do appreciate being able to switch to e.g. Slack specifically rather than switch to their browser then find the Slack tab.
You can do all of this with progressive web apps too these days, but every time they come up in HN people crap on them, so… shrug
Not a fan of Electron or native-ified apps in general but I usually have a very easy decision matrix:
If it's one of my main productivity drivers (IDE, Browser, E-Mail, Messenger, Note-taking app, whatever) it can be massive and I am willing to update it constantly.
If it's a tiny tool that sometimes offers one functionality and otherwise sits in the tray: No, I don't want it to gobble up 200MB of RAM if you can quite literally draw the window and the 5 checkboxes and 3 buttons with 30 lines of WINAPI code. I might have 10 of these running, a browser-based UI does not make sense for this, yet people keep doing it. Electron is good at UIs, if I only open the UI once per month (but the app is running 24/7) it should optimize for resource usage, not developer happiness.
Some things are in between, even for me. Music player: I prefer foobar2000 or the likes, no images, just a list of songs I can doubleclick. Not a web app. A text editor that does not render mark down, is not an IDE, etc.pp. Not a web app. But for some people these can be really feature rich, not for me.
Generally agree. Tiny utilities should be, well, tiny.
Will add that where possible, I’ll use the PWA version instead of the Electron version now that Safari on macOS can install PWAs that launch independently from the browser itself (unlike Chrome and its numerous cousins which require the full browser to be open). This sidesteps some of the native access concerns that come with Electron versions and is easier on the battery than the Electron version or a Chrome tab.
I don't get what's all the hate around Electron apps to be honest.
I run VS Code, Slack, Discord, Spotify (not Electron, but web tech) all the time and I don't see problems[1]. I mainly use a 7 year old mac, nothing too beefy.
No, I wouldn't like to use a website instead. But I don't crave an actual native app that much either.
[1] Perhaps apart from Discord always updating itself, but that's their decision.
The only example you provided that doesn't strictly need network based functionality for its core purpose is VS Code.
Slack, Discord and Spotify are all "web-based" to their core in the sense that they have an in-built client/server model as part of their core design and purpose. So in those examples, the only thing we have to complain about is the rendering / presentation layer.
And that kind of shifts the goalpost if you focus on those types of apps in my opinion.
Because my dislike for web apps is not strictly that they are using a browser-based presentation engine. If those UIs felt sluggish to me then I might choose to blame the underlying tech, but I wouldn't question it as much if they were not network-enabled applications in the first place (unless UI performance was a real pain and I thought they could perform better using something native).
The real issue for me is that our industry likes to chase trends like they are all or nothing. I don't like that every single application is moving to a web-based model whether or not it makes sense for that app. For the majority of my personal use, I don't need my applications to be network-enabled in the first place. I don't want them to sync to cloud storage, or provide collaboration features. I don't want to have to have an "account" with some SaaS company to use a word processor or a photo manipulation program.
I want my data local. I don't want my usage and data tracked. I don't want the app to stop working if my ISP has an outage and I don't want my data and app to disappear if the company goes out of business. I also don't like that web apps tend to see a much higher rate of UI changes pushed to the user. Software versions have largely disappeared for end-users and marketing. Now it's a continuous stream of pushed changes whether you chose to "upgrade" or not.
Slack has to be the clunkiest, slowest app I have ever used. It makes visual studio seem fast.
Electron apps are the hill I want to die on.
It is against hacker ethos, incredibly slow and bloated, and teaches devs features are the only thing which matters and not how much memory or cpu runtime it uses.
Readit News
Often I see Nvidia's or Microsoft's or Discord's own services snooping in my installed applications, but it can go much further with, e.g., applications like grammarly that have access to my current buffer and clipboard virtually everywhere.
Another example, if I use Discord's web it has no real way of knowing what I'm doing on my PC, but when I used the desktop client, it showed and notified publicly half the world I was on Fortnite (even though, I was trying the Verse programming language in Fortnite's editor) which means that Discord tracks all of my activities on my computer.
Thus, honestly, I'd rather choose the web version of most applications 9 times out of 10, I simply have no clue what native applications know, do, and it's hard for me to debug what data they are sending and receiving, something that's quite transparent if I open the dev tools.
In addition to the massive benefit of running browser-sandboxed, web apps are also:
1. Easier to start and stop (open/close a tab)
2. Less permanent (clear your browser's local storage and no data is left to stagnate on your hard drive)
3. Portable - no installation required
4. Cross-platform by nature of being a website
And you're totally right about companies pushing desktop apps because they're more invasive. It's outrageous that a desktop app can access virtually anything on your system in a totally opaque way.
Desktop computing needs a massive push towards finely-grained privacy/security controls in a similar way to how browsers work.
Sure. That’s iOS app sandboxing. And people perpetually complain about the inconvenience of having each application in its own file space and having to click a button (or, gasp, go to the files app) to make data appear in another sandbox.
If you can’t make the UX seamless, as in “the OS can read your mind and know which things to make available in the sandbox” then people will complain. And if you weaken that and start letting more through then you lose the benefits of sandboxing. It’s the same battle that seclinux has faced - secure configurations are often quite inconvenient.
I'm going to throw a bit of shade at Photoshop... remember how up through CS3 they actually did have a native interface? From CS4 and beyond it turned into cross-platform web gunk.
Always disappointing to see. CS2 and CS3 felt so fluid on Mac OS X.
It’s also weird how I still go to, to me, random websites to download these apps (I trust Spotify.com, but having users google “Spotify” to find an app is ripe for supply chain attacking). The only time I ever visit some of these websites is to download their desktop app. In some sense, gaming has sort of figured this out as most everything comes through one of a handful of platforms nowadays (steam, gog, epic, etc).
I’m sure there are lots of solutions here but I think the current state definitely could be significantly improved.
I see this as more of a failing on the part of desktop OSes than anything. I know a lot of more technically inclined folks are used to the programs they run having access to all the same things they do and may even prefer that, but it’s been proven countless times over that large commercial devs will abuse this access however they can.
It’s because of this that I’m not nearly as upset by things like macOS app sandboxing as some seem to be. It’s nice to have the assurance that these apps can’t poke their noses anywhere that I haven’t explicitly allowed them to.
Unfortunately I don’t know when sandboxing will become the norm on the dominant desktop platform (Windows) where it’d make the most positive impact. Sandboxing breaks all sorts of dev assumptions and thus backwards compatibility, which is something of a sacred cow in the Windows world.
Smartphones have been beneficial as they've shown an alternative model built essentially from a clean slate (their non-original kernels are of little relevance here), proving that a more fine-grained permissions model does work in the "real world" for most "ordinary person" use cases, though advanced users will likely always need to make use of escape hatches at times. And now we have technologies like Flatpak and distributions like Fedora Silverblue which are slowly but surely bringing it to desktop
Also for Windows I think the transition can be done. It doesn't need to be a big bang. Imagining something like Flatpak-style isolation, just introduce it as an enterprise feature, requiring explicit enabling by the admin for each program. These first users will therefore be sysadmins who know what they're doing more, and will also see the most benefit of it. Then roll it out for general users, perhaps allowing developers to add their own programs to a default-enable list (incentive to do so undetermined). Then eventually move to a fully opt-out model where you just disable it on problematic programs (and have another list of known ones). And also have a registry flag to globally disable it, for the peace of mind of skeptics
I agree, and the reasons are ones that I think are also a failing:
- Sandboxing is used by OSs to take control back from users (whether that’s stopping them from building their own non-brand system or stopping them from ripping bit-perfect copies of copyright audio)
- Proper sandboxing is not implemented because it can be used to circumvent the anti-piracy measures that app developers use (specifically offline-friendly native apps). If all data can be wiped, so can the record of the trial expiration, for example.
- The commercial OS makers want a “no one can do it except us” policy and it’s been shown time and time again that any amount of “except us” becomes an attack vector.
- Clawing back permissiveness either requires a lot of expensive dev time or breaks older software (or both) and they don’t seem to be prioritizing users when going down that road.
And as much as iOS is becoming the standard for how to sandbox apps, did everyone know that iOS apps can communicate with each other (and persist data even after an uninstall) through Safari’s local storage/cookies?
Typically, that type of game notification is the game reporting it. Games want to have that Discord integration.
I can't tell you how many times I've installed an Android app by a big company and it was fundamentally broken in some way. This would happen even if I was using a non-rooted phone, though on my current rooted phone the problem is slightly worse when an app somehow detects that I'm rooted and prevents me from using it. Say what you want about the "clunkiness" of webpages, but I've used tons of native apps that aren't even using webviews that are extremely clunky and slow. The web loads plenty of unneeded crap, but native developers don't seem to give a f*** if their app bundles are half a gigabyte. Maybe it's because they all need to ship AI models now or whatever.
JavaScript isn't as fast as C++ or Rust, but it's pretty fast. Around the speed of Java and Go in some cases, which are compiled.
For a web app the speed of the language is rarely the bottleneck anyway, other than some exceptional cases like WebGL-type stuff.
What's also not mentioned is that because JavaScript is single-threaded and garbage collected, classes of issues that you'd see in C++ are completely avoided (of course at the cost of absolute performance potential). I'd argue that TypeScript is probably the easiest language to grok, but I'm biased.
Anyway, Electron is its own circle of hell as it redundantly ships a ton of stuff and eats memory due to its own inefficiencies (though some of this is necessary sadly as letting you Bring Your Own Browser would create complexity of its own). I'm honestly surprised the Chromium team hasn't already addressed this with the Electron team somehow by now, given the popularity of the apps.
Though, I guess with newer apis such as the File System one Electron is slowly becoming unnecessary (but I doubt it'll ever go away because it's doubtful Chrome will include all of the APIs necessary).
The other issues mentioned in the article, such as UI could easily be addressed if Google and Apple cared to. They could release a CSS framework and style guide and people would quickly adhere to it. Google kind of did this with Material, but it doesn't go far enough, which is why you see 3rd parties picking up the slack.
I think there’s some selection bias in this; the apps that get built as web apps tend to be the ones that are not bottlenecked by JavaScript. For exceptions that are pushing the limits of performance, you’ll more often than not find Rust/C++ compiled to Wasm in the stack.
[1] https://www.construct.net/en/blogs/construct-official-blog-1...
[2] https://surma.dev/things/js-to-asc/
Sorry, not even remotely close. I want to see some serious evidence.
JS id as unoptimizable as can be, thanks to its hyper dynamic nature. And js developers without any clue about memory will happily allocate hundreds of thousands of unnecessary objects to save a line of code. Completely unknowingly of course.
Funny that you say "not even remotely close" while providing zero evidence yourself, but then ask other people to present their evidence.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
There you go. There's the evidence. No goalpost-moving, please.
For evidence that Javascript can be used to build large, production-quality applications, see coldtea's comment: https://news.ycombinator.com/item?id=37568707
And yet it has been optimized.
> Sorry, not even remotely close. I want to see some serious evidence.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
JS is ~30% slower than Java or Go.
Go is a lot closer to JS perf than to C++ perf.
---
For real-world applications....compare IntelliJ, Eclipse, Visual Studio, or Sublime against VSCode.
There was this blog post of a company trying improve their clients' webpage performance by incrementally migrating them from JS to WASM/Rust: https://zaplib.com/docs/blog_post_mortem.html
In short, their idea failed. Those rewrites did not yield the "orders of magnitude" perf improvements that they were hoping for. A quote from the article:
> Rust is faster than JS in some cases, but those cases are rarer than we expected, and the performance gain is on the order of 2x some of the time, not 10x most of the time.
Having had a good deal of experience programming in JS, this doesn't surprise me. JS engines are extremely good at JIT optimizing, especially if you know what you're doing and give them code that's suitable for optimization (e.g. using mostly primitives and arrays, simple loops, avoid creating tons of intermediate data structures, etc).
IDK if any of this counts as "serious evidence". It's purely anecdotal really. But it's on par with the "evidence" presented as a counter to this.
Yes, it's a 30 year old game but the typical CRUD web app doesn't have close to the complexity of quake. Good C++ code is significantly faster than JS, that's true, but JS is also much, much faster than you'd think.
I have an app that has one pretty frequent cpu intensive call (it computes the lcs for diffing). I decided to benchmark a rust wasm bindgen implementation against the js one I was using and found that ironically enough, node did perform better than rust. To be fair to the rust version, I think the JS implementation was slightly better optimized. I then looked into parallelizing LCS, (which is possible) but bindgen and almost all node:rust ports don’t support multithreaded calls, I can think of a myriad of ways to overcome this but not in a browser context. At that point I gave up on worrying about porting to lower level languages for cpu intensive work because if you’re forced into a single threaded context the gains of a memory managed language are going to be trivial at best and add ipc overhead at worse.
The main culprit of poor JS performance in native contexts is almost always bridges and the serialization/deserialization that comes with them. Electron apps don’t really suffer from the bridge problem. While, I’d never claim that JS is as fast as GO or Java (objectively it isn’t), it’s seems equally naive to suggest that using memory managed languages without exploiting multicore is going to lead to significant performance gains in a native app or web app.
I think the real power of wasm is the power of virtualization, it won’t be performance unless web APIs decide to break the single thread paradigm.
Also, why do you compare JS written by amateurs with Go/Java experts? There are JS experts too.
Rust and C++ were both within about 10% of each other. Python was about 3 orders of magnitude slower. The surprising result was that JavaScript was only about 7-8x slower than the C++ version, which was much faster than I had expected.
That is quite the claim, I wonder if you have any data to back that up. As it goes against everything I've seen.
The Javascript JIT arms race was the most heavily funded dynamic language arms race since forever - involving three major players (Apple, Google, Mozilla), dedicated teams, tons of benchmarks, constant tracking of performance improvements, total rewrites of the engines and additional JIT stages added, and public boasts in the official company blogs and marketing material!
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
There are others as well like:
https://programming-language-benchmarks.vercel.app/go-vs-jav...
That being said, the specific performance characteristics isn't really the point. Even if you accept JavaScript and Go being similarly fast (same order of magnitude), JavaScript uses way more memory (which I'd argue doesn't really matter, but it's worth mentioning) and the DOM is the main bottleneck in the browser, so WASM won't save you completely there.
Well, a solution might be to share the chromium "vm" across all electron app, but maintaining compatibility will be horribly difficult so, no I guess.
Teams 2 is supposed to use it (and there's a couple smaller system apps that use it).
That’s not to say that all code written in Rust or Swift is all AAA grade or anything, but to write those to the point of being able to publish a product that functions reasonably well, a deeper level of understanding is required which acts as something of a filter.
It would be interesting to see what would happen if all browsers added support for a sort of “JavaScript Next Gen” that were much more strict, sitting somewhere between TypeScript and Swift without the various escape hatches that TS currently has. My bet is that sites and web apps written with this would be on average of higher quality than their legacy JS counterparts.
Indeed, JS is pretty darn fast.
Not because of innate characteristics, but because of the human-centuries spent optimizing JIT VMs.
Deleted Comment
Last time I tried, it was still a pain point. For one, the API felt... alien. Also, the performance was not good. I'm not sure why, maybe it's my Javascript-FU that's bad, but all in all I'd still use another language for this if possible.
Their primary reasoning for picking V8 for Edge was that node, electron etc were built on V8.
We haven’t seen anything specific to those environments in Windows yet. I expect that to probably change pretty soon.
If we're talking about a glorified form/CRUD app, no.
For web apps proper, that's not really the case.
And to the author's point, something slow in JavaScript is better than nothing at all.
This statement is misleading and false.
The distinction between "interpreted" and "compiled" isn't as clear-cut as it once was, especially in the context of modern languages and runtimes. However, when it comes to JavaScript, here's the general understanding:
-Interpreted: JavaScript is traditionally known as an interpreted language. This means that it is typically executed line by line, on-the-fly, without a preliminary compilation step to machine code. When web browsers first supported JavaScript, they essentially had interpreters that read and executed JavaScript code directly.
- Just-In-Time Compilation (JIT): Modern JavaScript engines like V8 (used in Chrome and Node.js), SpiderMonkey (used in Firefox), and Chakra (used in older versions of Microsoft Edge) use Just-In-Time (JIT) compilation to execute JavaScript code. With JIT, the JavaScript code is compiled into machine code just before it is executed, rather than being interpreted line by line. This approach can greatly improve performance because the machine code can be optimized for the current machine and can be executed much faster than interpreted code. So, in this sense, JavaScript is compiled at runtime. - Ahead-of-Time Compilation (AOT): There are also tools and technologies that allow you to compile JavaScript (or languages that transpile to JavaScript) "ahead of time" into machine code or other languages. Examples include the asm.js subset of JavaScript and WebAssembly (although WebAssembly isn't strictly JavaScript, it's a target for languages including C/C++ and Rust, among others).
As a result, except in only very trivial cases, Javascript is only slower than C++ by about a factor of 2-4. This is a much smaller difference than the "orders of magnitude" mentioned above.
The following list of benchmarks illustrates this point: https://programming-language-benchmarks.vercel.app/javascrip...
The only exception is "hello world", which is about one order of magnitude slower in JS, but that's probably explained by the runtime startup / teardown.
Most web apps are slow because the DOM is slow.
Most web apps use it for what it wasn't meant to do, in an inefficient matter, with useless rerenders and overhead.
That being said, there is a caveat that the code _can_ change for something compiled JIT, and there are inefficiencies related to that.
But still, whenever I use Teams, something like this happens: I click a button, nothing happens. I wait 10 seconds, because teams sometimes just needs a little longer. Nothing happens. I click the button again, it finally starts doing something. 5 seconds later, the thing I wanted appears.
And every time it happens, I die a little inside.
The issue isn’t really with the tech stack, though electron is not the best, other companies like Discord have managed to build much better apps on top of it. The issue I see is organizational.
What happens is you have a top down product vision where the features all come from the top and the engineers just have to figure out the implementation, they have no say in which features get pushed.
So you get a scenario where every quarter, there are ever more features you need to cram into the app. All of this is feature work, no rework, no performance fixes. Once a team is done with this feature they don’t have time to go back and fix the tech debt because they have a new feature to implement. For any bug fixes and performance fixes the feature is shipped to another (probably offshore) team for maintenance, another quarter passes and more stuff gets thrown in to the app, a never ending cycle.
It’s a vicious cycle where the app seems to be feature filled but every feature feels half baked with no attention paid to the details. Features are only added to and seldomly removed.
Contrast this to smaller shops like Discord. I would imagine they follow a similar process but you have the same teams managing the building and maintenance of feature and more importantly, it’s not just adding new features but going back and reworking things to be more performant.
In my mind these apps are actually ugly organizational problems that rear their head in the technology that the org creates.
Not to mention Microsoft themselves! VS Code is probably the shining example of what performance you can get out of Electron - with the caveat that it did take more engineering effort than I'd expect out of a chat app, and it's still more resource hungry than equivalent native editors/IDEs
I keep hitting the RAM ceiling on my 16GB dev machine with the amount of electron crap I have to have open just to send messages to colleagues. Maybe it isn't noticeable when your app is the only one developed on your machine, but on a typical user machine these days the RAM guzzling is real.
We could have it better, we had it better and I hate this.
I've a bunch of ideas on how to improve it that would require much more speed for raw computation, so for now that's off the table. Maybe one day it'll catch up, maybe there are some performance tricks that I'm simply not aware of that could make it happen today. But it's plenty useful as it is.
Teams is typical bloatware. We had video-in-the-browser in 1995 and it worked, by 1998 we had audio as well plus a whole pile of people hanging off high volume events (Shuttle launches, F1 etc). Since then computers have become considerably faster. That there are alternatives to Teams that do not suffer from the same drawbacks makes me think that this is implementation dependent and that MS would really love you to download their native stuff. The web based Teams clients doesn't seem like it was ever priority #1. And because in any Teams meeting with more than five participants there always is at least one person using the web the impression is that the system as a whole just doesn't work.
But then microsoft just decides to kick its users in the balls again by adding a feature that allows outgoing calls only on chrome and edge while blocking firefox. Meetings work, so that's obviously bullshit.
I guess electron isn't what makes teams terrible, but rather microsoft.
That's me. Like with Slack, both native and web versions are junk, but the web version is leaner and snappier. And no, generally me using the web version didn't cause any issues to anyone on corporate calls.
Terrible software can be coded in any language.
Is this an intrinsic attribute of all web apps, or specific to an implementation?
Firstly, there's something about the combination of saying nothing new and adding very little opinion, plus a few writing/editorial oddities, makes me wonder if this is GPT-generated? Or at best, it's just comms copy from a non-specialist, banging something out in a hurry. (Noting that the author is COO of a 'communication agency'.)
Secondly, given how uninteresting the article to (at least, to a typical HN reader, IMO) why has it popped up onto the front page?
I'm genuinely interested what's going on here - just an anomaly, or HN gaming, or a sign of things to come?
It's been 3 hours on one of the slower hours on HN. The algorithm is loosely engagement / time^2, so something that pops up at the right timing can stand out against really good news 14 hours ago.
But typically the high comment vs upvote ratio triggers the low quality filter and it's likely to fall off soon.
And what's that about notes taking 120 Mb, when Electron apps start at 3-400 Mb? Deceptively split into <App Name> and <App Name Helper (Renderer).
Not to mention when you leave a chat app like Discord or Slack running and they keep instatiating those meme gifs forever, until you run out of ram.
A desktop app based on Electron-Chromium runtime has more integration options with the operating system. E.g. file system access, taskbar/Dock icon and notifications, runs in the background, etc.
If a developer were to create a 100% pure web url app running locally on https://127.0.0.1/foobarapp.html -- ... they'd quickly run into browser's limitations. For example, the sandboxed security model won't let the Javascript inside of foobarapp.html iterate all files of the local file system. And Mozilla's new filesystem api isn't really available yet: https://caniuse.com/native-filesystem-api
Not sure if there's any "deception" here. Developers just want to write desktop apps leveraging their existing Javascript knowledge instead of learning C++/C#/Swift for each platform and trying to manage feature parity in separate code bases.
Chrome added a file system API for some reason, but every Electron based application I've used just used the standard <input type=file> prompt and it worked absolutely fine. Even things like live screen recording and P2P VoIP can be done from the browser now.
I'm sure there are plenty of applications that need Electron, but I'm having a hard time coming up with any.
If a developer has the app run locally on 127.0.0.1, they already have the capability to enumerate files (without the Web browser's cooperation).
- I know that I can access it from any device and any OS.
- Better security and privacy unless it grant it permissions.
- I can open multiple tabs and switch between them.
Browser should be much more sand boxed and never have access to the file system with privileges of a user running browser.
Yes, someone can install malicious electron app but that is totally different than randomly stumbling upon malicious website while browsing/clicking around.
- making sure it works on all platforms independently of the browser you use (because it comes packages with chromium)
- having access to more API from the platform. Although the UI is rendered through a WebView, there's still native code running, that you can hook back into your app. That can be useful to either offload some logic to native, or access native API that you pilot from the WebApps
- having a shortcut icon to open you app in the system (although this is getting obsolete now that Chrome and Safari offer "Add to Desktop" functionally)
Google Chat has a similar issue in that it uses a lot of memory for what it does and has a shitty UI, except it's actually a PWA.
I do get the cross platform benefit, but how many developers do you actually need to build an awesome native application, when much of the interaction is done on the backend anyway? Slack does seem a little complicated, but I have the feeling that you could do Google Chat with perhaps five developers per platform.
In some cases, so you can load and save data from the user's disk instead of the app's back-end.
Because they appear separately on the user’s task switcher. Honestly there’s not a lot more to it than that. And users do appreciate being able to switch to e.g. Slack specifically rather than switch to their browser then find the Slack tab.
You can do all of this with progressive web apps too these days, but every time they come up in HN people crap on them, so… shrug
If it's one of my main productivity drivers (IDE, Browser, E-Mail, Messenger, Note-taking app, whatever) it can be massive and I am willing to update it constantly.
If it's a tiny tool that sometimes offers one functionality and otherwise sits in the tray: No, I don't want it to gobble up 200MB of RAM if you can quite literally draw the window and the 5 checkboxes and 3 buttons with 30 lines of WINAPI code. I might have 10 of these running, a browser-based UI does not make sense for this, yet people keep doing it. Electron is good at UIs, if I only open the UI once per month (but the app is running 24/7) it should optimize for resource usage, not developer happiness.
Some things are in between, even for me. Music player: I prefer foobar2000 or the likes, no images, just a list of songs I can doubleclick. Not a web app. A text editor that does not render mark down, is not an IDE, etc.pp. Not a web app. But for some people these can be really feature rich, not for me.
Will add that where possible, I’ll use the PWA version instead of the Electron version now that Safari on macOS can install PWAs that launch independently from the browser itself (unlike Chrome and its numerous cousins which require the full browser to be open). This sidesteps some of the native access concerns that come with Electron versions and is easier on the battery than the Electron version or a Chrome tab.
I run VS Code, Slack, Discord, Spotify (not Electron, but web tech) all the time and I don't see problems[1]. I mainly use a 7 year old mac, nothing too beefy.
No, I wouldn't like to use a website instead. But I don't crave an actual native app that much either.
[1] Perhaps apart from Discord always updating itself, but that's their decision.
Slack, Discord and Spotify are all "web-based" to their core in the sense that they have an in-built client/server model as part of their core design and purpose. So in those examples, the only thing we have to complain about is the rendering / presentation layer.
And that kind of shifts the goalpost if you focus on those types of apps in my opinion.
Because my dislike for web apps is not strictly that they are using a browser-based presentation engine. If those UIs felt sluggish to me then I might choose to blame the underlying tech, but I wouldn't question it as much if they were not network-enabled applications in the first place (unless UI performance was a real pain and I thought they could perform better using something native).
The real issue for me is that our industry likes to chase trends like they are all or nothing. I don't like that every single application is moving to a web-based model whether or not it makes sense for that app. For the majority of my personal use, I don't need my applications to be network-enabled in the first place. I don't want them to sync to cloud storage, or provide collaboration features. I don't want to have to have an "account" with some SaaS company to use a word processor or a photo manipulation program.
I want my data local. I don't want my usage and data tracked. I don't want the app to stop working if my ISP has an outage and I don't want my data and app to disappear if the company goes out of business. I also don't like that web apps tend to see a much higher rate of UI changes pushed to the user. Software versions have largely disappeared for end-users and marketing. Now it's a continuous stream of pushed changes whether you chose to "upgrade" or not.
Electron apps are the hill I want to die on.
It is against hacker ethos, incredibly slow and bloated, and teaches devs features are the only thing which matters and not how much memory or cpu runtime it uses.