13 ms·

> The biggest gripe is that everything feels sluggish. Alt-tabbing between Firefox and a terminal takes one second, as does switching between Firefox tabs. As a

• Google234 6y ago
  I don’t understand your comment. When would taking 1 seconds to switch tabs ever feel normal? Are you saying all computers should be that slow?
  • opan 6y ago
    Software should be optimized for weaker machines so that it's not this slow even on machines this cheap.
    • paulcole 6y ago
      Why bother to support something that 1 in 1,000 people (high estimate) is going to be using?
      • saagarjha 6y ago
        The same reason you use accessibility in general: there might be 1 in 1,000 people who might permanently need it, but considerably more who may want it at certain times (running a compile job in the background, on a business trip and only have low internet speeds, underclocking to save battery, …) and that can be the difference between "I want to use your software because it always works for me" and "I tried it and it works 90% of the time for me, so it's not reliable enough for me to pick it". Plus there's the usual feel-good "I'm helping more people using my software, even the (often) lesser-privileged" rather than "I shouldn't care about these people".
        • novok 6y ago
          Those people don't pay you $$$, so in exchange for cheaper / faster eng costs, you pay via lower quality software. In businesses that would actually pay slack money, they will probably pay $800 for a decent enough laptop to run slack every 4 years and employees bring their own smartphones now.
          • cxr 6y ago
            Capitalists also have financial incentives to prioritize against environmental concerns, and yet raising a criticism about a business's practices that neglect to take environmental impact into account isn't out of hand an unreasonable thing to do on the basis that addressing it would mean higher costs to the business. It's a reasonable criticism that reasonable people can have opposing perspectives on and find it worthwhile to talk about, rather than being immediately dismissed. (I also don't see anything in this comment that actually addresses the accessibility metaphor raised by the person you're responding to.)
      • imtringued 6y ago
        If it can run well on bad hardware then it will run even better on good hardware.
        • ClikeX 6y ago
          Unless it's a videogame where framerate and physics are inherently linked. [1] https://www.youtube.com/watch?v=AqDOefJc7a4 https://www.youtube.com/watch?v=AqDOefJc7a4
      • squarefoot 6y ago
        It's not just supporting, it's about not wasting resources that can be used productively for other things. Take a look at this paint software: https://github.com/Symbian9/azpainter https://github.com/Symbian9/azpainter https://tipsonubuntu.com/2020/05/19/azpainter-full-color-illustration-drawing-software-for-linux/ https://tipsonubuntu.com/2020/05/19/azpainter-full-color-ill... It's written in pure C by one developer, and it's super fast. Operations are on par with other software because fx libraries are usually already written in native compiled languages and optimized, but this one loads its interface in a lot less than one second, which becomes like 100 ms or less cached. Wouldn't it be wonderful if all software would at least load their interface comparatively fast? Why do i have to waste (tens? hundreds?) megabytes just to show a GUI that does absolutely nothing else than linking events to graphics elements when someone can write a full fledged software using a quite complex interface whose entire executable size is less than one megabyte?
      • ClikeX 6y ago
        Just to humor you. We develop websites on $3000 Macbooks Pro's. The shitty $300 Windows laptop I see in most households is struggling with a lot of websites. As are $200 Android phones I see many people use on a daily basis. I rarely see any developer testing performance on a crap device or bad connection. The Pinebook might be an outlier device by itself. But ARM Windows laptops are pretty common.
  • dTal 6y ago
    Their point is that software is written so that it's only barely fast enough on machines much more powerful than a PineBook, which makes it more difficult than necessary to use perfectly functional machines that happen to be slower than average. The problem is that fast software is harder to write than slow software (there are trivial transforms from fast to slow, but not vice versa). Thus, each generation back you expect your software to run smoothly on, represents more effort (or at least, more care) on the part of the author. We should expect software to be "just fast enough for the average user" essentially by natural law.
• jorvi 6y ago
  I don’t particularly agree with Facebook it’s ethical ideologies but one great thing they do (or used to do?) is 2G fridays where the devs could only test the app on a simulated 2G connection with throttled bandwidth and simulated delays / packet loss. I’m pretty sure in general smartphone apps are tested for a decent variety of performance targets, perhaps it should happen more for desktop software. Now that I think of it, the push for more and more Electron apps may be because all devs are living comfortably on 16GB and 32GB devices, where the voracious RAM appetite of Electron does not matter.
  • throwaway189262 6y ago
    > Now that I think of it, the push for more and more Electron apps may be because all devs are living comfortably on 16GB and 32GB devices, where the voracious RAM appetite of Electron does not matter. IMO its generally the JS hype producing these monstrosities. QT and Java have had fast and powerful cross-platform UI for ages. I'm trying to push a new paradigm at work where we write most of the logic in Rust. UI view layer would be JavaFx for desktop and React Native for mobile. Only 2 UI's to target for all platforms, reuse of core code, and good performance all around.
    • cxr 6y ago
      > IMO its generally the JS hype producing these monstrosities. If you use "the JS hype" as a synonym for what are considered best practices by the folks in the NodeJS/NPM ecosystem, then you're right. (I.e., the fault lies in the "hype" half, not in the "JS" half.) It was 10–15 years ago that you could routinely hear one of the most prevalent criticisms in the programming world about the bloat of Java. I think that, where JS is concerned, for some reason we're seeing a regression where it's becoming "conventional wisdom" that JS itself is slow, against the evidence to the contrary. I've seen straightfaced comments here on HN in the last few months, for example, that complain about the slowness of JS as a general rule. But the reality is that the JS runtimes have billions of dollars of engineering from top-tier teams invested in them, and today's JS engines are by-and-large pretty fast. V8, in fact, shares parts of its implementation with Java's HotSpot—specifically the parts that were developed by the folks who made the StrongTalk VM and who were acquired by Sun, thus leading to that work being incorporated into HotSpot in the first place. So what is that reason? There has been a noticeable shift in performance degradation that corresponds to the rise of, for lack of a better term, "the NPM way of programming". As with the case of Enterprise™ Java®, the problem lies in the way people in those circles are writing their programs and what passes for an "idiomatic" coding style. The NPM style used heavily in many Electron apps is relatively recent, with respect to JS's lifetime. Even before JS engines were JITted, Firefox itself had hundreds of thousands (millions?) of lines of JS doing a lot of the work both in what you see on the screen when you're poking at your browser as well as behind the scenes. Notably, the JS in those cases is not of the NPM style. There's nothing in principle that means the "Emacs-like" application architecture (compiled core, dynamic shell) needs to be slow, particularly on today's hardware. As I've mentioned before[1], in the early days of Firefox, I used to use 1.0 and 1.5 on an 800 MHz PIII with 128 MB of RAM. (For folks looking to leap in here with what they'd like to consider a well-timed "well, actually…": yes, I'm acutely aware that even that number is on the order of 100× or more beyond what is necessary to get real work done with a computer—but the point is that it's nothing compared to, say, stock 2015-era Chromebooks with 8GB of RAM, or a comparable quantity in today's phones, for that matter.) Browser extensions are written in JS, and my laptop now is several times over better than the laptop I used 10 years ago—and yet... if I install any arbitrary extension today, there's a good chance that I will encounter perceptible bloat there, too. A recent example (within the last year) that I know of, is the WorldBrain Memex add-on, which upon immediate use has the telltale mark of influence from the world of modern "frontend" webdev, and the performance to match. This wasn't the case when add-ons were authored in the sui generis style of yesteryear, before the NPM practices leaked over and began influencing everything related to JS—and tainting people's perceptions. So I find the attempt to draw a contrast between JS and Java a little misplaced. Even ignoring the common history (in both culture and provenance), there's the fact that Java IDEs themselves have always been the poster children of bloat—second only (or somewhere in the running) along with Visual Studio proper. I know people like to point to VSCode as an example of a "snappy" Electron app, and the inevitable retort about just how lean it really is. (On my system, I don't think it's possible to run VSCode without making sure that there's at least 350 MB of main memory to spare before launching it. Compare to the old joke about Emacs's "bloat": that it was supposed to stand for "Eight Megabytes And Constantly Swapping".) On the other hand, I have to recognize that the folks calling VSCode snappy really are on to something. The previous statements notwithstanding, the fact is that VSCode is still snappier than anything I've ever experienced using one of the mainstream Java IDEs. If I were a naive person, I could point to that and conclude that the problem lies with Java-the-language. And yet every day I used my phone with large parts written in Java—which, to be fair, does impart some impression of bloat and sluggishness, so it's prudent for me to keep in mind earlier versions of Android on older, more limited hardware that did have a fairly snappy feel. And those observations lead us back to the root problem, which is if you judged only by much the code being written today, programmers seem to have forgotten (or simply never learned?) how not to write code that's bloated and slow. 1. https://news.ycombinator.com/item?id=23183770 https://news.ycombinator.com/item?id=23183770
• throwaway189262 6y ago
  What is this user doing lol? I've run Linux on an absolutely ancient Thinkpad because we had some stuff in the field that needed serial/parallel port for comms. It ran fine as long as you didn't have 10 tabs open. And Slack has become a bloated piece of crap. It lags like hell on everything I own. It takes a few seconds to switch between channels and workspaces on my overclocked 3700x with 32gb of ram on fiber.
  • vosper 6y ago
    Is the performance of the app the same as the website? I’ve only ever run Slack in a browser tab, and haven't had much in the way of performance problems.
    • throwaway189262 6y ago
      Ironically, I've found it to be worse. No idea why
  • novok 6y ago
    I think something is up with your slack instance or computer. I have a 2017 15" macbook pro and never get channel changes taking seconds.
    • literallycancer 6y ago
      It's a chat program. It should run just fine on 2007 laptops. Shitty engineering is what's up with it.
  • _trampeltier 6y ago
    Modern software is soooo terrible. It's not just bloated, the animation of every action, "smooth" opening a menu or a window are so slow. Everything is so slow these days. When you'r just in an office and click a bit around it is all nice, fine and shiny. But as soon as you are in a hurry, these animations feel like hours .. you click 20 times on the wrong place because animations are so slow .. one day I will bend my pretty fast ZBook on work over my knee because I'm f*ing angry.