hckrnws
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.
IMO the solution is to give users the tools to run apps in a sandbox without forcing them to or making it the default. If an operating system like macos were to ship with a user-friendly UI to change what a given app has access to, then even relatively non-technical users might decide to e.g. turn off WhatsApp's access to various things if they happen to read a news article about the app's data collection.
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.
It occurs to me that there exists a fairly elegant UI trick to hide this: RiscOS had no save or load dialogs, everything was drag and drop to or from the file browser.
> 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.
> 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
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.
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.
Centralizing everything into app stores benefits our corporate overlords more than anyone else. It gets even worse when every approved app has to depend on the platform's API. The privacy and security issues still exist, but now developers and users have to pay to for an untrusted app.
Web apps don't have any of those problems.
Neither do Linux distros
maybe wasm+wasi(x) would allow us to build an open "app store" platform or a sort of package manager for desktop apps?
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...
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.
May I ask you to elaborate on what is not working for you with WebUSB and Web Bluetooth? I'm surprised to hear ChromeOS can't run Web Bluetooth properly.
> 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.
WebAssembly with sandboxing might help with this.
> 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].
[1] https://www.construct.net/en/blogs/construct-official-blog-1...
Fair enough, Construct looks cool. If you or anyone from your team is interested in doing an interview for a technical newsletter about browser-based apps[1] I'd be glad to get a JS perspective on high performance in the browser.
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
>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.
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.
Google Sheets is a big one. It really does seem like CRUD when compared ti Excel.
Desktop or web Excel?
Desktop.
Comment was deleted :(
Even those CRUD apps you and I use daily have substandard performance, as they get bottlenecked by amount of data they can process, in at least two major ways:
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.
I see it mostly with what I would call “industrial applications”: video editing, CAD, etc. Besides games, consumer software tends not to be computationally intensive, so there are few consumer examples (which I think leads to a sort of “JavaScript is fast enough for everything” fallacy among web devs)
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...
Webdevs seem to have a blind spot around UI. Plenty of end-user apps - like music players - and websites - like e-commerce stores - tend to have compute-intensive UIs. They may not look compute-intensive for a dev on a beefy machine, playing with mockups and toy loads, but they absolutely become noticeable compute hogs on real machines with real loads.
And by "real loads" I really mean just more than two dozen items on a list of whatever it is the app displays.
My company has several tables in our UI whose API endpoints simply query for all records in that table without pagination. hundreds of rows are loaded into a table plugin, even if you'll never get past the first page
That's... good. Hundreds of rows is a trivial amount, so unless they're expensive to generate on the backend and/or meaningfully large, it should be a non-issue. The question is, what is the page size in the UI, and why is it less than "hundreds of rows"?
Browsers can handle hundreds of rows just fine, even on, say, a modest Chromebook. No problem. If you're looking for someone to blame, you need to blame the crummy UI frameworks in use on the site and the half-rate developers who chose not to vet (and veto) their use. And blame the screwy job requirements and hiring practices at the company that insisted that those developers—the ones who took this development approach and worked with this kind of tech—were the right ones to hire and others were the wrong ones.
Of course. I'm definitely not blaming browsers for this - we're talking about trivial requirements here, while browsers themselves are absurdly well-optimized these days. Which makes it even harder to watch the webdevs casually throw that all away using crummy tools, too focused on moving fast themselves to give a damn about letting users move fast too.
Figma is a good example. Likewise, many games. Google Sheets? GIS apps? Probably the next big things in both DAWs and video editing will be in the browser too…
Oh yeah I guess Figma is one, but I'm not in the design department. I guess there are a lot of apps out there that benefit from it, but I don't seem to use any of them
>I've always wondered what kind of apps these are. The vast majority of web apps I use are all CRUD.
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.
Oh yeah I'm sure those applications exist, I just don't seem to use or work on any of them
> 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.
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
Speed is achieved via optimization, which is achieved via constraints. Javascript is being known for its inefficiency. Saying JS is just as fast is a hot take and whoever claims that has the burden to proof otherwise.
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.
> done by people who know exactly what they are doing
Do you think we should only compare JavaScript written by newbies?
> JS id as unoptimizable as can be, thanks to its hyper dynamic nature.
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.
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.
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.
Comment was deleted :(
My experience is that IntelliJ takes way longer to start and freezes more frequently.
How often do you start up your IDE a day?
This is classic goal-post moving - you started out by saying that Intellij was faster than VSCode, then after a commentator said that their experience was the opposite, you moved the goal-post to "well it doesn't matter". You should be willing to admit when you're wrong.
> 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.
Comparing WASM and JS is fine.
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.
> > Around the speed of Java and Go in some cases …
> Claiming JS has the same performance as …
"in some cases"
Quake 1 (about 100k lines of C) runs in the browser just fine: https://www.netquake.io/quake
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.
That quake demo is surely running on the WASM runtime which isn't really related to JavaScript: https://en.m.wikipedia.org/wiki/WebAssembly
Webassembly started its life as a JS hack, called asm.js: https://en.wikipedia.org/wiki/Asm.js, which itself was fully capable of running Quake.
Here's the Unreal engine demo from 10 years ago: https://www.youtube.com/watch?v=XsyogXtyU9o
now you can make web apps in your compiled language of choice (limited choice) and not worry (as much) that its not fast enough
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.
Just use Workers API and spawn another JavaScript thread
Well then you’re back to the bridge problem. postMessage is crazy slow. There are some problems where parallelization will outperform the ipc cost with postMessage but those problems are few and far between. I haven’t dove into the new web GPU api but it does look kinda promising (shared memory is hard, so I’m apprehensive). I’m sure some of these things will get solved in the long run but for the time being, the bottleneck to browser performance is not necessarily JavaScript itself but the webapis that are crafted around a single threaded model. This is really my only point. Aside from providing systems engineers familiarity with syntax/devex and possibly some portability with some llvm/wasm compatible libs, there is little point in wasm runtimes at this current time imo.
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.”
Transferable objects have been part of the spec for a while now, making it possible to send data back and forth contexts with no copying.
https://developer.chrome.com/blog/transferable-objects-light...
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.
> Around the speed of Java and Go in some cases, which are compiled.
That is quite the claim, I wonder if you have any data to back that up. As it goes against everything I've seen.
Is it "quite the claim"?
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!
It is still quite the claim.
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.
>However, in almost all real-world scenarios, it’s still generally pretty easily beaten by ahead-of-time-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.
Yeah, what I expressed was a bit sloppy. Go is AOT-compiled, but kinda the weak link among most such languages as regards performance. Java is somewhere in between the two, and the HotSpot JVM is also generally handily faster than JavaScript engines (it also has had rather a lot of effort put into optimising it, and without most of the starting disadvantages of JavaScript).
You really should take benchmarks with a grain of salt, but:
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.
"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'm honestly surprised the Chromium team hasn't already addressed this with the Electron team somehow by now
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.
Microsoft has this on Windows: https://learn.microsoft.com/en-us/microsoft-edge/webview2/
Teams 2 is supposed to use it (and there's a couple smaller system apps that use it).
you solve it the same way you do with iOS and Android - an LTS release with careful deprecation of APIs.
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.
> 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.
Indeed, JS is pretty darn fast.
Not because of innate characteristics, but because of the human-centuries spent optimizing JIT VMs.
Comment was deleted :(
> 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.
I suspect MS is working on some sort of common browser layer for Electron apps on Windows.
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.
>For a web app the speed of the language is rarely the bottleneck anyway, other than some exception cases like WebGL-type stuff.
If we're talking about a glorified form/CRUD app, no.
For web apps proper, that's not really the case.
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 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.
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.
Yes, but any UI stuff in C++ is also going to be a major source of slowdowns.
And C++ compiled to WASM will have the same slowdowns if it needs to touch the DOM.
That actually makes me want to create a set of UI benchmarks comparing performance standard UI operations in C++ with Qt vs JS with DOM. I think I’ll look into it over the weekend.
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.
Yeah this really bugs me because it leads people down the path of WASM craziness when the language is rarely the problem.
Most web apps are slow because the DOM is slow.
The DOM is plenty fast.
Most web apps use it for what it wasn't meant to do, in an inefficient matter, with useless rerenders and overhead.
Let me clarify: the DOM is fast _at what it does_. But in order to truly serve things like web apps rather than documents it needs to have primitives like list virtualization. It doesn't, so people end up using needlessly complex JavaScript frameworks that drag down performance.
> But in order to truly serve things like web apps rather than documents it needs to have primitives like list virtualization.
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.
Comment was deleted :(
Or just use htmx.org
This! Call it once with a string containing 457 elements and the DOM is blazing fast. Call it 457 times to create an element and the DOM is slow.
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.
And every time it happens, I die a little inside.
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.
MSN Messenger really was never that bad, was it?
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.
For me only the web version works. The native macos version doesn't let me log in for some obscure reason. Teams is trash.
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.
Teams is just shit. Discord is also a web app and works great.
Discord's UI occasionally has me cursing but at least they've kept it consistent. And it is true that it doesn't have the same performance problems.
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.
> whenever I use Teams
Terrible software can be coded in any language.
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?
I'm sorry, but there's something wrong with your computer at that point. Seconds of lag to type is ridiculous. This is not most people's experience with VSCode. Visual Studio is way more sluggish to me (and probably most people)
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
Dwarf Fortress and Factorio are what I play. And while DF may be a graphically simple game, it's well known that many fortresses which don't succumb to fun succumb instead to FPS death, as the in-depth simulation eventually surpasses every computer as the fortress grows and sieges build up. It's certainly a demanding game, and towards the late game even on my perfectly working mid-tier PC it slows to a complete crawl. Factorio is easy to run, it's just that I mostly play things like Team Fortress 2, Factorio, Geometry Dash and Dwarf Fortress. I needed some examples and Factorio isn't from 2007, so I picked that. The most demanding one is of course DF.
And unfortunately, in the world of electron apps there’s far more leaning in the direction of Teams than in the direction of VS Code.
> 5 seconds later, the thing I wanted appears
Is this an intrinsic attribute of all web apps, or specific to an implementation?
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?
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.
>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.
>That's great, but I don't know any Electron app that needs file system or task bar access.
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.
Does Zulip not add these red dots to the favicon? Because every chat application I've used does. I've got a bunch of them pinned exactly for this purpose.
There is unread counter in the favicon
> 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.
This is actually my preferred approach. If the app doesn't have a compelling reason to be native I prefer it to be a website.
- 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.
Electron isn’t just a website-as-an-executable, it has a whole separate API that goes what a browser does/could/should offer. https://zeke.github.io/electron.atom.io/docs/api/
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.
> Why deceptively package the javascript as an app when you can just put it on a website?
In some cases, so you can load and save data from the user's disk instead of the app's back-end.
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.
Web apps don't require constant access to the internet.
They do, because the browser will arbitrarily unload your webapp for no reason whatsoever, so you'd better have the Internet available any time you want to switch back to the app...
Websites have a code size restriction? What is it?
You seen a 100MB web apps? That's pretty common in mobile apps. A practical restriction rather than a principle one. A web app can be as large as it wants, it will just take forever to load or some obscene over-engineering to stream the modules.
So you can later charge extra for the web version.
> 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.
I can feel the frustration when people are forced to use a specific proprietary app that is bad (hey MS Teams). They clearly have the resources and experience to build better native apps.
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/
> 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 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.
The fact that the most common denominator for publishing an application to reach the maximum user base is a web application is kind of a depressing one to developers. We know that to reach a maximum user base that we need to ship using bloated tech.
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.
I think web apps are also slower, because they don’t store data locally.
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.
As an interim solution, I just wish everyone with a stand-alone app that runs on Electron would let me open it as a tab (E.g Morgen), even though more often than not, the team behind app X would also nerf it's usability if run in a tab (e.g Spotify - can’t sort playlists).
If there is no such option, I just drop it.
I wouldn't call a an Electron app strictly a wep app, because you can control the browser version it uses.
For a real wep app it's the user's choice.
Agree, electron != web-app. It's a native application that I need to install on my local machine with a platform specific binary. A web app can be accessed immediately from any browser on any machine with network access.
The reason I prefer web apps (running in the browser, not in Electron) is because companies push for native apps so aggressively that it's extremely obvious that native apps make it easier to mine my private data for profit, including on mobile.
As someone who's been using Linux for around 15 years, this is a sentiment I often find myself expressing to younger (at least in Linux time) friends complaining that some commercial app we both use is Electron-based - I'm too busy being amazed that we have first party Linux support at all, and I can see clearly what technology it was that led us there. Yes in theory companies could all be writing cross-platform Qt apps, but the reality is most were/are not, and the proportion of non-FOSS desktop apps that have official Linux support has gone noticeably up via Electron
The old (Qt?) Spotify client was better and also supported Linux though, I'll concede that
Honestly you’re damned no matter which move you make unless you have the dedicated teams to build out for every platform.
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.
> Unfortunately, the actual choice is about having an app or not, and I’d rather take something over nothing.
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.
Sorry, but Electron wrapped application should not be considered a "web app". It's a web app and a browser in a bundle. Web apps, added to desktop or homescreen is in whole different league, as they do not require additional runtime, and main runtime always gets all security patches. RAM usage depends on complexity of application. While Chrome, Edge and Safari already support adding PWA web apps to desktop, why are we still bundling them into Electron wrappers?
Instead of wrapping the application with something like Electron, why not install as a service and connect to a localhost port using your default browser?
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.
It’s more obscure for users if they have to open http://localhost:some_port/. You also have to decide on a hopefully free port.
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.
CORS policy usually requires that the port must match. This issue potentially applies to all web apps, not only those hosted on localhost
Comment was deleted :(
Hrmmm I wonder if you could do this on mobile.
Last time I checked it's not possible on iOS. On Android it's possible with some effort (e.g. you have to use Termux), not something you could expect a user to setup
> Of course, Notion is a complex app by itself, but in comparison, the native app for Apple Notes usually takes around just 120Mb for me.
Anyone else surprised that Apple Notes takes up 120mb? That... sounds like an electron app to me.
I mean I can't disagree with the title, but it's a bit of a straw man as nobody says they won't make an app if they can't make it a webapp.
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.
I would even go a step further and say Web Apps are better than platform apps (including wrappers like electron) for most simple applications.
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, ...)
People should try QML (with C++), it's great. The author mentioned Craft (an only Mac-native Notion-like app). I'm now working on turning my note-taking app editor into a Notion alternative -> an advanced block editor based on just plaintext. Built using Qt C++ & QML.[1] That way I achieve native-like performance and resource use while being cross-platform.
Aren't we facing a case of: everything seems like a nail for my hammer?
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.
As someone who has looked into using Gtk+, Qt, Wxwidgets, Dear Imgui, Nuklear, Druid and Lazarus, I see the appeal of Electron.
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.
>Web Apps Are Better Than No Apps
Yes. Just like stale bread is preferrable to dying of starvation.
Beside from the blog post, when i was reading the post i noticed that his blog is not only smooth, but everything is where it should be, the UI is awesome i enjoyed reading the post.
Web app must be there if you want invited people to instantly be able to join and see something.
And if you already have a web app, why not wrap it in Cordova to make the native app?
I read the blog and I am confused,what are those web apps he is talking about? anything running inside a browser? wasm? electronjs? web crud? SPA? PWA?
almost all the web apps out there are mobile friendly out there unless they are too much complicated in themselves
Web apps are worse experience for the user, cost more to develop, and are more complex and difficult to operate and support, besides being resource pigs.
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.
> Such apps leverage the native platform’s interface, including windows, buttons, text areas, and everything else. They look right and familiar, and they behave this way.
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.
> Nope, they don't look familiar because they look different on every platform.
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.
They are saying if they have say an iphone and an android (tablet?), the same app should behave the same. Contrary to you, some people could not care less about "consistency" of different apps that have different UIs and do different things anyway.
Yes, we have different interfaces on the web already, and nobody is complaining that the Gmail login button looks different from the Facebook login button on the web.
to be fair there are a lot of those people who would not shut up about "native" html and "use the platform". Anyone develops for more than one platforms knows that platform is always the first thing to be abstracted away
Where is this magical market that has an iPhone AND Android tablet? I would wager that ihat is a pretty rare user, and even rarer to be using the same native apps on both.
The family's tablet can be of a different brand than each family member's phone.
Leave tech world and look at what people have. Most iPhone users have Windows machines.
I'm not talking about windows and iPhones though, iPhone users are buying iPads, why would they buy an android tablet?
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
Comment was deleted :(
Do you want to advocate that everybody buys a single brand?
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?
I'm literally not advocating for anything, I'm telling you what it's like right now
Yes, and if we want more competition in the smartphone space, it seems silly to argue that everyone has or should have the same brand of everything.
Most people use two platforms at most. Phone and PC, and these already look different because of the screen sizes and orientation.
And a web app look rarely like the most used desktop apps people are used to: Excel and Word
Stuff looks different on the web everywhere, yet people know how to find their way around without any problems. On the web, Facebook has a different shape and color of login button than Gmail, but nobody's complaining.
To be fair a native iOS app will look the same on a new iPhone and same with android apps on a new android based phone.
iOS apps tend to have back buttons, vs Android's swipe from left side to go back
This paradigm isn’t necessarily correct for the modern iOS experience. Many apps I use can be handled with just swiping down or back.
Crafted by Rajat
Source Code