Live data from Hacker News

The web is swallowing the desktop whole (2017)

char.gd

161–170 of 256 posts

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

#161

There’s nothing wrong with the industry wanting to switch to layout engines for desktop applications. The problem is that this type of runtime environment is still fairly new. Desktop OS’s should have HTML/JS runtime built into the application layer, maybe even deeper. It’s such a dominant user functionality these days. Instead we get a bunch of headless chrome instances. There needs to be an engine that maybe isn’t…

> Desktop OS’s should have HTML/JS runtime built into the application layer, maybe even deeper. It’s such a dominant user functionality these days. They all do but good luck convincing any developer to develop something they have to test in multiple places with different engines when they can just only test in chrome and ship a bloated executable and the problem is negated.

> good luck convincing any developer to develop something they have to test in multiple places with different engines

Ooh, this is such a good point! I am one such developer.

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

#162
post #81

Earlier quoted context omitted.

I don't know how old you are, but at 57 and having been "computing" for 35 years, I'd say that this is wrong, on two levels. 1. C has been the green field language for application for decades. 2. The major obstacle is precisely cross-platform development; without a fairly thick layer to abstract away the OS API/platform, it's very difficult. In addition to those two, there's the detail that lots of development projec…

I'm a developer in my mid 20s with a few friends who are software engineers. None of them worked with C for years. The jobs here are JavaScript, Java, Python, etc.

The modern reality is that most, 99.99%, of all software does not need the performance nor engineering flexibility that is C/C++. couple that with multiple generations of new developers being told "memory management is too hard for your poor little brains" and similar bullshit - nowadays it is rare to find a young developer that is not downright afraid of C/C++. Plus, the greybeard C/C++ guru is not at all helpful in many locations, having been corporate abused for decades at this point...

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

#163

Earlier quoted context omitted.

Microsoft has destroyed the Windows desktop singlehandedly on their own. Since Win8 and “Metro” they moved away from having consistent UI widgets like it was in Windows 2000 or XP but instead made the Windows desktop a Wild West if different UI paradigms. Even the ribbon introduced a new UI paradigm that wasn’t available to third party devs. If even MS themselves doesn’t bother to be consistent then developers certai…

I'm in the same boat. I was asked recently to develop a small custom app for a library that would need to be maintained for decades. This left me scratching my head as to which GUI technology to choose to minimize the danger of it being broken/unsupported after 10 years. Paradoxically, I think Win32 might be the safest choice as MS can't really innovate (=break) too much here anymore (although I might underappreciate…

Emacs Lisp would probably rank even higher.

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

#164

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. The web distribution model is just so much nicer for users and devs. No app stores, no install/uninstall process, no access to system internals. I can deploy an app today and just send a link to my friends for them to use it. It takes…

> 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 distribution model is just so much nicer for users and devs. No app stores, no install/uninstall process, no access to system internals.

No ability to use it at all in an area with shitty network, no consistency, no integration, no respect for OS themes, no ability to continue using old versions if something is wrong with the new one...

> I can deploy an app today and just send a link to my friends for them to use it. It takes a day just to put together an app store submission with all the necessary screenshots and configuration, not to mention the lengthy review process which could then deny me permission to launch.

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. Macs could do the same thing with Application Bundles or their single-file applications before that.

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

#165

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…

As I understand it, the chrome team have tended towards using more memory as a way of improving performance (i.e. trading space for time), with the feeling being that most systems have quite a lot of memory (relatively speaking) so why not use it.

This isn't a one off thing so would be challenging to change. It's more a case of many small decisions about increasing memory usage that in aggregate add up.

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

#166

While I tend to agree that Electron is going to be more and more relevant, I'd like to counter-argument that native apps these days are accompanied by powerful vendor services. For example, if you target the Apple ecosystem you get CloudKit and can deploy syncing between devices very easily and translating operational infrastructure costs to the user. Need crypto? You have CryptoKit, and so on. What this means: any a…

You can always extend Electron apps with platform-native capabilities. Things like Neon [1], a wrapper for writing node bindings in Rust, make this particularly convenient. You can then use Rust to call into platform native APIs. It's more work, but you can still benefit from cross platform UI development and augment it with native code where appropriate. [1] https://github.com/neon-bindings/neon

So now you get all the bloat of a bundled web browser and the completely-non-native GUI of a website plus the all the security of a native application?

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

#167
post #38

Earlier quoted context omitted.

> everything other the browser and the text editor is now a web app video editing, DAWs, music notation, CAD/CAM, 3D modelling (think Blender), compilers, linkers, IDE's other than VSCode, local photo management, media players, messaging services (telegram etc), device management ... these and many more called and laughed at your claim.

IIRC you can use fusion 360 in the browser now? WhatsApp is of course available on the web. I'm a regular user of play.spotify.com, works great. Figma is a great design tool available only on the web. I do get your point, but there are more and more things moving to the web as more and more standards are being published (if you think this is a good idea is another discussion). Modern html and CSS is by far the least…

Wow, if modern html and CSS is the least complex GUI framework you've used, you need some exposure. That combo is uber-complex, and the tool sets are college degrees all by themselves. It is a flat out joke how the developers of today have added complexity everywhere they could.

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

#168

It is exactly the failure of Microsoft and Apple to propose any meaningful cross-platform API. Both are fighting to increase vendor lock-in - it is in their best interests that apps written on Windows don't work on macOS/iOS and the other way round. Linux/OS folks themselves are unable to solve this problem on their own and it becomes a mouse-and-cat game. The popularity of web apps helped to reduce the problem, but…

Apple shipped X11. It’s really just Microsoft.

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

#169

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.

None of those UI libs work on Android or iOS.

I think that's a huge part of it. Most of the users nowadays are using smartphones and tablets.

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

#170
post #165

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…

As I understand it, the chrome team have tended towards using more memory as a way of improving performance (i.e. trading space for time), with the feeling being that most systems have quite a lot of memory (relatively speaking) so why not use it. This isn't a one off thing so would be challenging to change. It's more a case of many small decisions about increasing memory usage that in aggregate add up.

Tk and gtk2 apps were performant and used way less memory so that doesn’t seem like it should be necessary.
Post reply on HN