Live data from Hacker News

Web apps are better than no apps

molodtsov.me

191–199 of 199 posts

Re: Web apps are better than no apps

#191
post #155

Earlier quoted context omitted.

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

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.

Re: Web apps are better than no apps

#192
post #54

Earlier quoted context omitted.

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

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

[deleted]

Re: Web apps are better than no apps

#193

Earlier quoted context omitted.

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

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

[deleted]

Re: Web apps are better than no apps

#194

Earlier quoted context omitted.

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.

Re: Web apps are better than no apps

#195

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

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

[deleted]

Re: Web apps are better than no apps

#196

Earlier quoted context omitted.

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.

[deleted]

Re: Web apps are better than no apps

#197
post #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 int…

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

Re: Web apps are better than no apps

#198
post #194

Earlier quoted context omitted.

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

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.

Re: Web apps are better than no apps

#199

Earlier quoted context omitted.

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…

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.
Post reply on HN