6 ms·

The real reason in vast majority of cases, why most of our software seems slow is not because someone used Javascript instead of Win32 C or something else progr

by la12 7y ago

The real reason in vast majority of cases, why most of our software seems slow is not because someone used Javascript instead of Win32 C or something else programming language related. The real driver of slowness are the network requests for everything. You could build your software in assembly but if each action has to hit a rest endpoint, the network request will utterly dwarf anything else happening locally. So as more and more software moves to browser as web-apps this slowness is unavoidable. Consider how more quicker and responsive Thunderbird feels to using gmail, a web-app.

tluyben2 7y ago
Well, let’s take one of the problem apps; Slack. It is slow because it eats a lot of memory and makes my computer slow. You are right that networking makes apps slow, but not to the point they feel slow now. If I have a background thread getting Slack messages and nothing came in, why is the entire thing slow as molasses? I know most apps/applications simply do 1-1 page to web api req and if the web api req is slow they give up (usually with some stupid message that they cannot connect / reconnect) but why would that be slow; you can do that blistering fast with win32. And yet my Slack is usually stuck and sluggish? There is a lot of laziness going on: not such an easy relationship between slow web and frontend as you describe. Most apps can work fine with stale data for most uses; they just do not because then the developer has to think about it and that costs money/time and takes talent.
- mushufasa 7y ago
  Slack just fixed this. Try updating: https://slack.engineering/rebuilding-slack-on-the-desktop-308d6fe94ae4 https://slack.engineering/rebuilding-slack-on-the-desktop-30... Slack originally designed the app for one workspace. As users grew the expectations for multiple workspaces, they retrofitted by spawning a new thread for each workspace. eThey consciously traded off tech debt for growth. Now they've grown, they have invested resources to pay off the debt. And everything is one thread again.
- WillYouFinish 7y ago
  Slack is a great example. My first thought was Jira. It’s a great software for functionality, but it’s so unbelievably slow that I tend not to use it at all. We have a quite powerful server for Jira and just five users. It should work out fine, but I encountered waiting times of a minute to just load the start screen. It feels like running all the time and as soon as you need to do something in Jira you’re trapped in quicksand.
  - tluyben2 7y ago
    Jira, also Youtrack... Why are these systems so slow :( They had almost two decades to optimize.
gmueckl 7y ago
Well, if your problem is the network stack, then don't use it. My word processor doesn't need to be Frankenstein's monster with parts running in my totally abused hypertext viewer and others running on some servers distributed across half the globe where most of the work their are performing is making sure that they are talking to each other properly. Same goes for almost everything else that is a totally ridiculous "browser-based" abomination. OK, let's turn this into less of a rant: if you can do things in a native desktop app, you're almost always better off than with a browser based solution. If you need networking, then you need to put up with latency and throughput. Thay is just unavoidable. What is avoidable is the overhead of unsuitable protcols. HTTP is perfect for one-off stateless requests for documents from a remote server. That is the whole point. But people crammed haphazard session tracking into it (cookies) and wonky authentication, then decided that having open sessions on the server is not something you do and layered an extra layer of statelessness on top of that while all the conplex browser based applications out there are actually incredibly stateful on the client and server. A native client that uses a custom tailor-made stateful protocol to talk to a server that also keeps session state would be much faster and more efficient than the shaky Jenga tower of compoments that are cobbled together to form the current generation of browser based software.
- la12 7y ago
  > if you can do things in a native desktop app, you're almost always better off than with a browser based solution The reason fewer and fewer people are doing this are more to do with funding. So if I were to build software today, I'd instantly go with web-apps so that I can monetize them as much as I want. Web app software has zero issues with piracy and in built regular cash flow model which everyone wants. Find a way to fund desktop apps and make them as easy to build like web apps and they'll be vogue again.
  - TeMPOraL 7y ago
    In other words: companies and individual developers alike prioritize their business needs over providing value to the users. I could stomach this excuse if people were at least honest about it. And still, it's not applicable everywhere. E.g. if you're targeting business customers, the ones that can afford to pay you are also the ones that would be in deep trouble with the regulators if they pirated your software. But that's just part of the problem. Unfortunately, with business customers, another big reason against desktop applications is that they can trivially work around the increasingly arcane and arguably bullshit approval and security policies corporations tend to have around installing new software. Though that seems to be changing; I've recently heard of companies using deep packet inspection to apply similar policies to SaaS webapps.
asark 7y ago
> The real reason in vast majority of cases, why most of our software seems slow is not because someone used Javascript instead of Win32 C or something else programming language related. On the PS3, I bought way less stuff in their store than I might have otherwise, because it was so damn slow, crashed so much (out of memory, felt like, but might have been something else), lost state all the time, and so on. It definitely felt like they were using a web view of some kind, probably with scripting enabled and in use, not just HTML+CSS for layouts & formatting or something. I'm sure that made publishing and adding rich content features ("just have a JS dev do it!") convenient. It also cut the amount of stuff I bought on there by at least half. There's no way I was alone in that—it was so, so bad. Even on the much faster PS4 their store's unpleasant, though—barely, for now, until they bloat it with more JS as we approach the PS5—usable. [EDIT] point being it wasn't the network requests ruining everything in that case, it was memory and processor hogging webtech on a machine that couldn't handle it yet should never have felt slow, going by specs, unless someone'd screwed up bigtime (say, by putting webtech on it).
- gmueckl 7y ago
  The PS3 should be bored out of its mind running a shop front consisting of a few text labels and images. It is a kind of machine where one would think that it takes deliberate effort to write a simple UI that is actually slow.
- zapzupnz 7y ago
  Funny thing is the Wii U, which was still less powerful than the PS3, has a delightful shop. It wasn’t necessarily fast, but it didn’t shit itself loading a JPEG — AND has charming music and animations!
eps 7y ago
Point is valid, but that's not the real reason in "the vast majority of cases." The context here is that of the desktop software and the vast majority of desktop software is still not networked at its core. It is slow exactly because programmers used extra blubber layers to simplify their life, not because of the network API latency.
- mankeysee 7y ago
  >used extra blubber layers to simplify their life "simplify" lmao Or rather to create an artificial market and justify their pay. More deeply, it is a symptom of our economic system that forces to do such things for having a living.
GuB-42 7y ago
The network stack by itself is incredibly fast. I am talking about the Linux TCP/IP stack here, but I suppose that other vendors do just as well if not better. I wrote a simple web server in C and I was impressed by how tight my code had to be to reach the limits of the OS. Even the internet is fast. Just look at fighting games. The simple fact they are playable over the internet is quite a feat. Fighting games require reaction times at the limit of what humans are capable of, and some moves require a 1/60s accuracy. The problem is that there are so many layers of abstraction. You have the OS, JS engine, layout engine, frameworks, etc... Networking is just one of the layers.
Splines 7y ago
I'd say that disk comes a close second, if not first. Overtaxed slow disks with low memory makes for a terrible desktop experience. Once your memory usage climbs and your OS starts paging/swapping things to disk, seemingly trivial operations that page in new code will take forever.
- mankeysee 7y ago
  Point is, most normal computer usage absolutely should NOT require a 10TB SSD and 256GB ram. It didn't for providing the same/more functionality a few years ago, why does it suddenly require these days?
  - la12 7y ago
    Because a web-app is the only way you can monetize a desktop app like functionality in 2019. Linux desktop toolkits and dev environment utterly sucks. You'll have to develop 3 different codebases for Win, Mac and Linux. Worse still, you'll have to reinvent app updates technology if you go with Qt or will be tied into a different updating technology and still have to deal with piracy problems. Or you could go with web-apps: -> Easy to develop code -> Can't be pirated -> In built model of regular payments -> One codebase for all platforms It's not even a close fight.
mankeysee 7y ago
More importantly spending 99% of the time on self-inflicted non-problems that come with using the web as application platform. For example that anyone can open any url anytime...that alone leads to so many problems related to security (user isn't supposed to be able to see/edit/etc this part) and flow (this page shouldn't be visited before filling a form in this other page, and or if we randomly visit there it would error out crazy, what if user deletes their session, what if network is lost which can happen literally any time in the applications life etc) and then of course theres the matter of anything that would be a trip to ram/local hard disk becomes a networked trip to a distant server.

by la12 7y ago

tluyben2 7y ago

Well, let’s take one of the problem apps; Slack. It is slow because it eats a lot of memory and makes my computer slow. You are right that networking makes apps slow, but not to the point they feel slow now. If I have a background thread getting Slack messages and nothing came in, why is the entire thing slow as molasses? I know most apps/applications simply do 1-1 page to web api req and if the web api req is slow they give up (usually with some stupid message that they cannot connect / reconnect) but why would that be slow; you can do that blistering fast with win32. And yet my Slack is usually stuck and sluggish? There is a lot of laziness going on: not such an easy relationship between slow web and frontend as you describe. Most apps can work fine with stale data for most uses; they just do not because then the developer has to think about it and that costs money/time and takes talent.

mushufasa 7y ago
Slack just fixed this. Try updating: https://slack.engineering/rebuilding-slack-on-the-desktop-308d6fe94ae4 https://slack.engineering/rebuilding-slack-on-the-desktop-30... Slack originally designed the app for one workspace. As users grew the expectations for multiple workspaces, they retrofitted by spawning a new thread for each workspace. eThey consciously traded off tech debt for growth. Now they've grown, they have invested resources to pay off the debt. And everything is one thread again.
WillYouFinish 7y ago
Slack is a great example. My first thought was Jira. It’s a great software for functionality, but it’s so unbelievably slow that I tend not to use it at all. We have a quite powerful server for Jira and just five users. It should work out fine, but I encountered waiting times of a minute to just load the start screen. It feels like running all the time and as soon as you need to do something in Jira you’re trapped in quicksand.
- tluyben2 7y ago
  Jira, also Youtrack... Why are these systems so slow :( They had almost two decades to optimize.

gmueckl 7y ago

Well, if your problem is the network stack, then don't use it. My word processor doesn't need to be Frankenstein's monster with parts running in my totally abused hypertext viewer and others running on some servers distributed across half the globe where most of the work their are performing is making sure that they are talking to each other properly. Same goes for almost everything else that is a totally ridiculous "browser-based" abomination. OK, let's turn this into less of a rant: if you can do things in a native desktop app, you're almost always better off than with a browser based solution. If you need networking, then you need to put up with latency and throughput. Thay is just unavoidable. What is avoidable is the overhead of unsuitable protcols. HTTP is perfect for one-off stateless requests for documents from a remote server. That is the whole point. But people crammed haphazard session tracking into it (cookies) and wonky authentication, then decided that having open sessions on the server is not something you do and layered an extra layer of statelessness on top of that while all the conplex browser based applications out there are actually incredibly stateful on the client and server. A native client that uses a custom tailor-made stateful protocol to talk to a server that also keeps session state would be much faster and more efficient than the shaky Jenga tower of compoments that are cobbled together to form the current generation of browser based software.

la12 7y ago
> if you can do things in a native desktop app, you're almost always better off than with a browser based solution The reason fewer and fewer people are doing this are more to do with funding. So if I were to build software today, I'd instantly go with web-apps so that I can monetize them as much as I want. Web app software has zero issues with piracy and in built regular cash flow model which everyone wants. Find a way to fund desktop apps and make them as easy to build like web apps and they'll be vogue again.
- TeMPOraL 7y ago
  In other words: companies and individual developers alike prioritize their business needs over providing value to the users. I could stomach this excuse if people were at least honest about it. And still, it's not applicable everywhere. E.g. if you're targeting business customers, the ones that can afford to pay you are also the ones that would be in deep trouble with the regulators if they pirated your software. But that's just part of the problem. Unfortunately, with business customers, another big reason against desktop applications is that they can trivially work around the increasingly arcane and arguably bullshit approval and security policies corporations tend to have around installing new software. Though that seems to be changing; I've recently heard of companies using deep packet inspection to apply similar policies to SaaS webapps.

asark 7y ago

> The real reason in vast majority of cases, why most of our software seems slow is not because someone used Javascript instead of Win32 C or something else programming language related. On the PS3, I bought way less stuff in their store than I might have otherwise, because it was so damn slow, crashed so much (out of memory, felt like, but might have been something else), lost state all the time, and so on. It definitely felt like they were using a web view of some kind, probably with scripting enabled and in use, not just HTML+CSS for layouts & formatting or something. I'm sure that made publishing and adding rich content features ("just have a JS dev do it!") convenient. It also cut the amount of stuff I bought on there by at least half. There's no way I was alone in that—it was so, so bad. Even on the much faster PS4 their store's unpleasant, though—barely, for now, until they bloat it with more JS as we approach the PS5—usable. [EDIT] point being it wasn't the network requests ruining everything in that case, it was memory and processor hogging webtech on a machine that couldn't handle it yet should never have felt slow, going by specs, unless someone'd screwed up bigtime (say, by putting webtech on it).

gmueckl 7y ago
The PS3 should be bored out of its mind running a shop front consisting of a few text labels and images. It is a kind of machine where one would think that it takes deliberate effort to write a simple UI that is actually slow.
zapzupnz 7y ago
Funny thing is the Wii U, which was still less powerful than the PS3, has a delightful shop. It wasn’t necessarily fast, but it didn’t shit itself loading a JPEG — AND has charming music and animations!

eps 7y ago

Point is valid, but that's not the real reason in "the vast majority of cases." The context here is that of the desktop software and the vast majority of desktop software is still not networked at its core. It is slow exactly because programmers used extra blubber layers to simplify their life, not because of the network API latency.

mankeysee 7y ago
>used extra blubber layers to simplify their life "simplify" lmao Or rather to create an artificial market and justify their pay. More deeply, it is a symptom of our economic system that forces to do such things for having a living.

GuB-42 7y ago

The network stack by itself is incredibly fast. I am talking about the Linux TCP/IP stack here, but I suppose that other vendors do just as well if not better. I wrote a simple web server in C and I was impressed by how tight my code had to be to reach the limits of the OS. Even the internet is fast. Just look at fighting games. The simple fact they are playable over the internet is quite a feat. Fighting games require reaction times at the limit of what humans are capable of, and some moves require a 1/60s accuracy. The problem is that there are so many layers of abstraction. You have the OS, JS engine, layout engine, frameworks, etc... Networking is just one of the layers.

Splines 7y ago

I'd say that disk comes a close second, if not first. Overtaxed slow disks with low memory makes for a terrible desktop experience. Once your memory usage climbs and your OS starts paging/swapping things to disk, seemingly trivial operations that page in new code will take forever.

mankeysee 7y ago
Point is, most normal computer usage absolutely should NOT require a 10TB SSD and 256GB ram. It didn't for providing the same/more functionality a few years ago, why does it suddenly require these days?
- la12 7y ago
  Because a web-app is the only way you can monetize a desktop app like functionality in 2019. Linux desktop toolkits and dev environment utterly sucks. You'll have to develop 3 different codebases for Win, Mac and Linux. Worse still, you'll have to reinvent app updates technology if you go with Qt or will be tied into a different updating technology and still have to deal with piracy problems. Or you could go with web-apps: -> Easy to develop code -> Can't be pirated -> In built model of regular payments -> One codebase for all platforms It's not even a close fight.

mankeysee 7y ago

More importantly spending 99% of the time on self-inflicted non-problems that come with using the web as application platform. For example that anyone can open any url anytime...that alone leads to so many problems related to security (user isn't supposed to be able to see/edit/etc this part) and flow (this page shouldn't be visited before filling a form in this other page, and or if we randomly visit there it would error out crazy, what if user deletes their session, what if network is lost which can happen literally any time in the applications life etc) and then of course theres the matter of anything that would be a trip to ram/local hard disk becomes a networked trip to a distant server.