4 ms·

> showing the user environment before the software was fully started. and it has migrated to web apps today - where doing something causes the UI to show a loa

by chii 2y ago

> showing the user environment before the software was fully started. and it has migrated to web apps today - where doing something causes the UI to show a loading/progress wheel, but it takes forever in actuality (or on start up of the webpage, you get a blank screen with placeholder bars/blurred color images etc). And this is the so-called responsive design...

forgotusername6 2y ago
What would you suggest? Is it better to wait until the whole app is loaded to show anything? Or is the only solution to fix loading times in the first place?
- arkh 2y ago
  > Or is the only solution to fix loading times in the first place? Ding! Ding! Ding! We got a winner! Yeah, maybe we could expect machines which got 40 years of Moore's law to give you an experience at least as snappy as what you got on DOS apps.
  - 72deluxe 2y ago
    Yes I am baffled how modern apps are painfully slow. Everything seems to include a Chrome Embedded Framework and therefore have an entire browser running. There is sadly a generation of people who grew up after .net was introduced who think it's perfectly reasonable for a VM spooling up as part of an app load or loading a browser is fine too, and have no idea how speedy Windows 95 used to be, or how loading an app took less than 1 second, or how easy Delphi apps were to create. It's honestly very sad.
    - mike_hearn 2y ago
      Let's not go too far with the rose tinted glasses. Win95 apps are speedy if you run them on modern hardware but at the time they were all dog slow because the average Win95 machine was swapping like crazy. Loading apps on it definitely did not take one second. The prevalence of splash screens was a testament to that. Practically every app had one whereas today they're rare. Even browsers had multi-second splash screens back then. Microsoft was frequently suspected to be cheating because their apps started so fast you could only see the splash for a second or two, and nobody could work out how they did it. In reality they had written a custom linker that minimized the number of disk seeks required, and everything was disk seek constrained so that made a huge difference. Delphi apps were easier to create than if you used Visual C++/MFC but compared to modern tooling it wasn't that good. I say that as a someone who grew up with Delphi. Things have got better. In particular they got a lot more reliable. Software back then crashed all the time.
      - 72deluxe 2y ago
        I suppose you are right. I worked with MFC/C++ and COM and it was horrible. Delphi and C++ Builder things were nicer to use but fell by the wayside, particularly after Borland lost their focus and didn't bother supporting VCL correctly in themes and also had major issues with their C++ compiler. They suffered a brain drain. I remember Windows Explorer opening swiftly back in the day (fileman even faster - https://github.com/microsoft/winfile https://github.com/microsoft/winfile now archived sadly) and today's Explorer experience drives me insane as to how slow it is. I have even disabled most linked-in menu items as the evaluation of these makes Explorer take even longer to load; I don't see why it can't be less than 1 second. Anyway, I do recall Netscape taking a long time to load but then I did only have a 486 DX2 66MHz and 64MB of RAM.... The disk churning did take a long time, now you remind me... I think using wxWidgets on Windows and Mac was quite nice when I did that (with wxFormBuilder); C++ development on Windows using native toolkits is foreign to me today as it all looks a mess from Microsoft unless I have misunderstood. In any case, I can't see why programs are so sluggish and slow these days. I don't understand why colossal JS toolkits are needed for websites and why the average website size has grown significantly. It's like people have forgotten how to write good speedy software.
        mike_hearn 2y ago
        Well, today I spent a lot of time waiting for some slow software that I wrote and maintain, a program that helps ship large desktop apps that use JVM or Electron. It can do native apps too but nearly nobody writes those. So I guess I both feel and create your pain in several directions. Why is my software slow? Partly because the task is inherently intensive. Partly because I use an old Intel MacBook that throttles itself like crazy after too much CPU load is applied. Partly because I'm testing on Windows which has very slow file I/O and so any app that does lots of file I/O suffers. And partly because it's a JVM app which doesn't use any startup time optimizations. But mostly it's because nobody seems to care. People complain to me about various things, performance isn't one of them. Why don't I fix it anyway? Because my time is super limited and there's always a higher priority. Bug fixes come first, features second, optimizations last. They just don't matter. Also: optimizations that increase the risk of bugs are a bad idea, because people forgive poor performance but not bugs, so even doing an optimization at all can be a bad idea. Over the years hardware gave us much better performance and we chose to spend all of it on things like features, reducing the bug count, upping complexity (especially visual), simplifying deployment, portability, running software over the network, thin laptops and other nice things that we didn't have on Windows 98. Maybe AI will reduce the cost of software enough that performance becomes more of a priority, but probably not. We'll just spend it all on more features and bug fixes.
    - duped 2y ago
      > Yes I am baffled how modern apps are painfully slow. People underestimate how slow the network is, and put a network between the app and its logic to make the app itself a thin HTTP client and "application" a mess of networked servers in the cloud. The network is your enemy, but people treat it like reading and writing to disk because it happens to be faster at their desk when they test.
      - 72deluxe 2y ago
        I think all developers should test against a Raspberry Pi 3 for running their software (100mbps network link) just to concentrate on making it smaller and faster. This would eradicate the colossal JS libraries that have become the modern equivalent of many DLLs.
        dijit 2y ago
        Modern iterations of the Pi have 1000Mbit but your statement has an even broader hole based on the context. Latency. The issue the parent mentions is one of latency, if you’re in the EU and your application server is in us-east-1 then you’re likely staring at a RTT of 200ms. The Pi under your desk from NY? 30ms- even less if its a local test harness running in docker on your laptop.
    - kjkjadksj 2y ago
      It is really amazing how big gui flagship apps like office suite or adobe suite seem slower than they did in 2001. And really they don’t do anything different than these old tools maybe a few extra functions (like content aware fill in ps) but the bread and butter is largely the same. So why is it so slow? It is almost like they realized users are happy to wait 30-60 seconds for an app to open in 2001 and kept that expectation even as the task remained the same and computers got an order of magnitude more powerful in that time.
  - oblio 2y ago
    When I want to make old devs cry I send them this link[1]: https://forum.dlang.org/ https://forum.dlang.org/ I know it's very simple, I know there isn't a lot of media (and definitely no tracking or ads), but it shows what could be possible on the internet. It's just that nobody cares. [1] Yes, Hacker News is also quite good in terms of loading speed.
    - skydhash 2y ago
      Private torrent trackers are generally fast too. My pet peeves is when news websites are slow, because the only content you have is 90% text.
      - kjkjadksj 2y ago
        That 10% left of adware is heavy stuff
- Aanok 2y ago
  I think at the very least individual widgets should wait to be fully initialized before becoming interactable. The amount of times I've, say, tried to click on a dropdown menu entry just to have it change right under my cursor making me click on something else because the widget was actually loading data asynchronously, without giving me any notice to the fact at all, is frankly ridiculous. It's the right thing to do to load resources asynchronously in parallel, but you shouldn't load the interface piecemeal. Even on web browsers. I'd much rather wait for an interface to be reliable than have it interactive immediately but having to make a guess about its state.
tonyedgecombe 2y ago
I'd be happy to get a progress wheel, half the time it is a blank page.
- skydhash 2y ago
  There used to be a loading progress by the browser, but today, it’s when it’s done that the real loading start.
caseyohara 2y ago
> And this is the so-called responsive design... I’m not sure if this was meant to be a pun, but “responsive design” has nothing to do with how quickly a UI loads. It’s about adapting to different screen sizes.
- kjkjadksj 2y ago
  Plain html could do that too. People forget the ancient knowledge.
  - presbyterian 2y ago
    If everything was plain HTML, the web would still be only for academics and a handful of nerds, and most of the people on HN would have to find other jobs.
    - chii 2y ago
      Well, the plain html version of gmail (which google recently removed) works so much better and runs so much faster than the fully interactive webapp version. I would imagine that to be the case for a lot of webapps out there.
  - 7bit 2y ago
    Plain HTML does not support scrolling, why else are there so many websites with JS scrolling behaviour.

by chii 2y ago

forgotusername6 2y ago

What would you suggest? Is it better to wait until the whole app is loaded to show anything? Or is the only solution to fix loading times in the first place?

arkh 2y ago
> Or is the only solution to fix loading times in the first place? Ding! Ding! Ding! We got a winner! Yeah, maybe we could expect machines which got 40 years of Moore's law to give you an experience at least as snappy as what you got on DOS apps.
- 72deluxe 2y ago
  Yes I am baffled how modern apps are painfully slow. Everything seems to include a Chrome Embedded Framework and therefore have an entire browser running. There is sadly a generation of people who grew up after .net was introduced who think it's perfectly reasonable for a VM spooling up as part of an app load or loading a browser is fine too, and have no idea how speedy Windows 95 used to be, or how loading an app took less than 1 second, or how easy Delphi apps were to create. It's honestly very sad.
  - mike_hearn 2y ago
    Let's not go too far with the rose tinted glasses. Win95 apps are speedy if you run them on modern hardware but at the time they were all dog slow because the average Win95 machine was swapping like crazy. Loading apps on it definitely did not take one second. The prevalence of splash screens was a testament to that. Practically every app had one whereas today they're rare. Even browsers had multi-second splash screens back then. Microsoft was frequently suspected to be cheating because their apps started so fast you could only see the splash for a second or two, and nobody could work out how they did it. In reality they had written a custom linker that minimized the number of disk seeks required, and everything was disk seek constrained so that made a huge difference. Delphi apps were easier to create than if you used Visual C++/MFC but compared to modern tooling it wasn't that good. I say that as a someone who grew up with Delphi. Things have got better. In particular they got a lot more reliable. Software back then crashed all the time.
    - 72deluxe 2y ago
      I suppose you are right. I worked with MFC/C++ and COM and it was horrible. Delphi and C++ Builder things were nicer to use but fell by the wayside, particularly after Borland lost their focus and didn't bother supporting VCL correctly in themes and also had major issues with their C++ compiler. They suffered a brain drain. I remember Windows Explorer opening swiftly back in the day (fileman even faster - https://github.com/microsoft/winfile https://github.com/microsoft/winfile now archived sadly) and today's Explorer experience drives me insane as to how slow it is. I have even disabled most linked-in menu items as the evaluation of these makes Explorer take even longer to load; I don't see why it can't be less than 1 second. Anyway, I do recall Netscape taking a long time to load but then I did only have a 486 DX2 66MHz and 64MB of RAM.... The disk churning did take a long time, now you remind me... I think using wxWidgets on Windows and Mac was quite nice when I did that (with wxFormBuilder); C++ development on Windows using native toolkits is foreign to me today as it all looks a mess from Microsoft unless I have misunderstood. In any case, I can't see why programs are so sluggish and slow these days. I don't understand why colossal JS toolkits are needed for websites and why the average website size has grown significantly. It's like people have forgotten how to write good speedy software.
      - mike_hearn 2y ago
        Well, today I spent a lot of time waiting for some slow software that I wrote and maintain, a program that helps ship large desktop apps that use JVM or Electron. It can do native apps too but nearly nobody writes those. So I guess I both feel and create your pain in several directions. Why is my software slow? Partly because the task is inherently intensive. Partly because I use an old Intel MacBook that throttles itself like crazy after too much CPU load is applied. Partly because I'm testing on Windows which has very slow file I/O and so any app that does lots of file I/O suffers. And partly because it's a JVM app which doesn't use any startup time optimizations. But mostly it's because nobody seems to care. People complain to me about various things, performance isn't one of them. Why don't I fix it anyway? Because my time is super limited and there's always a higher priority. Bug fixes come first, features second, optimizations last. They just don't matter. Also: optimizations that increase the risk of bugs are a bad idea, because people forgive poor performance but not bugs, so even doing an optimization at all can be a bad idea. Over the years hardware gave us much better performance and we chose to spend all of it on things like features, reducing the bug count, upping complexity (especially visual), simplifying deployment, portability, running software over the network, thin laptops and other nice things that we didn't have on Windows 98. Maybe AI will reduce the cost of software enough that performance becomes more of a priority, but probably not. We'll just spend it all on more features and bug fixes.
  - duped 2y ago
    > Yes I am baffled how modern apps are painfully slow. People underestimate how slow the network is, and put a network between the app and its logic to make the app itself a thin HTTP client and "application" a mess of networked servers in the cloud. The network is your enemy, but people treat it like reading and writing to disk because it happens to be faster at their desk when they test.
    - 72deluxe 2y ago
      I think all developers should test against a Raspberry Pi 3 for running their software (100mbps network link) just to concentrate on making it smaller and faster. This would eradicate the colossal JS libraries that have become the modern equivalent of many DLLs.
      - dijit 2y ago
        Modern iterations of the Pi have 1000Mbit but your statement has an even broader hole based on the context. Latency. The issue the parent mentions is one of latency, if you’re in the EU and your application server is in us-east-1 then you’re likely staring at a RTT of 200ms. The Pi under your desk from NY? 30ms- even less if its a local test harness running in docker on your laptop.
  - kjkjadksj 2y ago
    It is really amazing how big gui flagship apps like office suite or adobe suite seem slower than they did in 2001. And really they don’t do anything different than these old tools maybe a few extra functions (like content aware fill in ps) but the bread and butter is largely the same. So why is it so slow? It is almost like they realized users are happy to wait 30-60 seconds for an app to open in 2001 and kept that expectation even as the task remained the same and computers got an order of magnitude more powerful in that time.
- oblio 2y ago
  When I want to make old devs cry I send them this link[1]: https://forum.dlang.org/ https://forum.dlang.org/ I know it's very simple, I know there isn't a lot of media (and definitely no tracking or ads), but it shows what could be possible on the internet. It's just that nobody cares. [1] Yes, Hacker News is also quite good in terms of loading speed.
  - skydhash 2y ago
    Private torrent trackers are generally fast too. My pet peeves is when news websites are slow, because the only content you have is 90% text.
    - kjkjadksj 2y ago
      That 10% left of adware is heavy stuff
Aanok 2y ago
I think at the very least individual widgets should wait to be fully initialized before becoming interactable. The amount of times I've, say, tried to click on a dropdown menu entry just to have it change right under my cursor making me click on something else because the widget was actually loading data asynchronously, without giving me any notice to the fact at all, is frankly ridiculous. It's the right thing to do to load resources asynchronously in parallel, but you shouldn't load the interface piecemeal. Even on web browsers. I'd much rather wait for an interface to be reliable than have it interactive immediately but having to make a guess about its state.

tonyedgecombe 2y ago

I'd be happy to get a progress wheel, half the time it is a blank page.

skydhash 2y ago
There used to be a loading progress by the browser, but today, it’s when it’s done that the real loading start.

caseyohara 2y ago

> And this is the so-called responsive design... I’m not sure if this was meant to be a pun, but “responsive design” has nothing to do with how quickly a UI loads. It’s about adapting to different screen sizes.

kjkjadksj 2y ago
Plain html could do that too. People forget the ancient knowledge.
- presbyterian 2y ago
  If everything was plain HTML, the web would still be only for academics and a handful of nerds, and most of the people on HN would have to find other jobs.
  - chii 2y ago
    Well, the plain html version of gmail (which google recently removed) works so much better and runs so much faster than the fully interactive webapp version. I would imagine that to be the case for a lot of webapps out there.
- 7bit 2y ago
  Plain HTML does not support scrolling, why else are there so many websites with JS scrolling behaviour.