3 ms·

> While the software isn't as snappy as it theoretically could be, that is mostly because the market finds the tradeoff between features and speed. I don't kno

> While the software isn't as snappy as it theoretically could be, that is mostly because the market finds the tradeoff between features and speed. I don't know how much the market really has a say in this. I don't use Slack because I want to. I use it because I must. When we had open protocols, you really could choose the best client. Nowadays everything is a walled garden. It's amazing just how poorly we've managed to make a chat application run. Across the board companies are using JS-based apps not because it necessarily leads to a better user experience but because it reduces their costs. Running a couple might be fine. Running more than that really slows things down. And developers tend to forget that most of the world isn't running a machine with the specs that they run with and many don't bother testing their stuff on machines with more limited resources. I routinely have to kill applications when trying to build software or pair program because our video conferencing tools aren't light on resources either. I can't just add more RAM to my laptop because everything is soldered on now. That's another big difference from the past couple of decades. People could cheaply upgrade their hardware every couple of years. Now, you have to buy a brand new device, so people naturally hold on to their hardware longer. Mobile phone users are hanging on to their devices longer. Just yesterday we saw news that GitHub employees can only refresh laptops every four years. We should be working to make more efficient use of resources instead of targeting everything at the latest hardware specs. Obviously there was old, bloated software. I think most of what people remember as being slow had a lot to do with spinning disks. I upgraded a family member's computer to something more modern not too long ago. He's pretty set in his ways and still uses old versions of MS Money and the like. It was amazing how much faster they ran. I can't know for certain, but I don't see that sort of future for JS apps. They're slow on considerably more advanced hardware. While more memory would help, more CPU cores likely won't. I wish performance would be taken more seriously in the UX world. But, it costs less to cut corners and when you have a captive market, who cares? Once one company starts doing it, others do too, making it a race to the bottom. I'm thankful there are still indie developers building high quality, platform-native applications.

anthk 4y ago
Kopete did the same Slack does today (with inline Youtube videos and LaTeX equations) with KDE3 running in the background under a machine with 256MB of RAM.
dalmo3 4y ago
> I don't know how much the market really has a say in this. (...) companies are using JS-based apps not because it necessarily leads to a better user experience but because it reduces their costs. That's quite literally the market having a say.
- nirvdrum 4y ago
  I'm sorry, I did phrase "companies are using JS-based apps" poorly. I meant it to mean that software vendors were delivering JS-based apps. That "(...)" you used is pulling a lot of weight. You deleted all the other context I had and stitched together two paragraphs. The explosion of JS apps is a cost saving measure for vendors that given real choice, I don't think many consumers would opt for. The point is once you have lock-in and network effects, your customers don't really have much of a choice in the matter. At the very least, you can't say that's the market speaking in favor of the substandard apps any more than you can say it's the market speaking for any other choice the vendor makes. As a related example, I'm sure people that were using 3rd party Twitter clients aren't feeling like the market has spoken and the best app has won just because Twitter killed off their API access. Their choice to stay on the platform has nothing to do with the their new-found love of the official apps.
  - fulafel 4y ago
    JS apps have bounded the crappiness at the bottom end of SW competence. For example MS Teams can now be run in a browser tab where the bad stuff it can do (on purpose or thru security holes) is bounded by the sandbox and it works on Linux, unlike predecessors.
    - nirvdrum 4y ago
      The security sandbox is a fair point. Although, embedding a web browser brings in a whole lot of extra surface area so you need to update regularly to stay secure. Electron's defaults have historically favored developer-friendliness over security and require a level of diligence from the app developer, as well. It's gotten better, for sure. The Linux point is interesting. I have a Linux workstation I use regularly (in addition to a macOS laptop) and sometimes the desktop integration is nice to have. I just also struggle to believe a company worth 10s of billions building tools for software developers couldn't solve the problem in any other way. It feels a bit like we let companies off the hook. Whatever misgivings people have about the UI consistency, we have plenty of Linux desktop software that runs well and developed on far smaller budgets. I could live with resource-hogging vendor software if there were open protocols or APIs in place to supplant with something of my own.

anthk 4y ago

Kopete did the same Slack does today (with inline Youtube videos and LaTeX equations) with KDE3 running in the background under a machine with 256MB of RAM.

dalmo3 4y ago

> I don't know how much the market really has a say in this. (...) companies are using JS-based apps not because it necessarily leads to a better user experience but because it reduces their costs. That's quite literally the market having a say.

nirvdrum 4y ago
I'm sorry, I did phrase "companies are using JS-based apps" poorly. I meant it to mean that software vendors were delivering JS-based apps. That "(...)" you used is pulling a lot of weight. You deleted all the other context I had and stitched together two paragraphs. The explosion of JS apps is a cost saving measure for vendors that given real choice, I don't think many consumers would opt for. The point is once you have lock-in and network effects, your customers don't really have much of a choice in the matter. At the very least, you can't say that's the market speaking in favor of the substandard apps any more than you can say it's the market speaking for any other choice the vendor makes. As a related example, I'm sure people that were using 3rd party Twitter clients aren't feeling like the market has spoken and the best app has won just because Twitter killed off their API access. Their choice to stay on the platform has nothing to do with the their new-found love of the official apps.
- fulafel 4y ago
  JS apps have bounded the crappiness at the bottom end of SW competence. For example MS Teams can now be run in a browser tab where the bad stuff it can do (on purpose or thru security holes) is bounded by the sandbox and it works on Linux, unlike predecessors.
  - nirvdrum 4y ago
    The security sandbox is a fair point. Although, embedding a web browser brings in a whole lot of extra surface area so you need to update regularly to stay secure. Electron's defaults have historically favored developer-friendliness over security and require a level of diligence from the app developer, as well. It's gotten better, for sure. The Linux point is interesting. I have a Linux workstation I use regularly (in addition to a macOS laptop) and sometimes the desktop integration is nice to have. I just also struggle to believe a company worth 10s of billions building tools for software developers couldn't solve the problem in any other way. It feels a bit like we let companies off the hook. Whatever misgivings people have about the UI consistency, we have plenty of Linux desktop software that runs well and developed on far smaller budgets. I could live with resource-hogging vendor software if there were open protocols or APIs in place to supplant with something of my own.