27 ms·

Web apps are better than no apps

114 points by _xivi 3y ago

amelius 3y ago
> 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.
- croes 3y ago
  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
  - amelius 3y ago
    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.
- quickthrower2 3y ago
  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.
  - mavhc 3y ago
    iOS apps tend to have back buttons, vs Android's swipe from left side to go back
    - Klonoar 3y ago
      This paradigm isn’t necessarily correct for the modern iOS experience. Many apps I use can be handled with just swiping down or back.
- JimDabell 3y ago
  > 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.
  - nsonha 3y ago
    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.
    - Capricorn2481 3y ago
      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.
      - amelius 3y ago
        The family's tablet can be of a different brand than each family member's phone.
      - joshmanders 3y ago
        Leave tech world and look at what people have. Most iPhone users have Windows machines.
        amelius 3y ago
        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.
        Capricorn2481 3y ago
croes 3y ago
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.
- master-lincoln 3y ago
  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.
gidis_ 3y ago
"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).
- esailija 3y ago
  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.
- sentimentscan 3y ago
  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
- afavour 3y ago
  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.
nottorp 3y ago
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.
- nsonha 3y ago
  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.
  - sanderjd 3y ago
    Web apps don't require constant access to the internet.
    - TeMPOraL 3y ago
      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...
  - pjc50 3y ago
    Websites have a code size restriction? What is it?
    - nsonha 3y ago
      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.
- nottheengineer 3y ago
nottheengineer 3y ago
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.
- HeckFeck 3y ago
  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.
  - jwells89 3y ago
    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.
- mozey 3y ago
  > 5 seconds later, the thing I wanted appears Is this an intrinsic attribute of all web apps, or specific to an implementation?
- matwood 3y ago
  > whenever I use Teams Terrible software can be coded in any language.
  - kamray23 3y ago
    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?
imsurajkadam 3y ago
almost all the web apps out there are mobile friendly out there unless they are too much complicated in themselves
phartenfeller 3y ago
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/ https://bun.sh/
- lawn 3y ago
  > 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.
endisneigh 3y ago
> 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.
- JeanMarcS 3y ago
  > 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.
  - endisneigh 3y ago
    you solve it the same way you do with iOS and Android - an LTS release with careful deprecation of APIs.
  - easton 3y ago
    Microsoft has this on Windows: https://learn.microsoft.com/en-us/microsoft-edge/webview2/ 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).
master-lincoln 3y ago
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, ...)
hxii 3y ago
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.
mozey 3y ago
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.
- J_Shelby_J 3y ago
  Hrmmm I wonder if you could do this on mobile.
  - mozey 3y ago
    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
- deleted 3y ago
  [deleted]
- layer8 3y ago
  It’s more obscure for users if they have to open http://localhost:some_port/ 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.
  - mozey 3y ago
    CORS policy usually requires that the port must match. This issue potentially applies to all web apps, not only those hosted on localhost
coldtea 3y ago
>Web Apps Are Better Than No Apps Yes. Just like stale bread is preferrable to dying of starvation.
bobajeff 3y ago
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.
rubymamis 3y ago
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. [1] https://x.com/mamistvalove/status/1704100506644164859 https://x.com/mamistvalove/status/1704100506644164859
Cthulhu_ 3y ago
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.
synergy20 3y ago
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?
mft_ 3y ago
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?
- foul 3y ago
  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.
- throwawaaarrgh 3y ago
  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.
- muzani 3y ago
  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.
- lopkeny12ko 3y ago
  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.
yreg 3y ago
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.
- gspencley 3y ago
  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.
- ilrwbwrkhv 3y ago
  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.
throwawaaarrgh 3y ago
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.
samyar 3y ago
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.
bikamonki 3y ago
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.
daltont 3y ago
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.
daft_pink 3y ago
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.
epolanski 3y ago
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.
- jwells89 3y ago
  > 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.
  - didntcheck 3y ago
    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
EGreg 3y ago
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?
JohnFen 3y ago
> 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.
kibwen 3y ago
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.
wink 3y ago
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.
- jwells89 3y ago
  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.
butz 3y ago
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?
samtheprogram 3y ago
> 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.
dinkleberg 3y ago
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.
didntcheck 3y ago
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

114 points by _xivi 3y ago

> 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.

croes 3y ago
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
- amelius 3y ago
  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.
quickthrower2 3y ago
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.
- mavhc 3y ago
  iOS apps tend to have back buttons, vs Android's swipe from left side to go back
  - Klonoar 3y ago
    This paradigm isn’t necessarily correct for the modern iOS experience. Many apps I use can be handled with just swiping down or back.
JimDabell 3y ago
> 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.
- nsonha 3y ago
  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.
  - Capricorn2481 3y ago
    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.
    - amelius 3y ago
      The family's tablet can be of a different brand than each family member's phone.
    - joshmanders 3y ago
      Leave tech world and look at what people have. Most iPhone users have Windows machines.
      - amelius 3y ago
        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.
      - Capricorn2481 3y ago

croes 3y ago

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.

master-lincoln 3y ago
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.

gidis_ 3y ago

"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).

esailija 3y ago
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.
sentimentscan 3y ago
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
afavour 3y ago
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.

nottorp 3y ago

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.

nsonha 3y ago
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.
- sanderjd 3y ago
  Web apps don't require constant access to the internet.
  - TeMPOraL 3y ago
    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...
- pjc50 3y ago
  Websites have a code size restriction? What is it?
  - nsonha 3y ago
    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.
nottheengineer 3y ago

nottheengineer 3y ago

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.

HeckFeck 3y ago
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.
- jwells89 3y ago
  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.
mozey 3y ago
> 5 seconds later, the thing I wanted appears Is this an intrinsic attribute of all web apps, or specific to an implementation?
matwood 3y ago
> whenever I use Teams Terrible software can be coded in any language.
- kamray23 3y ago
  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?

imsurajkadam 3y ago

almost all the web apps out there are mobile friendly out there unless they are too much complicated in themselves

phartenfeller 3y ago

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/ https://bun.sh/

lawn 3y ago
> 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.

endisneigh 3y ago

> 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.

JeanMarcS 3y ago
> 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.
- endisneigh 3y ago
  you solve it the same way you do with iOS and Android - an LTS release with careful deprecation of APIs.
- easton 3y ago
  Microsoft has this on Windows: https://learn.microsoft.com/en-us/microsoft-edge/webview2/ 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).

master-lincoln 3y ago

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, ...)

hxii 3y ago

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.

mozey 3y ago

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.

J_Shelby_J 3y ago
Hrmmm I wonder if you could do this on mobile.
- mozey 3y ago
  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
deleted 3y ago
[deleted]
layer8 3y ago
It’s more obscure for users if they have to open http://localhost:some_port/ 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.
- mozey 3y ago
  CORS policy usually requires that the port must match. This issue potentially applies to all web apps, not only those hosted on localhost

coldtea 3y ago

>Web Apps Are Better Than No Apps Yes. Just like stale bread is preferrable to dying of starvation.

bobajeff 3y ago

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.

rubymamis 3y ago

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. [1] https://x.com/mamistvalove/status/1704100506644164859 https://x.com/mamistvalove/status/1704100506644164859

Cthulhu_ 3y ago

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.

synergy20 3y ago

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?

mft_ 3y ago

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?

foul 3y ago
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.
throwawaaarrgh 3y ago
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.
muzani 3y ago
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.
lopkeny12ko 3y ago
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.

yreg 3y ago

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.

gspencley 3y ago
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.
ilrwbwrkhv 3y ago
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.

throwawaaarrgh 3y ago

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.

samyar 3y ago

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.

bikamonki 3y ago

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.

daltont 3y ago

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.

daft_pink 3y ago

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.

epolanski 3y ago

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.

jwells89 3y ago
> 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.
- didntcheck 3y ago
  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

EGreg 3y ago

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?

JohnFen 3y ago

> 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.

kibwen 3y ago

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.

wink 3y ago

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.

jwells89 3y ago
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.

butz 3y ago

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?

samtheprogram 3y ago

> 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.

dinkleberg 3y ago

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.

didntcheck 3y ago

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