Hacker News Reader

Comment by meetups323 | Hacker News Reader

Usually they are websites. That's kinda the whole point... Spotify's desktop app is the same as open.spotify.com, Discord's is the same as discord.com, VS Code's is the same as vscode.dev, Slack is the same as.. something. But yeah, instead of those companies all needing 5 separate engineering teams (Web, Mac, Windows, iOS, Android, and you're joking if you think they'll make a Linux native app), they just make a website. You're welcome to use the websites instead of the desktop apps for any of those, though you'll lose some OS integration capability.

View on HN

I think it's a huge pity that we're so reliant on platforms instead of protocols - there would be native Slack clients for every platform. Few companies even allow proper API access.

Spotify buck the trend, Spot is a fantastic app

https://github.com/xou816/spot

Even Spotify don't make it easy. The librespot library is a rewrite of libspot, which Spotify deprecated.

Small companies loves protocols, but as they become big and dominant they start pivoting to platforms to exert control and extract more profits from the ecosystem.

We need regulations around platforms, protocols are inherently more powerful and from the perspective of humanity almost always preferable over platforms, so the incentives of companies should reflect that, but it isn't right now.

Stuff like email, http etc is what makes computers great. I doubt anything like that could get invented today, companies would just create their own proprietary protocols and there would be no web browsers. Imagine if we just continued along that route and made protocols for everything instead of having big companies lock down computing habits via platforms.

web 3.0, anyone?

There are tradeoffs beyond just the company making more money, as Moxie's recent web3 assessment covered. Protocols take much longer to evolve, platforms are quick to evolve.

Allowing platforms to innovate but somehow incentivizingnor requiring opening up what they've built seems like it would be the best of both worlds, but I'm not sure how that could be done well.

If people actually paid for usage, that would be one thing, because then it would be all about getting people to use your platform so you made more money, and having others innovate on too of it that you could fold into it would be cost effective. In the world of free APIs and services, it's all about keeping control of every bit.

Maybe all it needs is a nudge to make the decision to hoard all data no longer worth while. Make companies liable for PII that's lost and make someone's PII their own property only to be used with their agreement and maybe the rest will start to fall out of it.

The UK open banking regulations are a good model to follow.

The problem is the intersection of extreme profits at stake and the public's lack of understanding of the underlying causes. That's not a recipe for good political outcomes.

In the case of the UK open banking regulations I suspect tech lobbying (powerful) might have trumped high street bank lobbying (not as powerful).

The last thing I want is gov regulations by even more out-of-touch regulators than the people they’re regulating.

Standards are good. IETF is the reason for some sanity in IT.

> Stuff like email, http etc is what makes computers great.

I concur with this. I've gotten into IRC recently, and have started reading RFC's/specs for various protocols instead of ducking "How to do X", and it's both greatly increased my enjoyment of computing, and my knowledge.

Crazy idea that I'm sure isn't an original thought: instead of adapting the languages to deal with abstracting the idiosyncrasies of each OS, change the OSes to expose a universal API to make everything else lighter.

I guess that's also kinda Docker or QEMU or V8, but also https://github.com/solo-io/unik if you think about it differently.

In other words: hey, Lisp Machines were an excellent idea back then, but they still are. Maybe someday we'll have a V8 co-processor. More fun reading: https://lobste.rs/s/2poahh/what_i_could_not_undiscover_about

Cross platform 'windowing toolkit' APIs are what's missing. At this point I'd be happy even if Microsoft, Apple, and UNIX likes (who would probably just implement any free open standard anyway) could agree on even ONE such interface.

Postscript as a UI language? Fine as long as they all do it.

HTML5+ as a UI language? (E.G. like the failed HP Fire or Firefox) Fine as long as they all do it.

Some new thing that isn't a complete dumpster-fire but is included everywhere and a free for anyone to implement interface? Fine as long as they all do it.

We have NO shortage of programming languages that can be cross compiled to different operating systems. Filesystem differences can be annoying but you can work around those. Entirely different user interaction paths? That's the sticking point.

That would be ideal, but there are huge differences between the window implementations on different platforms.

One really obvious example (maybe no longer current - it's been a while since I spent any time on Windows) is that OS X windows are responsive even without focus. So you can scroll around background windows just by hovering without having to click first. Windows doesn't support this.

The bigger problem is that the data structures for menus, chrome, and the rest are completely different. An OS X menu is nothing like a Windows menu is nothing like a Linux menu.

There are systems like Tcl/Tk and Qt which act as middleware between GUI descriptions and specific OS bindings, and they kind of work. But they force devs to learn a separate intermediate language and (IMO) they look crude compared to real native apps.

Of course there are also business reasons why GUI convergence won't happen.

Just an FYI your scrolling example is indeed no longer current (or least not with Windows 10).

Scrolling non-focused windows works just fine (ex. can type text into notepad while simultaneously scrolling a browser window).

If those don't go altogether stagnant then usually what happens is there are a bunch of features that only work in the "official" implementation so it's a degraded experience anyway.

I'm kinda hopeful that Maui+Blazor will eventually let us have our cake and eat it too - instead of "everything is web", do "everything is a desktop-style gui framework" including the web. Although AFAIK they don't even have a web renderer on the horizon right now - purely desktop+mobile.

Of course, there will be angry PMs and designers that will be upset that their website looks like it was spat out of a desktop GUI framework instead of looking exactly how they want it to look. I remember people whining about how desktop-looking ExtJS was back in the day... this was for an inventory-management application, shouldn't it look like a desktop productivity app?

Should it not be possible to style a native GUI application with the same framework language as for a website?

> Should it not be possible to style a native GUI application with the same framework language as for a website?

Not if the native controls are strongly opinionated as to style language, such that there is limited themability, unless you go to the level that your “native GUI” is doing the equivalent of drawing and reading mouse touches from a canvas to implement a custom UI rather than using more specific native controls.

Isn't that basically what Flutter does? In my experience, it works well enough for mobile, although you still have people saying it's not "native enough." It's less stable on web and desktop though but it works.

Flutter on web is basically unusable for anything that involves text or links. The browser has so much native functionality here that trying to reimplement it is futile.

> You're welcome to use the websites instead of the desktop apps for any of those, though you'll lose some OS integration capability.

On the flip side, when you use them as websites, you gain the benefit of extending them through browser add-ons and extensions. An example where I work is that everyone uses Asana’s website because our Everhour extension works in Chrome but there’s no equivalent for Asana’s desktop app.

This gave me the idea to use uBlock Origin to hide Spotify's "Episodes for you" section... a simple `open.spotify.com##section[aria-label="Episodes for you"]` and I don't have to deal with their spam ever again!

Update: block list has since grown to:

    open.spotify.com##section[aria-label="Episodes for you"]
    open.spotify.com##section[aria-label="Shows you might like"]
    open.spotify.com##section[aria-label="Shows to try"]
    open.spotify.com##section[aria-label="Funny LGBTQ+ Podcasters"]

This may not end up being the cakewalk I was expecting.

Spotify Desktop is kinda different from the website because of how it uses APIs locally to control things https://engineering.atspotify.com/2021/04/07/building-the-fu...

VSCode is also appreciably different both in capability and implementation, https://franz-ajit.medium.com/understanding-visual-studio-co... but interesting that V8 debug protocol is becoming more common, so maybe that will come to a browser some day :)

Slack isn't feature complete in their webapp if they even still have it. vscode.dev is new, the app existed for a long time. In practice, its the reverse; it allows you to turn an app into a website and add yet another supported platform.

> Slack isn't feature complete in their webapp if they even still have it.

It isn't? I use it daily and haven't noticed anything missing, except that voice calls don't work on Firefox, which is fine, because I never use them.

It isn't, except it is. lol.

Actually the newest Firefox ships with a user-agent override for slack so that voice calls work now.

But same, I haven't noticed any missing features from the web version.

This is something I think many HN'ers don't understand. For a good amount of modern web functionality, being supported in Firefox is less a matter of "do testing in firefox and make sure things work there" as much as it is "have a very popular product and good marketing team so that you can convince the firefox team to whitelist your domain in their internal maps of `what cool things should X domain be allowed to do`". People see that Slack works in Firefox, but Joe's Voice Calls.Com doesn't, and blame Joe for not supporting firefox. In reality it's firefox that doesn't support Joe.

You misunderstand, you have the situation exactly backwards. The problem isn't that Firefox doesn't support these APIs, it does support them and the problem isn't that they are limited to specific domains, they aren't. The problem is that the Slack code is `if isChrome() { enableCalls() }`. Mozilla has to spoof the user-agent to bypass this check. Joe's Voice Calls.com will just do no conditional or do feature-detection rather than user-agent checks and everything will work fine.

The exception is the list of domains that allow auto-play video with sound by default (like YouTube) but I think there are very few instances of this.

Ah, indeed I misunderstood. Though to be fair, at $DAY_JOB we had to do exactly the process I described above to access some API (not auto-play) without a litany of obnoxious prompts. If anyone at a smaller company tried to do what we were doing, they'd be 100% unable to provide a usable experience for Firefox users.

Reply on news.ycombinator.com