Hacker News new | ask | show | jobs
by darby_eight 807 days ago
Why would someone use this for desktop applications if you aren't obligated to target a web browser? The only benefit this brings is access to browser rendering, which is a pretty terrible desktop experience (see e.g. slack, spotify).
3 comments

Portability?

In some situations it is harder to support different desktop builds and this might unify that.

I don't think it is the strongest argument but at least on the margins it is an option I can see teams in some places choosing.

I think this is the strongest argument, but the sticking point is still the interface actually integrating with the OS environment well. Otherwise Java/C# would have taken off as a de-facto portable solution decades ago (and, in fact, this seems to work pretty well for stuff like games where native integration isn't a factor—most of my favorite games these days run on some sort of managed code, and in fact modding would be much more difficult without this).

Granted, at least the browser code uses native widgets, but the look/feel and layout still tend to be way off.

Not sure why you claim it's a "terrible desktop experience"? What's wrong with it, please explain.
I already answered re: slack above, but spotify is just slow, ugly, and doesn't conform to native interface expectations. Granted, this is also largely true of iTunes, but the issue is much less flagrant there.
>ugly, and doesn't conform to native interface expectations

These are not strictly a result of targeting browsers for desktop applications, it's strictly down to design decisions that have nothing to do with how its implemented. I've seen plenty of wonky desktop/native applications that took way too many liberties with design whimsy that end up being a worse user experience than any webpage.

I also can't complain about Slack being slow because it doesn't seem slow to me and I'm part of a very large organization. I also use VS Code which is based on browser tech, and it's working really well. And I love that VS Code also works in the web applications I create. YMMV.

> These are not strictly a result of targeting browsers for desktop applications, it's strictly down to design decisions that have nothing to do with how its implemented.

It's not "strictly" down to this; even if you want to implement interfaces that fit in with native ones, web browsers simply don't expose many native features via the DOM/CSS. It's a question of actual capabilities, not of this hypothetical design process that doesn't care about native integration.

(Of course, there will always be terrible native interfaces. Arguably Apple is the worst offender here!)

>even if you want to implement interfaces that fit in with native ones, web browsers simply don't expose many native features via the DOM/CSS

In an application like VS Code, or anything built on Electron or other similar frameworks, the web browser actually can have access to anything and everything a desktop application has. Electron is a fusion of a Chromium web browser with Nodejs, so you can call Nodejs functions from the browser, and if you really need OS API access, you can also have C++ addons for Nodejs that can do the work and the browser interface can be used to call those functions.

The web browser is simply the user interface, it communicates with a nodejs back-end which can definitely also access OS level APIs if you really want it to.

So yes, the capabilities are there, you just didn't know about them because you think it's simply a web browser, when it's much more than that.

And I know for a fact that you're wrong, because I worked on a desktop application in 2006 that used Internet Explorer as the user interface (Windows was our target, for reasons), and it had a C++ "back end", which was used for burning DVDs (the first legal DVD burning application). The browser could call C++ functions that we chose to expose to the browser to do all sorts of OS-level things. There was nothing that the browser front-end couldn't access at the OS level if we chose to expose it to the front-end. So I know for a fact that you're wrong about your assumptions about desktop applications that use a web browser as the front end.

Native interface expectations are only really a thing on MacOS at this point. I agree that they are often slower, but "ugly" is an opinion, one that I happen to disagree with. Native widgets feel primitive and dated to me.
> Native widgets feel primitive and dated to me.

Have you tried using a different theme?

I use MacOS so I don't think that's possible (unless you mean "dark mode"). But in any case, I am not talking about colors but general fidelity.
> Native widgets feel primitive and dated to me.

Compared to what? I honestly don't know what other people consider state of the art interfaces if native apps are excluded.

Compared to the web. I consider apps like Linear to be ones spearheading UI paradigms at the moment.
That app doesn’t look novel in any way.
Sure, if one is easily satisfied and has low expectations, it's perfectly satisfying!
Slack is terrible? In what sense?
The client was specifically designed for browsing web pages. It has all kinds of features for it. A chat client would be quite different. The file menu would load and save chats. The context menu would have chatty things in it. You have to close the application to lose any application state. We've kinda forgot how nice it is to have a desktop application. 30-35 years ago function keys where cool. I cant remember the last time I've used one. I also cant remember the last time I've used the top menu with alt keys. The browser also has to limit functionality for safety reasons.
How do you rename files?
I mean, it's slow, it uses about ~500x more memory than my irc client does, the interface doesn't meld with the rest of the OS, the options for end-users to actually customize how the app works are direly limited... I'm probably missing gripes but thankfully I haven't had to use it for a couple of years.
It's hard to list all the differences. Say, file association is quite useful.
But you can do file association on the web https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
Slow, memory hog, and incredibly bloated for what it does (not much different to what IM clients did 25 years ago on 1/100 the resources).