The web is swallowing the desktop whole (2017) • Hacker News Board

Re: The web is swallowing the desktop whole (2017)

#201

Post by citrin_ru » Thu, Sep 09, 2021, 1:57 PM UTC

anhanhanh wrote: post #197

AnIdiotOnTheNet wrote: post #164

Earlier quoted context omitted.

> If desktops could make a platform where I can write my app in one language, host it on my own server and get global distribution running in a sandboxed environment then I'd consider it. It was called Java and ironically people hated it because it was sluggish and didn't use native widgets. Now we have webapps which reinvent the GUI on almost every site and have built in 100ms+ latencies. Go figure. > The web distri…

> On Windows you could put your binary and libraries in a zip file and distribute to users in any variety of ways, including via web hosting. Would you really do that though? Or would you run a random exe from a random zip hosted from a random website?

If you trust a developer - why not? And if not then an app store model is not a panacea - there are examples of pushing fraudulent/malicious app into them.

Better sandboxing would be welcome, but it coming to desktop slowly (and it typically can only limit damage from a malicious app, but not prevent it fully).

Web-apps come with own security trade-off: infrastructure can have poor security and data can be leaked (and or destroyed) by hackers, a government can request all you data without you knowing about this, your data can be abused by an web-app creator e. g. sold to an Ad targeting company.

Re: The web is swallowing the desktop whole (2017)

#202

Post by golergka » Thu, Sep 09, 2021, 2:07 PM UTC

jiggawatts wrote: post #184

golergka wrote: post #141

Earlier quoted context omitted.

Requests aren't made equal. I don't have an opinion about the manga hosting site, but I have worked on a website where many read requests required a lot of heavy joins other data work for actual useful work and weren't really cacheable, as every used requested his own data. Here's an example: https://cs.fastcup.net/match6279498/stats

Manga hosting is the poster child for slowly-changing, largely read only static content. A bunch of thumbnails and some text, with a basic search function. The site you linked is more interesting. It's the type of thing where the obvious optimisation would be to perform the complex processing in-memory for live games, and then return a single precomputed static document blob for old games. (I assume the match results…

> I assume the match results don't change over time.

In this example of one match they don't, but there's a lot of aggregates that are functions of live data.

Re: The web is swallowing the desktop whole (2017)

#203

Post by AnIdiotOnTheNet » Thu, Sep 09, 2021, 2:25 PM UTC

anhanhanh wrote: post #197

AnIdiotOnTheNet wrote: post #164

Earlier quoted context omitted.

> If desktops could make a platform where I can write my app in one language, host it on my own server and get global distribution running in a sandboxed environment then I'd consider it. It was called Java and ironically people hated it because it was sluggish and didn't use native widgets. Now we have webapps which reinvent the GUI on almost every site and have built in 100ms+ latencies. Go figure. > The web distri…

> On Windows you could put your binary and libraries in a zip file and distribute to users in any variety of ways, including via web hosting. Would you really do that though? Or would you run a random exe from a random zip hosted from a random website?

Literally all the time.

Don't get me wrong, I'd much prefer if Windows had implemented proper application sandboxing.

Re: The web is swallowing the desktop whole (2017)

#204

Post by teleforce » Thu, Sep 09, 2021, 2:29 PM UTC

I have been using desktop applications for more than 30 years and web for more than 20 years now. I loathe web based applications as the next guy but can appreciate the convenient it provides.

As anything in life, it comes like a cycle and and after web it will probably be desktop again with a twist. Most likely a desktop with local-first software paradigm [1]. That will not happen until the two important issues are solved, firstly seamless distributed data replication and security.

The first issue can probably be solved by Commutative Replicated Data Type (CRDT) and/or Operational Transformation (OT) but not merely for editors but also for more general applications [2].

The second security issue could be solved by enabling working seamlessly for offline and online, and it will probably adhere to the zero trust architecture [3]. Personally I'm working on trying to solve on this issue now, and the Global Area Networking (GAN) initiatives for examples ZeroTier and Tailscale are going in the right direction.

[1] https://martin.kleppmann.com/papers/local-first.pdf

[2] https://arxiv.org/abs/1810.02137

[3] https://csrc.nist.gov/publications/detail/sp/800-207/final

Re: The web is swallowing the desktop whole (2017)

#205

Post by jillesvangurp » Thu, Sep 09, 2021, 2:54 PM UTC

ChrisArchitect wrote: post #15

2017? Anything new since then on this you think?

Yes, WASM is happening and slowly creeping into the web. The web five years ago was basically dom trees and javascript. Flash had been marginalized by then. HTML 5 + javascript was basically the only way to do web applications. Now we have web applications like Figma that are part written in C++ that have elements in their UI that are rendered in a canvas. Another one is Miro.

The next big leap here is WASM progressing to the point where e.g. garbage collection work is finished, which will enable a whole range of languages to easily target WASM as well (without having to bring their own GC). For example, Jetbrains announced a few months ago that they are working on a WASM compiler for Kotlin that will rely on this. MS has been targeting WASM as well with blazor. This will likely take another few years to mature.

Other trends are reactive frameworks like jetpack compose and swift UI slowly creeping into the mobile space. Jetbrains is actually working on web and desktop variants of compose. So cross platform UI development might become a lot easier. I expect that there will be multiple reactive frameworks for different languages available for use with wasm in browsers in a few years. Right now, it's mostly C/C++ and frameworks like QT and GTK being used for that. More choice might change a few things.

Re: The web is swallowing the desktop whole (2017)

#206

Post by imbnwa » Thu, Sep 09, 2021, 3:05 PM UTC

TeMPOraL wrote: post #154

mastrsushi wrote: post #53

Earlier quoted context omitted.

I didn’t think of it that way, It’s probably a tug war

Chrome has stellar engineering work done on it. It'd bet it's in the top 10 of the most optimized pieces of software ever . It's because of this work that modern web applications are even possible . The consequence - perhaps unintended - is that the web application practices all settled around extremely wasteful but "fast enough" patterns. It takes extra work and going against the grain to make web applications perfo…

In my experience what you're describing is true. JIRA Scrum is abused by businesses to implicitly blackmail teams into delivering ASAP, that means shortcuts and dependencies to "get shit done". All else is secondary. Tech debt? Put it in the backlog. "Good enough" is king. Every fault attributed to "stupid web devs" is just a projection to mask the true anxiety that the market has deemed expert, artisanal engineering irrelevant to profit and success. A comment above was lauding a fork of an open source electron app for implementing a C++ backend: good luck convincing a business to do that. Microsoft probably does this for VS Code precisely because their demographic are people who profess sensitivity to these types of details, but the broader population is not.

Re: The web is swallowing the desktop whole (2017)

#207

Post by torginus » Thu, Sep 09, 2021, 3:09 PM UTC

_fat_santa wrote: post #194

torginus wrote: post #106

This is a bit of an aside - but can anyone explain why Electron apps use so much memory/system resources? Is this a fundamental thing or accidental thing and could be remedied rather easily? I wonder why there hasn't been significant effort directed toward this, as this is the number 1 issue of desktop applications today. I have a few guesses/questions: - What kind of data is causing the GBs of memory usage? Is it JS…

I might be wrong here so someone correct me but I believe it's because every time you open a new electron app, you are opening another instance of Chrome. So if you have Chrome, VSCode and Figma running, that's 3 instances of Chrome each eating their respective 2-3GB of memory and associated CPU cycles.

You are not wrong, but there are multiple billion dollar companies that build their products on top of Electron. Presumably they could afford to hire engineers or Google could step in and optimize Chrome's renderer for Electron's use cases.

I may be wrong, but as things are now, Electron, more or less packages an unmodified, headless Chromium.

Re: The web is swallowing the desktop whole (2017)

#208

Post by ryandrake » Thu, Sep 09, 2021, 3:24 PM UTC

MontagFTB wrote: post #132

boomlinde wrote: post #127

Earlier quoted context omitted.

I don't get this. I've used GTK, Qt, Tk and FLTK software in OSX, Windows and Linux. The rest is usually covered by standard libraries and third party libraries. So I take it this approach is disqualified on your terms for not being meaningful, which raises the question about what "meaningful" means. My own guess is that it's a matter of convenience of distribution: enter an URL and you can start using the app.

Isn’t it that most software written today has to target the web? So you have two distinct platforms to write to: web, and non-web. Even if Microsoft and Apple came up with a brilliant, singular API, that’s still one more API that has to be coded to. With solutions like Electron, you have a very fast time-to-market with a “desktop” app, and your engineering team only needs to target the web. Customers will only notice…

Why do you have to target the web as a platform if you already have sufficient platform-native support in your application?

Re: The web is swallowing the desktop whole (2017)

#209

Post by MontagFTB » Thu, Sep 09, 2021, 3:41 PM UTC

ryandrake wrote: post #208

MontagFTB wrote: post #132

Earlier quoted context omitted.

Isn’t it that most software written today has to target the web? So you have two distinct platforms to write to: web, and non-web. Even if Microsoft and Apple came up with a brilliant, singular API, that’s still one more API that has to be coded to. With solutions like Electron, you have a very fast time-to-market with a “desktop” app, and your engineering team only needs to target the web. Customers will only notice…

Why do you have to target the web as a platform if you already have sufficient platform-native support in your application?

That's a good question. I can think of a handful of reasons, but I am sure there are more. 1) ease of use. It's much easier to tell a prospective customer a URL than instructions on how to download/install/run a local application (if they even have permission to do so.) 2) Ecosystem. If your customers are generating content that needs searching, sharing, or collaboration, it has to be on the web in some capacity. 3) (Unfortunately) Shiny object syndrome. Browser-based applications have an innate appeal that outmoded desktop applications lack.

Re: The web is swallowing the desktop whole (2017)

#210

Post by ryandrake » Thu, Sep 09, 2021, 3:49 PM UTC

ByteWelder wrote: post #178

refactor_master wrote: post #153

Are there any solid statistics on what “users” demand? This keeps being thrown around: “users want, demand and need native desktop applications”. Who are these users? Under what circumstances do they “want” such things?

I want native apps because I want a native experience: Keyboard shortcuts and UX patterns should be consistent throughout most applications. I'm fine with some exceptions (e.g. video editing, photo editing, etc.), but generally I want consistency. I want native apps because my bought RAM and CPU cycles are precious resources: they shouldn't be treated like a "free for all" by lazy devs. Not every native dev uses thes…

Thank you! I prefer native applications for the same reasons. Whenever we hear advocacy of web apps, it’s always from devs about dev problems. “I don’t have to learn more than one language!” and “Distribution is easier!” and “no AppStore rules!” and “It’s easier to monetize + no sharing revenue with the store vendor!” and “I don’t have to worry about supporting multiple versions floating around!” These are all developer problems, not user’s problems. I think we are shifting to more web based software simply because users really don’t have much pull—they take whatever junk is available.