Live data from Hacker News

Web apps are better than no apps

molodtsov.me

21–30 of 199 posts

Re: Web apps are better than no apps

#21
post #9

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

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)

Re: Web apps are better than no apps

#22

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 hap…

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.

Re: Web apps are better than no apps

#23
post #9

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

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.

Re: Web apps are better than no apps

#24
post #9

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

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.

Re: Web apps are better than no apps

#25
post #6

"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:…

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.

Re: Web apps are better than no apps

#26
post #6

"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:…

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.

Re: Web apps are better than no apps

#27
post #9

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

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/

Re: Web apps are better than no apps

#28
post #9

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

Re: Web apps are better than no apps

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

Re: Web apps are better than no apps

#30
post #9

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 and 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?

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

Post reply on HN