Web apps are better than no apps
molodtsov.me
molodtsov.me
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.
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?
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.
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.
Web apps don't have any of those problems.
it could provide a cross platform, sandboxed alternative to Shipping Chromium, while still supporting web technologies to build the GUI (powered by the system's native web view?)
i dont like having a centralized platform but i guess we could establish a standard file format (like .deb or AppImage?) or have a federated platform? i really know very little about all this though...
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 addition if an OS provides a way for sandbox settings of apps to be changed, then something like "ublock origin for the OS" could be created, where someone maintains a list of what capabilities should be granted to various apps, and users can just install something once and forget about it to harden their system.
Most users trust most of the apps installed on their computer, but might have a few things that they are suspicious of — such as things they have to install for school or work. Providing a way for users to restrict the capabilities of specific apps when they feel like they need it could be valuable.
Linux already effectively has this because it has stuff like user namespaces and better support for controlling other processes using ptrace than other OSes. This enables users to use things like proot and bubblewrap to apply sandboxing when needed.
Aside from the factual inaccuracy (Firefox has a "Work Offline" menu item), this is an irrational demerit. Other apps can do exactly the same things (and more); you're applying a double standard.
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.
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.
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 is quite the claim, I wonder if you have any data to back that up. As it goes against everything I've seen.
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.
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!
Given the disadvantage that it starts at, JavaScript is astonishingly fast, due to the extreme investment in it that you mention. However, in almost all real-world scenarios, it’s still generally pretty easily beaten by ahead-of-time-compiled languages, even if on some microbenchmarks and for a few specific sorts of tasks it can end up competitive with certain of these compiled languages.
The claim to be refuted was not "Javascript is faster than AOT compiled languges" however.
Instead, the claim was: "[Javascript is] around the speed of Java and Go in some cases, which are compiled", which is not far off. Especially given that these two are not in general among the fastest kids like C, C++, and Rust.
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.
This page has a list of examples: https://madewithwebassembly.com/
Many apps that are not CRUD need more efficient cpu performance of WASM... physics rendering engines, AutoCAD modeling, machine learning, etc.
Figma
Teams (the web version)
Outlook (the web version)
MS Word (the web version)
MS Excel (the web version)
Google Documents
Google Sheets
Google Earth
(similarly the iCloud versions for Pages, Numbers, etc)
Canva
Lightroom (the web version)
VSCode
Soundtrap
and a whole lot more.
I happen to write a newsletter where I interview this sort of company, here are some recent examples that use Wasm:
- Rayon (CAD): https://digest.browsertech.com/archive/browsertech-digest-ho...
- Modyfi (raster image editing): https://digest.browsertech.com/archive/browsertech-digest-ho...
And by "real loads" I really mean just more than two dozen items on a list of whatever it is the app displays.
1. Code "fast enough" to manipulate a few things (say, listings) will not be fast enough to handle hundreds of them;
2. UI frameworks and components people use are designed to look nice for demo case, which is again few elements, and tend to choke under actual, real workload of dozens, or hundreds, or thousands of elements.
Next time you see a website that paginates your results, like e.g. a store that shows you 20 results per page, look for a dropdown controlling the pagination threshold. See if you can bump it to 50 or 100 elements per page, and ask yourself, why do you dread doing so.
[1] https://www.construct.net/en/blogs/construct-official-blog-1...
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.
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.
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.
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.
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.
Here's the Unreal engine demo from 10 years ago: https://www.youtube.com/watch?v=XsyogXtyU9o
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
Sorry, about benchmarks I just quote myself: > I take these performance benchmarks with a rock of salt. They are mostly hyper-optimzied generics which are as far away from actual production code as it can be. They are written in a way to allocate as little memory as possible and is done by people who know exactly what they are doing.
Do you think we should only compare JavaScript written by newbies?
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.
Especially the garbage collection strategies of Java are second to none (sorry, don't want to be a shill).
> For real-world applications....compare IntelliJ, Eclipse, Visual Studio, or Sublime against VSCode. My experience is that VSCode has horrible input latency and Intellij is blazingly fast once indexing is done.
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.
citation:
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
“Data is sent between workers and the main thread via a system of messages — both sides send their messages using the postMessage() method, and respond to messages via the onmessage event handler (the message is contained within the message event's data attribute). The data is copied rather than shared.”
https://developer.chrome.com/blog/transferable-objects-light...
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.
Claiming JS has the same performance as Java or Go is not.
JS also has had decades of optimizations. So if WASM with essentially no optimization is just as fast as JS, that's a huge interoperability win.
> Claiming JS has the same performance as …
"in some cases"
Also, why do you compare JS written by amateurs with Go/Java experts? There are JS experts too.
Indeed, JS is pretty darn fast.
Not because of innate characteristics, but because of the human-centuries spent optimizing JIT VMs.
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.
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).
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.
Why not create a UI system, like X Window over the web (I know X can be done over the network) specifically for web apps? Solve the issue at the root and leave the DOM to documents.
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.
And C++ compiled to WASM will have the same slowdowns if it needs to touch the DOM.
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.
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.
Is this an intrinsic attribute of all web apps, or specific to an implementation?
Terrible software can be coded in any language.
Dwarf Fortress and Factorio are actually some of the least demanding games to run, by the way. I think a 2005 laptop could run Factorio. It's known for being easy to run
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.
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.
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.
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
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.
In some cases, so you can load and save data from the user's disk instead of the app's back-end.
- 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)
- 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.
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.
I first ran Zulip chat client in a Chrome web browser tab. But I often missed replying to new messages because I always forgot to manually cycle over to the Zulip tab to check for them.
After a few days of fighting that limitation, I gave up on Zulip in the web browser tab and installed the desktop version of Zulip (Electron runtime). Now new unread messages trigger a red dot on the taskbar. The desktop version is just easier to use.
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).
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
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.
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.
But I guess the one big advantage for electron is the Web stack. It is so ubiquitous and relevant that most developers have experience with it. In combination with open source, this is the reason VS Code (as an example) has so many contributions, leading to many features for a variety of languages and so many plugins. As a result, I don't have to learn other editors or IDEs which makes me more productive.
I would welcome performance improvements, but I heavily doubt that a native alternative for the same scope of VS Code can exist. Every other UI solution is niche compared to the Web. Even for mobile apps, many companies use something like React-native or Ionic instead of developing two native versions.
I hope that one day electron uses Bun[1] as it offers much more performance compared to node/v8. But until then, I will happily trade performance for productivity.
[1] https://bun.sh/
I don't know, (neo)vim and emacs are kind of the counterexample, and they have way more extensions and plugins. Neovim especially is seeing tons of momentum at the moment.
If an application that emulates a calculator was just now a new idea it would likely be first developed as a web application those would be an order of magnitude larger that it needs to be. It would use much more memory and cpu than a native version. You do get some things that could be a value like screen reader capabilities. It would show up in app stores but would be implemented in Electron.
In the "olden days" of the 1990's such an concept would likely been done in VB6 and distributed as an .exe since that the user base of Windows desktop users was the most significant. That resources consumes by the executable would be "nit" on today's devices.
Even though from a business perspective shipping bloated apps makes sense, developers are aware of the bloat and it bothers us.
If you compare Notion to Obsidian, which is also an electron app. Obsidian’s data is stored locally and it is extremely fast whereas Notion is not quick at all. It’s more complicated than the compiled vs interpreted, but also includes where your data is stored and the underlying infrastructure behind that data.
If there is no such option, I just drop it.
For a real wep app it's the user's choice.
The old (Qt?) Spotify client was better and also supported Linux though, I'll concede that
If you build for native Mac, windows and Linux users will be disappointed they can’t use it.
If you build it using electron (or similar) so that you can support all these platforms, lots will complain that it is bloated.
If you built it as a desktop app then those who want it on mobile will complain.
I do think web apps, especially with the power of PWAs, are the best starting point for most projects unless you know it obviously won’t be a fit. It isn’t going to make everyone happy, but at least it does give you the widest coverage of where people can use it.
Not yet, it's not. At least for the applications that I use (outside of work), I haven't had to settle for a web app yet, fortunately. At work, I have no choice but to use a couple.
It's not a given that I'd prefer a web app over nothing, personally. Being a web app is a serious downside, and I could see many situations where I'd just use nothing instead. It all depends on what my actual needs are.
I know this is not the same UX as installing an app. But why isn't this technique more standard?
Besides more efficient resource usage, another benefit is that it keeps the client/server architecture.
As an aside, if the application isn’t careful, that approach can potentially open up a security hole, because external javascript on a web page in your browser can perform requests to localhost.
Anyone else surprised that Apple Notes takes up 120mb? That... sounds like an electron app to me.
Electron based apps are a compromise, and the tradeoffs are well known. They'll be slower - but they will fast enough for most applications, if you look at apps like Slack, Spotify, VS Code. They won't look like native apps, but they allow for a full cross-platform app with your branding (again, see Spotify that has a consistent interface on web, desktop and mobile).
And of course, it's easier to find a web developer than a QT developer.
Many apps are free, do not do heavy computations or need to look fancy. These apps should all just be websites imho. That normally serves all the needs of the app creator and it works across platforms. As a user I have a safety benefit (as I have more control about what websites can do, e.g. via browser settings and extensions). Modern browser APIs should leave me with a similar feature set (home screen icon, notifications, peripheral access, ...)
What problem are you trying to solve? Game app? Go native, maybe. Utility app? Native too, maybe. Business app? Web will do, unless marketing demands it be native b/c management wants the darn icon on every darn screen out there.
What if it's neither? Chat apps seem to be the next app platform.
At some point a native gui toolkit feels just as, if not more, limited than a web UI in Electron only with scarcer documentation and guides/tutorials to help you.
Yes. Just like stale bread is preferrable to dying of starvation.
And if you already have a web app, why not wrap it in Cordova to make the native app?
The only reason web apps are popular is portability. If it were easy to make one native app that ran on every computer, there would be a stampede toward it and a loud sucking sound from the vacuum of apps leaving the web. Java is a travesty and there's nothing else that's popular enough to sway an entire industry.
Web apps are shitty thin clients.
Nope, they don't look familiar because they look different on every platform.
Give me consistency. If I buy a phone of some different brand (or use the family tablet which happens to be of a different brand), give me the same interface for each app as on the old phone.
And a web app look rarely like the most used desktop apps people are used to: Excel and Word
When I use an app, I don’t care what it looks like on somebody else’s phone, I care that it works the same as all the other apps on my phone.
> Give me consistency.
I want it to be consistent with all the other apps on my phone. I don’t care if it’s consistent with what’s running on somebody else’s phone.
If anything, it's tech world that has less brand loyalty. I have an apple, windows, and android.
The average tech user though? They're probably going all in on one
Or do you want competition in the smartphone space?
You know, where people can freely move from one brand to another if they don't like certain aspects of their current brand? Like how the free market is supposed to work?