5 ms·

The web has become truly awful and it’s invading desktop apps. We need to refactor our technology stack.

by fermienrico 6y ago

andai 6y ago
Today I installed an Electron-based terminal emulator and started seriously questioning my life choices.
- fermienrico 6y ago
  I have the opinion that UI should not be async - meaning if there is some processing going on, UI elements should be disabled from interaction until the function returns. If it is a web query, I think that's fine. When applications start adding queues and jobs, UI feels "springy" instead of "snappy". User is waiting for some feedback of how long something is going to take, instead the user assumes that job is done (due to lack of feedback) and tries something next - this action is now in the queue. And then user waits... wait... and all of a sudden all queued processes return. This is not human centric design.
  - iainmerrick 6y ago
    Yes! Obviously long-running operations should be asynchronous, but the assumption that all operations should be treated as long-running is wrong. Specifically, typing feedback and button feedback should be synchronous, and should be done directly in the UI loop. I understand the rationale for going async -- you can never be sure exactly how long anything will take, and invisible things like memory management and caching can blow up your runtime; and if you get synchronous operations wrong, that leads to spinning beach ball cursors and “app not responding” errors, which are even worse than lag. But in that scenario, an async app isn’t going to perform any more usefully, you’ll just get a blank or frozen screen instead of a beach ball.
  - deleted 6y ago
    [deleted]
AgentME 6y ago
Most native apps I've downloaded are well into tens or hundreds megabytes. I just tried a few big popular sites with caching off and none of them downloaded more than a couple megabytes of javascript. I'm really skeptical of the popular wisdom around here that web dev is doing something especially egregious when it comes to build sizes or dependencies.
- NateEag 6y ago
  The browser is where the hundreds of megabytes vanish to when you use a JS app instead of a native one. That might still be better (I'm undecided, personally), but it's worth recognizing that heavy native app is still there, just shared with a lot of other JS apps.
  - Drew_ 6y ago
    You could say the same about system libraries/binaries every native app needs to run
    - choward 6y ago
      Native apps can share libraries at run time. I'm no electron expert but I'm assuming electron apps only can share dependencies at build time at which point they would be copied into the executable so they really wouldn't be sharing.
    - NateEag 6y ago
      Valid point, for sure.
- deleted 6y ago
  [deleted]
- danieldk 6y ago
  Slack: usually ~300MiB of RAM for one account. The Ripcord [1] Slack/Discord client written in C++ and Qt: currently using 33MiB. Qt is not the native toolkit on Windows/Mac, but Qt apps typically follow platform conventions far better than Electron apps. This also voids the argument "we need Electron, because it reduces development costs, and we can get truly cross-platform apps". Ripcord is written by a single indie developer and runs on Windows, Mac, and Linux. Imagine what could be done if Slack employed a team with 10 Qt developers. Most web apps are egregious. The problem is that there is a whole generation that is not exposed to Delphi or Qt Designer and have the false believe that developing web apps is an order of magnitude easier. It's only an order or magnitude easier for them, because web tech is the only thing they know. Heck, I was writing GUI apps as a 12y/o with Delphi. [1] https://cancel.fm/ripcord/ https://cancel.fm/ripcord/
scarlac 6y ago
It's worth mentioning that apart from Javascript, there is nothing 'web' about React Native. To put it simply: You use Javascript to control native components. Electron and React Native are wildly different. React Native is set up to look like web development, but it is not. It makes it easier to get started, but over time you'll have to appreciate the native platform underneath.

The web has become truly awful and it’s invading desktop apps. We need to refactor our technology stack.

andai 6y ago

Today I installed an Electron-based terminal emulator and started seriously questioning my life choices.

fermienrico 6y ago
I have the opinion that UI should not be async - meaning if there is some processing going on, UI elements should be disabled from interaction until the function returns. If it is a web query, I think that's fine. When applications start adding queues and jobs, UI feels "springy" instead of "snappy". User is waiting for some feedback of how long something is going to take, instead the user assumes that job is done (due to lack of feedback) and tries something next - this action is now in the queue. And then user waits... wait... and all of a sudden all queued processes return. This is not human centric design.
- iainmerrick 6y ago
  Yes! Obviously long-running operations should be asynchronous, but the assumption that all operations should be treated as long-running is wrong. Specifically, typing feedback and button feedback should be synchronous, and should be done directly in the UI loop. I understand the rationale for going async -- you can never be sure exactly how long anything will take, and invisible things like memory management and caching can blow up your runtime; and if you get synchronous operations wrong, that leads to spinning beach ball cursors and “app not responding” errors, which are even worse than lag. But in that scenario, an async app isn’t going to perform any more usefully, you’ll just get a blank or frozen screen instead of a beach ball.
- deleted 6y ago
  [deleted]

AgentME 6y ago

Most native apps I've downloaded are well into tens or hundreds megabytes. I just tried a few big popular sites with caching off and none of them downloaded more than a couple megabytes of javascript. I'm really skeptical of the popular wisdom around here that web dev is doing something especially egregious when it comes to build sizes or dependencies.

NateEag 6y ago
The browser is where the hundreds of megabytes vanish to when you use a JS app instead of a native one. That might still be better (I'm undecided, personally), but it's worth recognizing that heavy native app is still there, just shared with a lot of other JS apps.
- Drew_ 6y ago
  You could say the same about system libraries/binaries every native app needs to run
  - choward 6y ago
    Native apps can share libraries at run time. I'm no electron expert but I'm assuming electron apps only can share dependencies at build time at which point they would be copied into the executable so they really wouldn't be sharing.
  - NateEag 6y ago
    Valid point, for sure.
deleted 6y ago
[deleted]
danieldk 6y ago
Slack: usually ~300MiB of RAM for one account. The Ripcord [1] Slack/Discord client written in C++ and Qt: currently using 33MiB. Qt is not the native toolkit on Windows/Mac, but Qt apps typically follow platform conventions far better than Electron apps. This also voids the argument "we need Electron, because it reduces development costs, and we can get truly cross-platform apps". Ripcord is written by a single indie developer and runs on Windows, Mac, and Linux. Imagine what could be done if Slack employed a team with 10 Qt developers. Most web apps are egregious. The problem is that there is a whole generation that is not exposed to Delphi or Qt Designer and have the false believe that developing web apps is an order of magnitude easier. It's only an order or magnitude easier for them, because web tech is the only thing they know. Heck, I was writing GUI apps as a 12y/o with Delphi. [1] https://cancel.fm/ripcord/ https://cancel.fm/ripcord/

scarlac 6y ago

It's worth mentioning that apart from Javascript, there is nothing 'web' about React Native. To put it simply: You use Javascript to control native components. Electron and React Native are wildly different. React Native is set up to look like web development, but it is not. It makes it easier to get started, but over time you'll have to appreciate the native platform underneath.