Web apps are better than no apps

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&#x27;m not so sure about when installing native applications.<p>Often I see Nvidia&#x27;s or Microsoft&#x27;s or Discord&#x27;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.<p>Another example, if I use Discord&#x27;s web it has no real way of knowing what I&#x27;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&#x27;s editor) which means that Discord tracks all of my activities on my computer.<p>Thus, honestly, I&#x27;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&#x27;s hard for me to debug what data they are sending and receiving, something that&#x27;s quite transparent if I open the dev tools.

&gt; 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++.<p>JavaScript isn&#x27;t as fast as C++ or Rust, but it&#x27;s pretty fast. Around the speed of Java and Go in some cases, which are compiled.<p>For a web app the speed of the language is rarely the bottleneck anyway, other than some exceptional cases like WebGL-type stuff.<p>What&#x27;s also not mentioned is that because JavaScript is single-threaded and garbage collected, classes of issues that you&#x27;d see in C++ are completely avoided (of course at the cost of absolute performance potential). I&#x27;d argue that TypeScript is probably the easiest language to grok, but I&#x27;m biased.<p>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&#x27;m honestly surprised the Chromium team hasn&#x27;t already addressed this with the Electron team somehow by now, given the popularity of the apps.<p>Though, I guess with newer apis such as the File System one Electron is slowly becoming unnecessary (but I doubt it&#x27;ll ever go away because it&#x27;s doubtful Chrome will include <i>all</i> of the APIs necessary).<p>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&#x27;t go far enough, which is why you see 3rd parties picking up the slack.

&quot;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++.&quot;<p>This statement is misleading and false.<p>The distinction between &quot;interpreted&quot; and &quot;compiled&quot; isn&#x27;t as clear-cut as it once was, especially in the context of modern languages and runtimes. However, when it comes to JavaScript, here&#x27;s the general understanding:<p>-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.<p>- 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) &quot;ahead of time&quot; into machine code or other languages. Examples include the asm.js subset of JavaScript and WebAssembly (although WebAssembly isn&#x27;t strictly JavaScript, it&#x27;s a target for languages including C&#x2F;C++ and Rust, among others).

I hate to agree with this. Web is the best way to cram loads of features into a limited amount of dev time.<p>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.<p>And every time it happens, I die a little inside.

Did this &#x27;article&#x27; make anyone else&#x27;s antenna twitch?<p>Firstly, there&#x27;s something about the combination of saying nothing new and adding very little opinion, plus a few writing&#x2F;editorial oddities, makes me wonder if this is GPT-generated? Or at best, it&#x27;s just comms copy from a non-specialist, banging something out in a hurry. (Noting that the author is COO of a &#x27;communication agency&#x27;.)<p>Secondly, given how uninteresting the article to (at least, to a typical HN reader, IMO) why has it popped up onto the front page?<p>I&#x27;m genuinely interested what&#x27;s going on here - just an anomaly, or HN gaming, or a sign of things to come?

Why deceptively package the javascript as an app when you can just put it on a website?<p>And what&#x27;s that about notes taking 120 Mb, when Electron apps start at 3-400 Mb? Deceptively split into &lt;App Name&gt; and &lt;App Name Helper (Renderer).<p>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.

Not a fan of Electron or native-ified apps in general but I usually have a very easy decision matrix:<p>If it&#x27;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.<p>If it&#x27;s a tiny tool that sometimes offers one functionality and otherwise sits in the tray: No, I don&#x27;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&#x2F;7) it should optimize for resource usage, not developer happiness.<p>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.

I don&#x27;t get what&#x27;s all the hate around Electron apps to be honest.<p>I run VS Code, Slack, Discord, Spotify (not Electron, but web tech) all the time and I don&#x27;t see problems[1]. I mainly use a 7 year old mac, nothing too beefy.<p>No, I wouldn&#x27;t like to use a website instead. But I don&#x27;t crave an actual native app that much either.<p>[1] Perhaps apart from Discord always updating itself, but that&#x27;s their decision.

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.<p>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&#x27;t have to learn other editors or IDEs which makes me more productive.<p>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.<p>I hope that one day electron uses Bun[1] as it offers much more performance compared to node&#x2F;v8. But until then, I will happily trade performance for productivity.<p>[1] <a href="https:&#x2F;&#x2F;bun.sh&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;bun.sh&#x2F;</a>

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.<p>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.<p>In the &quot;olden days&quot; of the 1990&#x27;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 &quot;nit&quot; on today&#x27;s devices.<p>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.<p>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&#x27;s usability if run in a tab (e.g Spotify - can’t sort playlists).<p>If there is no such option, I just drop it.

I wouldn&#x27;t call a an Electron app strictly a wep app, because you can control the browser version it uses.<p>For a real wep app it&#x27;s the user&#x27;s choice.

The reason I prefer web apps (running in the browser, not in Electron) is because companies push for native apps so aggressively that it&#x27;s <i>extremely obvious</i> that native apps make it easier to mine my private data for profit, including on mobile.

As someone who&#x27;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&#x27;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 <i>in theory</i> companies could all be writing cross-platform Qt apps, but the reality is most were&#x2F;are not, and the proportion of non-FOSS desktop apps that have official Linux support has gone noticeably up via Electron<p>The old (Qt?) Spotify client was better and also supported Linux though, I&#x27;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.<p>If you build for native Mac, windows and Linux users will be disappointed they can’t use it.<p>If you build it using electron (or similar) so that you can support all these platforms, lots will complain that it is bloated.<p>If you built it as a desktop app then those who want it on mobile will complain.<p>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.

&gt; Unfortunately, the actual choice is about having an app or not, and I’d rather take something over nothing.<p>Not yet, it&#x27;s not. At least for the applications that I use (outside of work), I haven&#x27;t had to settle for a web app yet, fortunately. At work, I have no choice but to use a couple.<p>It&#x27;s not a given that I&#x27;d prefer a web app over nothing, personally. Being a web app is a serious downside, and I could see many situations where I&#x27;d just use nothing instead. It all depends on what my actual needs are.

Sorry, but Electron wrapped application should not be considered a &quot;web app&quot;. It&#x27;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?<p>I know this is not the same UX as installing an app. But why isn&#x27;t this technique more standard?<p>Besides more efficient resource usage, another benefit is that it keeps the client&#x2F;server architecture.

&gt; 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.<p>Anyone else surprised that Apple Notes takes up 120mb? That... sounds like an electron app to me.

I mean I can&#x27;t disagree with the title, but it&#x27;s a bit of a straw man as nobody says they won&#x27;t make an app if they can&#x27;t make it a webapp.<p>Electron based apps are a compromise, and the tradeoffs are well known. They&#x27;ll be slower - but they will fast enough for most applications, if you look at apps like Slack, Spotify, VS Code. They won&#x27;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).<p>And of course, it&#x27;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.<p>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&#x27;s great. The author mentioned Craft (an only Mac-native Notion-like app). I&#x27;m now working on turning my note-taking app editor into a Notion alternative -&gt; an advanced block editor based on just plaintext. Built using Qt C++ &amp; QML.[1] That way I achieve native-like performance and resource use while being cross-platform.<p>[1] <a href="https:&#x2F;&#x2F;x.com&#x2F;mamistvalove&#x2F;status&#x2F;1704100506644164859" rel="nofollow noreferrer">https:&#x2F;&#x2F;x.com&#x2F;mamistvalove&#x2F;status&#x2F;1704100506644164859</a>

Aren&#x27;t we facing a case of: everything seems like a nail for my hammer?<p>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&#x2F;c management wants the darn icon on every darn screen out there.<p>What if it&#x27;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.<p>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&#x2F;tutorials to help you.

&gt;<i>Web Apps Are Better Than No Apps</i><p>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.<p>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.<p>The <i>only</i> reason web apps are popular is portability. If it were <i>easy</i> 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&#x27;s nothing else that&#x27;s popular enough to sway an entire industry.<p>Web apps are shitty thin clients.

&gt; 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.<p>Nope, they don&#x27;t look familiar because they look different on every platform.<p>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.