43 ms·

This might be because I am a former semi-pro Quake3 player but these days I grind my teeth with 95% of all software. Everything feels like it has at least 200ms

This might be because I am a former semi-pro Quake3 player but these days I grind my teeth with 95% of all software. Everything feels like it has at least 200ms delay injected, on every transition. I'd honestly pay extra for an iPhone where I can disable ALL motion, too. But that's the least of the problems. I don't want to become the grumpy old grandpa yelling "back in my day!..." but we have waaaaaaaaaaay too much young JS devs who know nothing else. We need to get back to native UIs. Is it awfully hard? Yes it is. Do the users care? No, they don't. Many people want fast UIs. But to be fair to all sides -- there are also a lot of people who don't notice certain slowdowns that I scoff at. So there is a middle ground that won't cost billions to achieve and IMO that should be chased after.

reassembled 6y ago
Game developers know how to make smooth and performant UI, to say nothing of the rest of what goes into writing a game engine, particularly a fast GPU-accelerated engine. I’m starting to think it’s primarily a cultural thing, where it’s just become acceptable in the web dev and Electron app world to ship sluggish, resource-intensive apps. I also feel like more corners are cut and performance issues swept under the rug when devs are not staring down the barrel of the hardware on a daily basis.
- arethuza 6y ago
  VS Code uses Electron and I can't say I've noticed any performance problems with it - indeed it is quite a bit faster for me than its native-code relative Visual Studio. So responsive Electron apps are certainly possible.
  - baybal2 6y ago
    Vs code is an antiexample here. The whole point for then from the start was to not to repeat the Atom fiasco. The entirety of the project was running around of making Webkit not suck. They spent ennormous effort on that.
    - e_proxus 6y ago
      That being said, I immediately notice when switching from Sublime to VS Code. It’s something in the key presses... I think it’s only noticeable if you’ve used a native application for a while. It’s not enough to go from VSC to Sublime and back to VSC again for five minutes. Make an effort to use a native app for a week or a month and then switch back.
      - disgruntledphd2 6y ago
        I noticed this a bunch when I moved from emacs to Jupyter notebook. Emacs will sometimes become slower (especially remote emacs), but it will always buffer your keypresses and do them in the correct order. Jupyter (for whatever reason), doesn't do this with the result that I ended up wanting to create a new code block, but that keypress got lost and then i end up ruining my original code block. I 100% noticed the difference, and it was super frustrating (fortunately I left that job, and have managed to avoid Jupyter in the new gig).
        pdimitar 6y ago
        I am using Spacemacs and have spent days trying to make it work faster (I am on macOS). Took a while and some effort but with a few strange tweaks I managed to make it more responsive. Emacs/Spacemacs can still be weirdly slow sometimes but UI responsiveness is generally miles ahead of all Electron-based software still. Which makes it even funnier. Emacs is decades old and still uses quite a few ancient techniques that are only hampering it. Even with that, it's still so much better in terms of speed! Funny.
      - deleted 6y ago
        [deleted]
    - schmorptron 6y ago
      Wait, what is the atom fiasco?
      - foldr 6y ago
  - tonyedgecombe 6y ago
    VS Code has a lot of native code and VS is particularly bloated. I'm not sure this is a good comparison.
    - sime2009 6y ago
      VS Code has very little native code outside Electron itself.
      - WorldMaker 6y ago
        Depends on which languages you work with. Many language servers are written in their own languages so it is possible to work with a lot of native code when using VS Code day to day even if most of VS Code itself isn't native code. VS Code also used to have far more native code earlier on in its development life, but seems to be transitioning a lot of it to WASM (paralleling the Node ecosystem as a whole moving a lot of performance heavy stuff from native NAPI plugins to WASM boxes; as one example: the major source maps support library moved from JS native to Rust to WASM compiled from Rust, IIRC).
  - robenkleene 6y ago
    I'm very interested in the general perception of VS Code being fast, because for me it's slow enough that it's the main reason I use other editors. Here are a couple of examples: 1. It takes nine times as long as Vim to open a minified JavaScript file, and then format it with Prettier: https://twitter.com/robenkleene/status/1285631026648276993 https://twitter.com/robenkleene/status/1285631026648276993 2. It takes 14 times as long to open an empty text file than BBEdit: https://twitter.com/robenkleene/status/1257724392458661889 https://twitter.com/robenkleene/status/1257724392458661889 Both of the above examples revolve around opening files for the first time, and I suspect a lot of the slowness I perceive is because I open a lot of different projects and source code files when I'm working, and this is a bad use of VS Code. In practice, VS Code behaves more like a multi-language IDE than a text editor. Slow startup times are generally acceptable in IDEs because you're exchanging speed for power. A programmer should ideally be proficient in both an IDE and a text editor, because they're tools applicable to different problems. E.g., VS Code is a terrible choice for things like analyzing log output, formatting large files, testing isolated snippets of code, or working on source code files that aren't part of the same project. I find this to be a shame because VS Code is flexible enough that it would otherwise be excellent for all of these tasks if it were just more performant for some operations that it struggles with now.
    - arethuza 6y ago
      Out of interest do you mean starting a new instance of VS Code for those things or using an existing one. I would agree that VS Code isn't the fastest thing when the editor is starting up, though I find it fine when started. I pretty much always have VS Code running so I don't find this a problem.
      - robenkleene 6y ago
        VS Code is already running in both examples. A lot of the overhead seems to come from making a new window (even though the app itself is already running), although notably most of the time spent in the Prettier example seems to be spent syntax highlighting the JavaScript. If you want to try a direct comparison of opening a file vs. a window, you can see the difference between opening a new file in an existing window (on Mac, `⌘N` / `File > New File`) or new window (on Mac, `⌥⌘N` / `File > New Window`). For me the latter is far slower than the former.
- skohan 6y ago
  Given the state and culture of web development, it's honestly a travesty that most software is consumed via the web currently. I mean the web stack itself was never designed per se. HTML is essentially a text annotation format, which has been abused to support the needs of arbitrary layouts. The weakness of CSS is evident by how difficult it has been to properly center something within a container until relatively recently. And Javascript was literally designed in a week. And then in terms of deploying web content, you have this situation where you have multiple browsers which are moving targets, so you can't even really just target raw HTML+CSS+JS if you want to deploy something - you need a tool like webpack to take care of all the compatibility issues, and translate a tool which is actually usable like React into an artifact which will behave predictably across all environments. I don't blame web developers for abusing libraries, because it's almost impossible to strip it all down and work with the raw interfaces. The whole thing is an enormous hack. If you view your job as a programmer as writing code to drive computer hardware - which is what the true reality of programming is - then web development is so far divorced from that. I think it's a huge problem.
  - grishka 6y ago
    What about those weirdos who deliberately choose to use the abomination that the web stack is for desktop apps? To me it feels like they're trying to write real GUI apps in Word macros. I don't think I'll ever understand why.
    - skohan 6y ago
      In some ways I can I understand it, because if you want to deploy a GUI application which mostly consists of text and pictures across multiple platforms, this is probably most viable option in a lot of cases, but the fact that this is the case is a failure of the market and the industry
      - josephg 6y ago
        Yep. Native software development houses never invested enough in making a cross platform app toolkit as good as the web. There’s no technical reason why we don’t have something like electron, but lightweight and without javascript. But native-feeling cross platform UI is really hard (like $100M+ hard) and no individual company cares enough to make it happen. I’m sure it would be a great investment for the industry as a whole, but every actor with the resources is incentivised to solve their problems using different approaches. It’s pretty disappointing.
- jiggawatts 6y ago
  I used to write 4K demos and the like in assembly, and I wrote a 3D engine in the era where you still thought hard about making something a function call or not because... you know... those fractions of a microseconds add up, and next thing you know you've blown your 16.6ms frame time budget! These days I see people casually adding network hops to web applications like it's nothing. These actually take multiple milliseconds in common scenarios such as cloud hosting on a PaaS. (I measured. Have you?) At that point it's not even relevant how fast your CPUs are, you're blowing your "time budget" in just a handful of remote function calls. If you stop and think about it, the "modern" default protocol stack for a simple function consists of: - Creating an object graph scattered randomly on the heap - Serialising it with dynamic reflection ...to a *text* format! ...written into a dynamically resizing buffer - Gzip compressing it to another resizing buffer - Encrypting it to stop the spies in the data centre - Buffering - Kernel transition - Buffering again in the NIC - Router(s) - Firewall(s) - Load balancer and then the reverse of the above for the data to be received! then the forward -- and -- backwards stack -- again -- for the response If this isn't insanity, I don't know what is...
  - baybal2 6y ago
    Hello, Can you tell what is your occupation? Are you dealing with assembler level programming regularly?
    - jiggawatts 6y ago
      Not any more, these days I do various kinds of systems integration work and I still dabble in development, but mostly with high-level languages like C#. It just grinds me gears that we have all these wonderfully fast computers and we're just throwing the performance away. My analogy to customers where I consult is this: What you're doing is like buying a dozen sticks of RAM, and then throwing ten of them into the trash. It's like pouring superglue into all but a couple of the switch ports. It's like buying a 64-core CPU and disabling 63 of those cores. It's like putting some of the servers on the Moon instead of next to each other in the same rack. Said like that, modern development practices and infrastructure architectures suddenly sound as insane as they truly are.
- moron4hire 6y ago
  I've started noticing a weird counter effect. If you make a web app that is snappy and responsive, people just assume your app is trivial. Users have effectively been trained into thinking things like list pagination are "difficult" operations.
  - sidpatil 6y ago
    Maybe that's like the tech equivalent of enjoying a loud vehicle because it sounds more powerful than a quieter one. (In reality, the quieter one is more efficient than the louder one.)
- lewispollard 6y ago
  You'd be surprised how many games up until recently used Flash (Scaleform GFx), and now in some cases HTML5 (edit: Coherent GT/Hummingbird/Gameface) content for game UI. Rendering hundreds or thousands of meshes and doing complicated 3D math for physics is no problem, UI is still extremely hard and complex, especially if you are supporting multiple arbitrary resolutions for example. Godot, for example, has a full UI toolkit built in (the Godot editor was made using Godot components). However to actually get it working the way you want in most cases is a horrendous struggle, a struggle with ratios, screen sizes, minimum and maximum UI control sizes, size/growth flags, and before it gets any more complicated please just throw me a Tailwind flex/grid box model instead, because HTML/CSS has solved these problems repeatedly already.
est 6y ago
> Everything feels like it has at least 200ms delay injected, on every transition. I'd honestly pay extra for an iPhone If you are using Android, you are in luck. 1. Open Settings > About Phone, Tap the build number 7 times (Or google other methods to open Developer menu for your phone model) 2. Go to Developer options -> Drawing 3. Set all animation scale to 0.5x You'd be amazed to find how fast the phone appears
- nivenkos 6y ago
  You can also disable animations in the same settings, but I found it broke some applications.
- pdimitar 6y ago
  Oh yeah, I am aware of that but not using Android for 4 years now. But I think I'll buy a cheap Xiaomi device and play with Android again. Xiaomi optimize their phones quite a bit (even if you have to fight with their ROM to be less spyware).
  - zwirbl 6y ago
    I'd rather wait a small bit every time than getting a full blown spyphone, but scaling animation times down does improve the feel quite a lot
    - pdimitar 6y ago
      Fair, but it won't be my main device. Still, you have a point.
    - heywherelogingo 6y ago
      Is OnePlus also in this category?
      - Daho0n 6y ago
        No. Not perfect, not bad.
C19is20 6y ago
I would say that those 'that don't notice certain slowdowns', sadly, may never have experienced anything but slowed down systems.
- pdimitar 6y ago
  I know right? Learned helplessness.
- grishka 6y ago
  I mean there's now also an entire generation that has never seen the beautiful non-commercialized internet I miss so dearly. Meanwhile, here I am, making a decentralized social media server and being afraid to add an extra <div> lest it bloats the page.
  - raindropm 6y ago
    or an entire generation that will never realize how "doing nothing" or "being bored" is a good thing, or videogames don't require multiplayer or IAP to be fun. I'm consider myself lucky to be born in the 'transitional period(1980s) I see the world of my parents and also have abilities to adapt with technology.
- why_Mr_Anderson 6y ago
  Long time ago I worked at a hospital and once had to go to a certain department to fix something on computer nurses were using and was horrified how slow the computer and everything was. So I asked around and ladies happily explained their daily morning routine: - turn on computer - do a morning checkup of all patients (around 20 minutes) - when they got back, computer usually finished starting Windows, if not, they waited another 10+ minutes for it to get ready - then they started Word (another 10 minutes) - and opened their main document with notes..or to be exact wanted to open the document. That took another 10 minutes TL;DR - users can get used to pretty much anything because they don't know it could be so much better
  - benhurmarcel 6y ago
throwaway81523 6y ago
I've been convinced for a while that the only sane way to develop any gui app (including web apps) is have game developers in charge. They know how to make stuff run fast, or at least interact snappily.
- chromanoid 6y ago
  Yeah, totally :D https://news.ycombinator.com/item?id=26296339 https://news.ycombinator.com/item?id=26296339 Most game developers will make it as fast as they have to... in fact most developers do that. Games are usually developed as abandonware. Do you want your apps to be developed as abandonware?
- skohan 6y ago
  I think this is actually something which Apple has done a fairly good job of. I remember even back in 2009 in the early iPhone days, the Cocoa API's were fairly well designed in terms of letting you create responsive, non-blocking UIs on hardware an order of magnitude slower than what we have today. Game engineers are wizards, but real general-purpose UI is a different problem than they are generally solving. A game UI is typically very limited in terms of what types of information has to be displayed and how. Many applications have to support what is essentially arbitrary 2D content which has to be laid out dynamically at runtime, and this is something different than the problems most games have to solve.
  - hypertele-Xii 6y ago
    > Many applications have to support what is essentially arbitrary 2D content which has to be laid out dynamically at runtime, and this is something different than the problems most games have to solve. That sounds exactly like the problem most games have to solve. The age of fixed CPU speeds and screen resolutions is long gone. Games have to content with a plethora of dimensions along which to represent an interactive, dynamic, multimedia world.
    - kaba0 6y ago
      I think OP meant it more in terms of layouting, like vbox can be inside a hbox which has also a text object, and every object can change sizes which will cause a recalculation in everything. It is surprisingly more expensive than the GPU accelerated rendering of many many triangles. Games are complex, but the dimensions question is trivial there.
jiofih 6y ago
iOS has very fast and snappy transitions which are well suited for touch screens. And as pointed out in the article, it’s one of the few touch devices with <30ms input latency, so it can hardly be beaten by anything else. It doesn’t feel right with no animation (like Reduced Motion in settings) since spatial hints are lost.
_trampeltier 6y ago
I guess thats also the reason why old games in emulators not feel the same.
the_gipsy 6y ago
That's not fair to "young JS devs" who get inserted into a culture of product slowness.
- deleted 6y ago
  [deleted]
- pdimitar 6y ago
  I've been fired for taking the long road and preferring good craftsmanship and not idolizing shipping several times a day. Sadly most people can't afford that and the results are visible everywhere in IT.
kesor 6y ago
That is because they do inject a delay. https://apple.stackexchange.com/questions/17929/how-can-i-disable-animation-when-switching-desktops-in-lion https://apple.stackexchange.com/questions/17929/how-can-i-di... https://superuser.com/questions/455313/disable-os-x-enter-full-screen-animation https://superuser.com/questions/455313/disable-os-x-enter-fu... It looks "pretty" to the UI people.
- HenryBemis 6y ago
  > It looks "pretty" to the UI people. Buys them time to get stuff done under the hood while you are gazing upon the 'sands of time' (good old Windows hourglass). It conditions you/me/everyone to be impatient. I opt out of all such transition effects on my phone. I prefer that the screen goes black of freezes until the next screen comes up. This way I don't get distracted by irrelevant junk (spinning wheels, hourglasses, etc.). It is crunching bits. Don't add more junk to it. Let it crunch bits without tricking me.
- z92 6y ago
  Anybody else remember the speedup loop. https://thedailywtf.com/articles/The-Speedup-Loop https://thedailywtf.com/articles/The-Speedup-Loop tl;dr : programmer inserts a large empty loop in a UI, so that in weeks when he achieves nothing, he removes a single zero from the end of the loop counter to speed up things a bit.
  - rbanffy 6y ago
    I would expect the compiler to get rid of that loop.
    - bee_rider 6y ago
      The story is from 1990. Nowadays you would probably have to be a little bit more clever. Maybe toss in a volatile variable?
      - rbanffy 6y ago
rayiner 6y ago
It’s awful. Everything web-based is slower on my 4.5 ghz MacBook Pro than things were on my 300 MHz PII running Windows 98. Every web page causes MacOS to complain “Safari is using a lot of power.” I was hunting for a project management web app, and one ate up 10% of the CPU just sitting there doing nothing. This has gotten particularly bad with Microsoft, with Word and Outlook on the Mac, which just kill battery life. (I think they’re using more and more JS under the hood, and I hear Outlook is slated to be replaced with a web app.) Teams is a bloated pig. The crazy thing is that all these web apps also do a fraction of the things that the native apps used to do. They’ve somehow managed to strip down all the features while making the apps slow and bloated. Watching Microsoft’s To-Do blog is comitragic. Elon Musk will be living on Mars before the Microsoft tools allow you to schedule todos by dragging them to the calendar like Outlook has done since what, 98? (You can drag a todo from the web sidebar to the calendar now—but it somehow doesn’t actually schedule the due or start date in the todo itself or even have any link back to the todo.) And I feel like that’s one thing that’s different now. I also complained that Word 97 was a slow bloated big compared to Word Perfect, etc. But back in the day there was feature bloat. Now, everything is both slow and and non-functional. I have to assume that it’s a structural thing with the industry. Machine learning, big data, security, etc., has become the hot areas, so all the “A” teams have migrated over there. I hear Apple is having trouble even getting people to do kernel work on MacOS.
- pdimitar 6y ago
  I have no good theory about why that is except that maybe more and more business people are under the illusion that "software is being increasingly commoditized" which is of course not true.
  - mattgreenrocks 6y ago
    Their perception sort of perpetuates it. I've seen devs arguing this, though IMO that is more the devs speaking out of resignation and learning to say the right things rather than the truth.
  - yourapostasy 6y ago
    > ..."software is being increasingly commoditized"... I only wish this were true; then value propositions for software could climb a value ladder. The challenge is business' are not standardized beyond some very basic functions, and new standardization comes at a brutally high cost (time and expense). So I see where office productivity has settled on Microsoft Office (though even there, I see huge fragmentation between versions, how people don't use styles, how most people have no idea of pivot tables in Excel, etc.), and we've pretty much just crawled along at a snails pace since then. If anything, judging by how little I can transplant of business processes that emerge around software from one company to another, and how much those processes mutate over time, I would assert software standardization is getting worse, because getting businesses to standardize even when moving to the cloud has been a bigger challenge than I anticipated.
__s 6y ago
I don't think young JS devs know nothing else. There are still good programs out there, & you only need to experience it once I get annoyed with Windows having the cursor randomly stutter for a split second rather than smooth motion. Or Teams taking half a second to load the conversation I clicked on. Or Powershell taking 3 seconds between initial render & giving me a damn prompt. Or the delay between me pressing the Windows button & the start menu appearing. None of these delays exist on my Linux machine where I've had the freedom to select the programs I use I've made fast UIs with Javascript & React. Like all optimization it comes down to sitting down & profiling. Not taking "this is as fast it it can be" as an answer. In short, saying "Javascript is just slow" is part of the problem Blaming languages is chasing a fad. I deal with it when people think the service I'm working on in Ruby is going to be slow because Ruby is slow. Nope, architectures are slow. If you know what you're doing Ruby will do just fine at doing nothing, which is really the trick behind speed
- pdimitar 6y ago
  While what you say is fair, let me introduce an additional nuance: Languages like JS and Ruby make it easier to write slower code (and harder to detect that you're doing it) by the virtue of how their ecosystem and culture turned out with time. I stood behind the romantic statement of "you are holding it wrong" when I was younger but nowadays it seems to me that the languages live and die by the culture of their communities. It rarely if ever matters if the language itself can be better / faster. So while I agree JS/Ruby might have undeserved reputation for being slow, I think you should also agree that they are easy targets because observably a lot of software written with them is in fact slow. I am looking at it empirically / historically while you are postulating a theoretical construct. I don't disagree with you per se but prefer to work with the reality that's in front of me. --- That being said, kudos for being the exception in the group of the JS devs! The web frontend industry needs much more people like yourself. Keep up the good work. <3
- tamrix 6y ago
  Your windows cursor shouldn't stutter unless you have io interupt problems, bad drivers etc.
fxtentacle 6y ago
I feel the same way. We have way too many people working on tooling who don't know how to properly make things fast. On some days, I manage to type faster than XCode can display the letters on screen. There is no excuse for that with a 3 GHz CPU. And yes, 200ms seems plausible to me: Bluetooth adds delay over PS2 (about 28ms). DisplayPort adds delay over VGA. LCD screens need to buffer internally. Most even buffer 2-3 frames for motion smoothing (= 50ms). And suddenly you have 78 ms in hardware delay. If the app you're using is Electron or the like, then the click will be buffered for 1 frame, then there's the click handler, then 1 frame of delay until the DOM is updated and another frame of delay for redraw. Maybe add 1 more frame for the Windows compositor. So that's 83ms in software-caused delay. So I'd estimate a minimum of 161ms of latency if you use an Electron-based app with a wireless mouse on a DisplayPort-connected LCD screen, i.e. VSCode on my Mac.
- api 6y ago
  161ms is longer than it takes to ping half way around the world. Amazing.
  - fxtentacle 6y ago
    That's why most people don't notice any performance issues with Google Stadia / Geforce Now. They are conditioned to endure 100+ ms of latency for everything, so an additional 9ms of internet transmission delay from the datacenter into your house is barely noticeable.
- aembleton 6y ago
  161 ms is 1/6th of a second which I would have thought would be noticeable and yet I haven't noticed it. I assume that is mouse clicks? I'm sure Id notice if typing had that much lag on vs code. I am using manjaro Linux but I can't imagine that it would be much faster than osx.
  - aembleton 6y ago
    Just trying in VS Code again, and there does seem to be a lag for mouse clicks. Not sure if its as much as 1/6s, but probably 1/10. Typing though looks as snappy as any terminal. I get electron or MS have optimised the typing path. I don't click that much in VS Code so I don't think its ever bothered me.
spdionis 6y ago
I definitely hear you. As a heavy gamer myself, and a person who likes to do things fast to avoid slowing down my train of thought, our current tools are insanely slow. The researchers telling me I don't notice 100ms delays are smoking something. Yes, human reaction time is 200ms on average but we process information much faster than that. Moreover, the delays make it impossible to do "learned" chains of actions cause of the constant interruptions. Hackers typing insanely fast and windows popping up everywhere in movies? The reason why that looks very unrealistic is just that our tools do not behave like that at all.
- pdimitar 6y ago
  Those researchers never played Quake2 / Quake3 / Unreal Tournament. You can absolutely detect when your ping gets above 25ms even. It can't be missed. > Hackers typing insanely fast and windows popping up everywhere in movies? The reason why that looks very unrealistic is just that our tools do not behave like that at all. Right on. That's why, even though I have an insanely pretty Apple display (on the iMac Pro) I move more and more of my day work to the terminal. Those movie UIs are achievable. Related: I invest a lot of time and energy into learning my every tool's keyboard shortcuts. This increases productivity.
  - remram 6y ago
    And input lag (eg. local, mouse-to-screen lag) gets you before that.
  - kmeisthax 6y ago
    I would argue that it's more noticeable in those older games where they weren't using lag compensation and you had to lead your shots in order to hit other players. If you're testing on a game which has rollback netcode then lag matters less because the game is literally hiding it from you. What task is actually being measured here matters, too. For example, while it is true that humans cannot generally react faster than 100ms or so; most actual skills being tested by competitive gameplay are not pure reaction tests. They are usually some amount of telegraphed stimulus (notice an approaching player, an oncoming platform, etc) followed by an anticipated response. Humans are extremely sensitive to latency specifically because they need to time responses to those stimuli - not because they score really well in snap reaction tests. Concrete example: the window to L-cancel in Melee is really small - far smaller than humanly possible to hit if this was purely a matter of reaction times. Of course, no player actually hits that window, because it's humanly impossible. They don't see their character hit the ground and then press L. They instead press L several frames in advance so that by the time their finger presses the trigger, their character has just hit the ground and made the window. Now, if I go ahead and add two frames of total lag to the display chain, all of their anticipated reactions will be too late and they'll have to retrain for that particular display.
api 6y ago
Native UIs could be much, much better. They've been a neglected backwater for 20 years. Blame OS vendors for refusing to get together to specify a cross-platform standard API for UIs. We have mostly standard APIs for networking, file I/O, even 3D graphics, but not for putting a window on the screen and putting buttons on it. OS vendors are still trying to play the lock-in game by forcing everyone to write GUI apps for only their platform. This is a non-starter, so everyone goes to Electron. There are a few third party cross-platform UI libraries around. They suck. Qt is as bloated as HTML-based UIs, and then there's wxWidgets which is ugly and has an awful API based on 1990s MSC. We could have something better, but it's an extremely large and difficult project and nobody will fund it. OS vendors won't because they don't want cross platform (even though all developers and users do). Nobody else will because nobody pays for dev tools or building blocks. The market has been educated to believe that stuff should all be free-as-in-beer.
- pdimitar 6y ago
  It's a complete stalemate. We can't force the OS vendors. The users don't like the status quo but have no choice. As for the free aspect, I feel like this ship has sailed like 20 years ago. Nobody will pay for an UI toolkit these days. This is not Unreal Engine 4, you know. That stuff only works on AAA games market, apparently (although I am curious as to why it doesn't work everywhere else -- likely thin profit margins and/or middle management greed outside of the gaming genre).
  - api 6y ago
    IMHO a good cross platform UI toolkit is about as hard as a decent 3D game engine. Crazy you say? Start making a list of the features a modern UI toolkit has to have to even be considered for serious projects.
    - pdimitar 6y ago
      I'm not disagreeing with you. It's just that today's mindset makes it impossible for people to pay for GUI toolkits alone, I think.
- 6y ago
npteljes 6y ago
Absolutely agree and I loathe the modern UI with passion, for the speed alone. I recently booted up a single-core 900 mhz desktop PC with Windows XP, and it was so fast to respond that it felt like it knew what I wanted even before I pressed the button. Inspiringly smooth man-machine synergy that is rare to come by these days. I'm an old man yelling at cloud.
- pdimitar 6y ago
  And then you have the Apple II computers where the only bottleneck was the diskette drive speed. Stuff was just instant with almost everything you were doing.
- hypertele-Xii 6y ago
  I recently booted an old single-core PC with the latest version of Ubuntu. It ran like a glacier. Every single click took a minimum of 30 seconds to have effect.
justin66 6y ago
> This might be because I am a former semi-pro Quake3 player but these days I grind my teeth with 95% of all software. Not really. I'm sure plenty of people remember the quick feel of early PC UIs. Ironically, q3 kind of came at the end of that era. Some of the same people might even remember when, with a little training, voice recognition software could do its thing without an internet connection and a warehouse full of computers at the other end, on a PC with less RAM than the framebuffer of a modern PC or phone...
nicbou 6y ago
Websites do feel pretty slow, even when they're just a page of text. Caching helps a lot, but so does sending fewer bytes across the wire. This can be hard to achieve if you work off templates and plugins. Yet, I find it supremely important. I frequently lose my train of thought while waiting for pages to load.
- pdimitar 6y ago
  I'm not debating whether it's hard or not. I've worked with GUI toolkits some 16-18 years ago. It wasn't a walk in the park indeed but you had the means to produce a very snappy and responsive app. Can the same be said about Electron-based apps? I'm too losing my train of thought sometimes waiting for pages/apps to load. It's embarrassing and I'm face-palming.
  - nicbou 6y ago
    I'm strictly talking about text-based pages. It's not hard for us, skilled web developers, but it is hard for people who just want to get their content online.
bluejekyll 6y ago
While I agree with you, there’s a reason the current application environments are targeting web rendering engines, it’s cheaper for development. Why develop 3-4 different applications when you can develop 1 with hardly any extra effort? Chromium is a huge boon to developers for this reason. Now there could have been a different history here. Apple after acquiring NeXT had also gotten OpenStep, https://en.m.wikipedia.org/wiki/OpenStep https://en.m.wikipedia.org/wiki/OpenStep . OpenStep was a cross platform UI development kit, even the web could be a target. Apple decided (possibly for good reasons, hard to argue with success) to kill this off. But, they had toyed with it, https://www.macrumors.com/2007/06/14/yellow-box-seems-to-exist-but-only-for-apples-use/ https://www.macrumors.com/2007/06/14/yellow-box-seems-to-exi... . So, Apple had effectively what Chromium has become. A cross-platform development and runtime environment. Would things be different today if that wasn’t killed off? Would Apple have never come back from the brink of death to become the behemoth it is today, because it would have starved its own platforms? One thing you might have had is a cross-platform “native” UI platform, and that might have meant faster more efficient UIs like you want now. Shoutout to GNUStep trying to keep the dream alive: https://en.m.wikipedia.org/wiki/GNUstep https://en.m.wikipedia.org/wiki/GNUstep Follow up question: maybe with Apple being so successful, now they could revive this and make it profitable for themselves, rather than starving their own platforms?
- ip26 6y ago
  The good news is this means if we make browsers & JS rendering faster, everything gets faster. The bad news is that doesn't seem likely to happen.
bitwize 6y ago
One thing you can do if you're running Linux is to not run a compositing window manager. Use something old-school like fvwm, fluxbox, or WindowMaker. i3 is also good. When the X server draws directly to the display, it is FAST and there is not the delay of at least one frame, possibly several, that compositing WMs have. You run the risk of tearing, but I think most open source X video drivers let you turn tearing off.
- cma 6y ago
  Better to just get a 120hz+ monitor and lower the double buffering delay that way. Sharper clarity while scrolling and or tracking other motion with your eyes with that is worth it.
snake_case 6y ago
I agree that the web is generally more bloated and slow than native apps. However, native apps don't magically become performant by being native. As an example, my grandmother-in-law has been putting up with Microsoft Jigsaw's desktop app for years. Last time I watched her load it, we sat there for awhile and had to restart multiple times because it was getting stuck loading some advertisements. The startup time was absolutely brutal and the run-time performance while playing wasn't great either, even with a decent laptop. So when I saw how slow, bloated and laggy this app was, I wanted to try to make her a better jigsaw app for the web and I think I succeeded [1]. It loads almost instantly, has no advertisements, and feels super smooth while playing... and it's mostly just js, svelte and a little bit of Rust WASM. Anyway, I do prefer a good native app over a web app when available. But with native apps, it's also harder to block ads and other trackers compared to the web. [1]: https://puzzlepanda.com https://puzzlepanda.com
- pdimitar 6y ago
  Sure, I'm not denying it. It's just that apparently it's very easy to produce slow-as-molasses UI with JS. I've been working with the horrors called Windows MFC and Java Swing a long time ago. It was tough but if you did it right (moderately hard) you had a very snappy app on a computer that was 5x slower and had 10x less RAM than a midrange today's Android device.
  - snake_case 6y ago
    You're exactly right! Building a slow web app is only one npm install away. It takes someone who really cares about performance and monitors it to make a fast web app and to keep it that way. Unfortunately it's still too easy to accidentally make it slow.
- bochoh 6y ago
  I had a chance to play the demo round and it was extremely performant - well done. The only thing I'm not sure about is that on the first click of each piece it automatically orients itself to the final orientation as expected by the puzzle. Is this an "Easy / Medium / Hard" setting? Otherwise great!
ridethebike 6y ago
I know right, these days I just open browser with Gmail and youtube home page (not even watching a video) and do nothing - 10%+ CPU utilization (i7, 8 cores). Start serfing the web - laptop fans go into overdrive. It's almost like how much $ and how many cores needed to render bunch of text and images without lagging. And that's my home pc, it's blazingly fast compared to one in office with internal enterprise software installed on it.
- jeffbee 6y ago
  There's something wrong with your PC because nobody will be able to reproduce this result.
  - hnuser123456 6y ago
    Opened Chrome, opened gmail and youtube, nonstop 25% CPU usage, fans ramped to 4000+RPM, closed chrome, 3% with Firefox with some simple tabs. The culprit seems to be chrome's "software_reporter_tool.exe". It has chewed up 3 minutes of CPU and counting. It seems to have some well-multithreaded elements, it's added 12 seconds of CPU time in 1 second occasionally.
    - JTbane 6y ago
      That's Chrome scanning your computer for malware like toolbars and such.
- hypertele-Xii 6y ago
  What's absolutely mind-boggling to me is that moving my mouse consumes 10% of CPU. I fought tooth and nail to keep my PS2 ports, but everything's USB now. And apparently USB consumes 10% CPU to read mouse movements.
  - raindropm 6y ago
    I'm curious about this so I open the task manager and just swing my mouse wildly. It did consume around 16% (from 4% at idle) WAT.
avereveard 6y ago
> "back in my day!..." but we have waaaaaaaaaaay too much young JS devs who know nothing else. funny, java applet in the 90s gained a fame for being slow, being caused mostly by junior devs putting stuff on the UI thread
- pdimitar 6y ago
  I remember those times. To be fair though, there wasn't much of anything else back then...
DennisP 6y ago
Back in the early '90s my dad and I used to say in a few decades we'd all have supercomputers on our desks. Now by those standards we do, and everything is still freakin slow. This is not the future we were dreaming about.
- bmeski 6y ago
  It's because we let the product people in.
  - pdimitar 6y ago
    They forced themselves in, mostly.
hddu 6y ago
You can disable all motion on Android. One of the first things I do is disable all the animations. Everything responds instantly. It's great.
kmeisthax 6y ago
On iOS you can disable animations - it's buried in the Accessibility section but it totally works.
- kaba0 6y ago
  I don’t see the hate for animations when done correctly. I just tried it, and I really prefer the normal mode of operation. On Android I did disable animations because on an older version they are not done as smoothly as on the iPhone, but they can absolutely give many information on what actually happens.
myth2018 6y ago
> We need to get back to native UIs. Is it awfully hard? Yes it is. Do the users care? No, they don't. Many people want fast UIs. I wouldn't say native UIs necessarily, IMO, but I definitely agree that something has to change. Current systems are not only getting slower and less useful, but they're also getting harder to develop, test and maintain as well -- and, consequently, buggier. The fact that there still are many old, TUI-based systems out there AND that users favor them over the newer ones exposes a lesson we've been insisting on overlooking.
- Shared404 6y ago
  Add that to the fact that it's reasonably simple to make a cross platform TUI, and I think you're on to something there. I'm ready to move forward to TUI's over the terrible GUI's we're all stuck with.
  - pdimitar 6y ago
    I'm doing that lately -- very gradually and slowly, but I'm doing it. I've had enough of today's slow buggy messes that require gigabytes of memory and two CPU cores to show me a splash screen for 10 seconds. A lot of the TUI apps I stumbled upon seem really well-done.
    - Shared404 6y ago
      Out of curiosity, do you have a list? I'm always looking for good replacements. I'm currently using nvlc and cmus for music playback, and then of course your standard complement of text editors etc. I like Lynx et al. for some web browsing, but compatibility is a pain.
      - pdimitar 6y ago
        I just started like 6 months ago but... - `lazygit` is extremely valuable. - `lnav` for inspecting log files has turned out to be surprisingly good. - Do you use `fzf` in tandem with your shell so you can also search your command history (and not just look for files)? I use that for like a year now and can't live without it. - `mc` for TUI file management has been moderately alright. - How about `ripgrep`? Can't believe I lived without that one too. - Rust's tool `skim` (the command is `sk`) in tandem with `ripgrep` or `the_silver_searcher` to very quickly search in file contents in big directories has saved me a ton of time already (although I moved to search file contents in projects in Emacs since). To be fair, you can just use `fzf` instead of `sk` here though; I am just positively biased towards Rust. - `ripgrep_all` allows you to search in ZIP archives, PDF docs, Office docs/spreadsheets etc. Really useful. - `ht` is a Rust rewrite of `httpie`, the Python friendlier `curl`. I like `ht` much more because it doesn't incur any startup overhead and started replacing my scraping / syncing scripts with `ht` where applicable which is NOT everywhere because `curl` is extremely powerful and it doesn't often make sense to replace it. - Command-line or in-terminal charting/plotting: `jp`. I have made a CSV file out of all file sizes on my NAS (bucketed by powers of 2) and then invoked it on the input. Here's a sample CSV from a random directory: 0k,79 1k,6 2k,1 4k,166 8k,34 16k,7 32k,6 64k,3 128k,27 256k,2 512k,2 1M,3 2M,4 4M,8 8M,10 16M,135 Then do this: `cat THIS_FILE.csv | jp -input csv -xy '[*][0,1]' -type bar -height 57` And enjoy an in-terminal vertical bar charts. :) - ...And I have a ton more. But your question makes me sigh. I really have to start a blog. I am a very practical guy and people usually love my posts (scattered on different forums) where I make such lists. I should roll my own blog static web site generator in Rust I suppose, because the existing ones are either slow or don't support what I need... So, not going to happen in the next year, most likely. :(
fmakunbound 6y ago
I swear I can see the lag while typing into Slack and I feel like it is definitely getting worse the longer Slack has been running. What the hell is going on there? What are we doing wrong as a species to develop software like this?? Shit should be small, fast and simple.
- capableweb 6y ago
  Since we humans can, magically, make shit appear out of nothing by just writing gibberish and passing that gibberish to another program also written in gibberish, and get something that might be useful (probably not), I feel like we as a species are actually doing pretty well. I agree overall though, most developers/managers of developers/companies who write software fucking suck at their job.
- pdimitar 6y ago
  Agreed, Slack and Teams are particularly egregious examples.
veesahni 6y ago
Totally feel your pain here. I think a lot of has to do with current JS tech- React, by design, trades off performance for developer efficiency. I'm sensitive to latency.. first thing I do when I setup a new android phone is go into the developer settings and speed up all animations. For our own company [0], we also treat speed as a top feature, though it's not something that's easily to market. It's something that power users appreciate. I even wrote a similar blog post [1] to this. The magic number, from what I've found, is 100ms. If you can respond to a user action in 100ms, it feels instant to the user. 0: https://www.enchant.com https://www.enchant.com 1: https://www.enchant.com/speed-is-a-feature https://www.enchant.com/speed-is-a-feature
- pdimitar 6y ago
  Sounds like a good company to work in! :) I would immediately apply but I'm not interested in Ruby or HTML/CSS anymore (although I still know the last two rather well and plan on making a return there to author my own blog theme). Main focus are Elixir and Rust -- the latter exactly because I want to make efficient and ultra-fast software. Also very invested and averagely skilled in DevOps / sysadmin activities. I hope there are more companies like yours out there -- and that yours is thriving!
mrh0057 6y ago
I’m pretty sure if you gave the devs creating slow ui on the web would create slow native apps too. I’ve created web apps that are on average faster than the desktop apps they replaced. I’m willing to bet nice simple fast programs are way cheaper to write. Current situation is people creating abstraction at the wrong level and not understanding the performance cost of things like reflection and ORMs.
- pdimitar 6y ago
  Yep. Hence my somewhat dismissive quip about "way too many young JS devs who know nothing else". Kudos to you. We need more people like you.
- kaba0 6y ago
  I mean, ideally there should be absolutely no bearing of usage of ORM on the snappiness of UIs. It should absolutely never block the Ui thread. At most it could add longer “in progress” screens or something, but that is a different topic (also, good ORMs when used correctly, that is the developer actually knows what he/she does and not only blindly copies code, than I doubt they would cause serious overhead. But I agree that non-correct usage can cause problems)
slaymaker1907 6y ago
Ok then, everyone will just need to pay 3x as much for software. C and C++ will never return as mainstream UI languages for applications without extreme performance considerations because the cost of developing in such languages is too high. Before anyone gets their hopes up, I've written quite a bit of Rust and don't believe it changes this. Rust's type system is very difficult to teach and learn even compared to other complex type systems. Difficult to teach/learn = $$$. Even after writing a lot of Rust, I'm also still not very fast at writing it compared to my speed in other languages. The only change we might see are more "native" UIs written in C#, Swift, etc. Also, Swift will not be a suitable replacement in its current form. Any replacement needs to at minimum work on MacOS plus Windows and by work I mean you can create a UI without crazy amounts of platform specific code.
- pdimitar 6y ago
  There are ways to go still, I agree. But I'd argue that's because nobody wants to invest money and effort. As a fan of Rust (I'm regularly using it but I don't work for money with it currently) you are right: even if everyone agreed to move to it tonight, that wouldn't change things much because we have no cross-platform native UI toolkit. Additionally, you might be surprised what prices people could pay for really good software. I personally will pay $500 for a lifetime license of a lightweight, fast, cross-platform and rock-solid office suite. But there's no such thing.
marmaduke 6y ago
> We need to get back to native UIs. Is it awfully hard? Yes it is Not sure I agree with this. I wrote a bunch of data vis GUIs with PyQt and Pyqtgraph, all Python, with everything keyboard shortcuts and accelerators, and it was Vim-like speed except where CPU bound by data processing (NumPy). So I think it can be fairly easy yet Qt dies (frequently, on HN) on the altar of native look/feel/platform (ie doesn’t look/feel like a MacOS app on macOS).
- pdimitar 6y ago
  Not sure what you mean -- but I've never used Qt. I gather it's a controversial topic because I've heard exactly the opposite feedback than yours about it. Still, I bet if more people used it then its community would have an incentive -- or a kick in the butt -- to quickly fix its deficiencies and it could become the de facto native GUI toolkit? Who knows.
  - kaba0 6y ago
    Qt is really quick and is used at plenty of places. Places where (critical) software is needed for internal use will be written mostly as native apps. For example monitoring and the like. And these places often use Qt. I suggest you to try out the Telegram Desktop app (I think mac has a non-qt version as well so be aware). I really like using it for it’s speed as well. My only gripe with qt is that one has to use C++ or python, other bindings are not
    - pdimitar 6y ago
      Oh, I am using the Telegram Lite desktop app. It's a breath of fresh air in the pile of slow Electron-based UIs. I absolutely love it and learned its keyboard shortcuts.
mcguire 6y ago
And cue the traditional response: "Developer time is much more expensive than computer time, so it doesn't make sense to spend any effort optimizing." :-(
- pdimitar 6y ago
  That might be true in isolation but repeat it enough times and it's actually much cheaper to have several highly paid programmers work on it for several years, compared to so much time and energy lost otherwise...
Daho0n 6y ago
>I'd honestly pay extra for an iPhone where I can disable ALL motion, too. I do that on my Android phone. Feels snappier than the iPhone now. Not perfect though. Scrolling sucks. JavaScript is bad but nowadays that's not the main evil. That falls on the hideous awful libraries on top of JS that everyone seem to love these days. They need to die ASAP.
bdickason 6y ago
Agreed. I typically strip every feature possible out of my phone (and run in low power mode) and gravitate towards apps/products that just get out of my way. When I built my blog, I tried to find every opportunity to reduce cruft (even stripping out extra CSS classes) so reading it would feel as close to a native app as possible. You could argue that HN succeeded because it's focused on speed above all else. (Also - fellow former Q1/Q3 player here, I competed in CPL, Quakecon, and a few other events).
XCSme 6y ago
I just realized that even minimizing HN comment threads has like 1s+ of delay. Profiling: https://i.snipboard.io/UPhtmH.jpg https://i.snipboard.io/UPhtmH.jpg
XCSme 6y ago
> too much young JS devs who know nothing else The problem is not the language or framework, is that very few people/devs/businesses actually care about performance anymore, so they just implement the quickest solution without even thinking about the performance impact.

reassembled 6y ago

Game developers know how to make smooth and performant UI, to say nothing of the rest of what goes into writing a game engine, particularly a fast GPU-accelerated engine. I’m starting to think it’s primarily a cultural thing, where it’s just become acceptable in the web dev and Electron app world to ship sluggish, resource-intensive apps. I also feel like more corners are cut and performance issues swept under the rug when devs are not staring down the barrel of the hardware on a daily basis.

arethuza 6y ago
VS Code uses Electron and I can't say I've noticed any performance problems with it - indeed it is quite a bit faster for me than its native-code relative Visual Studio. So responsive Electron apps are certainly possible.
- baybal2 6y ago
  Vs code is an antiexample here. The whole point for then from the start was to not to repeat the Atom fiasco. The entirety of the project was running around of making Webkit not suck. They spent ennormous effort on that.
  - e_proxus 6y ago
    That being said, I immediately notice when switching from Sublime to VS Code. It’s something in the key presses... I think it’s only noticeable if you’ve used a native application for a while. It’s not enough to go from VSC to Sublime and back to VSC again for five minutes. Make an effort to use a native app for a week or a month and then switch back.
    - disgruntledphd2 6y ago
      I noticed this a bunch when I moved from emacs to Jupyter notebook. Emacs will sometimes become slower (especially remote emacs), but it will always buffer your keypresses and do them in the correct order. Jupyter (for whatever reason), doesn't do this with the result that I ended up wanting to create a new code block, but that keypress got lost and then i end up ruining my original code block. I 100% noticed the difference, and it was super frustrating (fortunately I left that job, and have managed to avoid Jupyter in the new gig).
      - pdimitar 6y ago
        I am using Spacemacs and have spent days trying to make it work faster (I am on macOS). Took a while and some effort but with a few strange tweaks I managed to make it more responsive. Emacs/Spacemacs can still be weirdly slow sometimes but UI responsiveness is generally miles ahead of all Electron-based software still. Which makes it even funnier. Emacs is decades old and still uses quite a few ancient techniques that are only hampering it. Even with that, it's still so much better in terms of speed! Funny.
    - deleted 6y ago
      [deleted]
  - schmorptron 6y ago
    Wait, what is the atom fiasco?
    - foldr 6y ago
- tonyedgecombe 6y ago
  VS Code has a lot of native code and VS is particularly bloated. I'm not sure this is a good comparison.
  - sime2009 6y ago
    VS Code has very little native code outside Electron itself.
    - WorldMaker 6y ago
      Depends on which languages you work with. Many language servers are written in their own languages so it is possible to work with a lot of native code when using VS Code day to day even if most of VS Code itself isn't native code. VS Code also used to have far more native code earlier on in its development life, but seems to be transitioning a lot of it to WASM (paralleling the Node ecosystem as a whole moving a lot of performance heavy stuff from native NAPI plugins to WASM boxes; as one example: the major source maps support library moved from JS native to Rust to WASM compiled from Rust, IIRC).
- robenkleene 6y ago
  I'm very interested in the general perception of VS Code being fast, because for me it's slow enough that it's the main reason I use other editors. Here are a couple of examples: 1. It takes nine times as long as Vim to open a minified JavaScript file, and then format it with Prettier: https://twitter.com/robenkleene/status/1285631026648276993 https://twitter.com/robenkleene/status/1285631026648276993 2. It takes 14 times as long to open an empty text file than BBEdit: https://twitter.com/robenkleene/status/1257724392458661889 https://twitter.com/robenkleene/status/1257724392458661889 Both of the above examples revolve around opening files for the first time, and I suspect a lot of the slowness I perceive is because I open a lot of different projects and source code files when I'm working, and this is a bad use of VS Code. In practice, VS Code behaves more like a multi-language IDE than a text editor. Slow startup times are generally acceptable in IDEs because you're exchanging speed for power. A programmer should ideally be proficient in both an IDE and a text editor, because they're tools applicable to different problems. E.g., VS Code is a terrible choice for things like analyzing log output, formatting large files, testing isolated snippets of code, or working on source code files that aren't part of the same project. I find this to be a shame because VS Code is flexible enough that it would otherwise be excellent for all of these tasks if it were just more performant for some operations that it struggles with now.
  - arethuza 6y ago
    Out of interest do you mean starting a new instance of VS Code for those things or using an existing one. I would agree that VS Code isn't the fastest thing when the editor is starting up, though I find it fine when started. I pretty much always have VS Code running so I don't find this a problem.
    - robenkleene 6y ago
      VS Code is already running in both examples. A lot of the overhead seems to come from making a new window (even though the app itself is already running), although notably most of the time spent in the Prettier example seems to be spent syntax highlighting the JavaScript. If you want to try a direct comparison of opening a file vs. a window, you can see the difference between opening a new file in an existing window (on Mac, `⌘N` / `File > New File`) or new window (on Mac, `⌥⌘N` / `File > New Window`). For me the latter is far slower than the former.
skohan 6y ago
Given the state and culture of web development, it's honestly a travesty that most software is consumed via the web currently. I mean the web stack itself was never designed per se. HTML is essentially a text annotation format, which has been abused to support the needs of arbitrary layouts. The weakness of CSS is evident by how difficult it has been to properly center something within a container until relatively recently. And Javascript was literally designed in a week. And then in terms of deploying web content, you have this situation where you have multiple browsers which are moving targets, so you can't even really just target raw HTML+CSS+JS if you want to deploy something - you need a tool like webpack to take care of all the compatibility issues, and translate a tool which is actually usable like React into an artifact which will behave predictably across all environments. I don't blame web developers for abusing libraries, because it's almost impossible to strip it all down and work with the raw interfaces. The whole thing is an enormous hack. If you view your job as a programmer as writing code to drive computer hardware - which is what the true reality of programming is - then web development is so far divorced from that. I think it's a huge problem.
- grishka 6y ago
  What about those weirdos who deliberately choose to use the abomination that the web stack is for desktop apps? To me it feels like they're trying to write real GUI apps in Word macros. I don't think I'll ever understand why.
  - skohan 6y ago
    In some ways I can I understand it, because if you want to deploy a GUI application which mostly consists of text and pictures across multiple platforms, this is probably most viable option in a lot of cases, but the fact that this is the case is a failure of the market and the industry
    - josephg 6y ago
      Yep. Native software development houses never invested enough in making a cross platform app toolkit as good as the web. There’s no technical reason why we don’t have something like electron, but lightweight and without javascript. But native-feeling cross platform UI is really hard (like $100M+ hard) and no individual company cares enough to make it happen. I’m sure it would be a great investment for the industry as a whole, but every actor with the resources is incentivised to solve their problems using different approaches. It’s pretty disappointing.
jiggawatts 6y ago
I used to write 4K demos and the like in assembly, and I wrote a 3D engine in the era where you still thought hard about making something a function call or not because... you know... those fractions of a microseconds add up, and next thing you know you've blown your 16.6ms frame time budget! These days I see people casually adding network hops to web applications like it's nothing. These actually take multiple milliseconds in common scenarios such as cloud hosting on a PaaS. (I measured. Have you?) At that point it's not even relevant how fast your CPUs are, you're blowing your "time budget" in just a handful of remote function calls. If you stop and think about it, the "modern" default protocol stack for a simple function consists of: - Creating an object graph scattered randomly on the heap - Serialising it with dynamic reflection ...to a *text* format! ...written into a dynamically resizing buffer - Gzip compressing it to another resizing buffer - Encrypting it to stop the spies in the data centre - Buffering - Kernel transition - Buffering again in the NIC - Router(s) - Firewall(s) - Load balancer and then the reverse of the above for the data to be received! then the forward -- and -- backwards stack -- again -- for the response If this isn't insanity, I don't know what is...
- baybal2 6y ago
  Hello, Can you tell what is your occupation? Are you dealing with assembler level programming regularly?
  - jiggawatts 6y ago
    Not any more, these days I do various kinds of systems integration work and I still dabble in development, but mostly with high-level languages like C#. It just grinds me gears that we have all these wonderfully fast computers and we're just throwing the performance away. My analogy to customers where I consult is this: What you're doing is like buying a dozen sticks of RAM, and then throwing ten of them into the trash. It's like pouring superglue into all but a couple of the switch ports. It's like buying a 64-core CPU and disabling 63 of those cores. It's like putting some of the servers on the Moon instead of next to each other in the same rack. Said like that, modern development practices and infrastructure architectures suddenly sound as insane as they truly are.
moron4hire 6y ago
I've started noticing a weird counter effect. If you make a web app that is snappy and responsive, people just assume your app is trivial. Users have effectively been trained into thinking things like list pagination are "difficult" operations.
- sidpatil 6y ago
  Maybe that's like the tech equivalent of enjoying a loud vehicle because it sounds more powerful than a quieter one. (In reality, the quieter one is more efficient than the louder one.)
lewispollard 6y ago
You'd be surprised how many games up until recently used Flash (Scaleform GFx), and now in some cases HTML5 (edit: Coherent GT/Hummingbird/Gameface) content for game UI. Rendering hundreds or thousands of meshes and doing complicated 3D math for physics is no problem, UI is still extremely hard and complex, especially if you are supporting multiple arbitrary resolutions for example. Godot, for example, has a full UI toolkit built in (the Godot editor was made using Godot components). However to actually get it working the way you want in most cases is a horrendous struggle, a struggle with ratios, screen sizes, minimum and maximum UI control sizes, size/growth flags, and before it gets any more complicated please just throw me a Tailwind flex/grid box model instead, because HTML/CSS has solved these problems repeatedly already.

est 6y ago

> Everything feels like it has at least 200ms delay injected, on every transition. I'd honestly pay extra for an iPhone If you are using Android, you are in luck. 1. Open Settings > About Phone, Tap the build number 7 times (Or google other methods to open Developer menu for your phone model) 2. Go to Developer options -> Drawing 3. Set all animation scale to 0.5x You'd be amazed to find how fast the phone appears

nivenkos 6y ago
You can also disable animations in the same settings, but I found it broke some applications.
pdimitar 6y ago
Oh yeah, I am aware of that but not using Android for 4 years now. But I think I'll buy a cheap Xiaomi device and play with Android again. Xiaomi optimize their phones quite a bit (even if you have to fight with their ROM to be less spyware).
- zwirbl 6y ago
  I'd rather wait a small bit every time than getting a full blown spyphone, but scaling animation times down does improve the feel quite a lot
  - pdimitar 6y ago
    Fair, but it won't be my main device. Still, you have a point.
  - heywherelogingo 6y ago
    Is OnePlus also in this category?
    - Daho0n 6y ago
      No. Not perfect, not bad.

C19is20 6y ago

I would say that those 'that don't notice certain slowdowns', sadly, may never have experienced anything but slowed down systems.

pdimitar 6y ago
I know right? Learned helplessness.
grishka 6y ago
I mean there's now also an entire generation that has never seen the beautiful non-commercialized internet I miss so dearly. Meanwhile, here I am, making a decentralized social media server and being afraid to add an extra <div> lest it bloats the page.
- raindropm 6y ago
  or an entire generation that will never realize how "doing nothing" or "being bored" is a good thing, or videogames don't require multiplayer or IAP to be fun. I'm consider myself lucky to be born in the 'transitional period(1980s) I see the world of my parents and also have abilities to adapt with technology.
why_Mr_Anderson 6y ago
Long time ago I worked at a hospital and once had to go to a certain department to fix something on computer nurses were using and was horrified how slow the computer and everything was. So I asked around and ladies happily explained their daily morning routine: - turn on computer - do a morning checkup of all patients (around 20 minutes) - when they got back, computer usually finished starting Windows, if not, they waited another 10+ minutes for it to get ready - then they started Word (another 10 minutes) - and opened their main document with notes..or to be exact wanted to open the document. That took another 10 minutes TL;DR - users can get used to pretty much anything because they don't know it could be so much better
- benhurmarcel 6y ago

throwaway81523 6y ago

I've been convinced for a while that the only sane way to develop any gui app (including web apps) is have game developers in charge. They know how to make stuff run fast, or at least interact snappily.

chromanoid 6y ago
Yeah, totally :D https://news.ycombinator.com/item?id=26296339 https://news.ycombinator.com/item?id=26296339 Most game developers will make it as fast as they have to... in fact most developers do that. Games are usually developed as abandonware. Do you want your apps to be developed as abandonware?
skohan 6y ago
I think this is actually something which Apple has done a fairly good job of. I remember even back in 2009 in the early iPhone days, the Cocoa API's were fairly well designed in terms of letting you create responsive, non-blocking UIs on hardware an order of magnitude slower than what we have today. Game engineers are wizards, but real general-purpose UI is a different problem than they are generally solving. A game UI is typically very limited in terms of what types of information has to be displayed and how. Many applications have to support what is essentially arbitrary 2D content which has to be laid out dynamically at runtime, and this is something different than the problems most games have to solve.
- hypertele-Xii 6y ago
  > Many applications have to support what is essentially arbitrary 2D content which has to be laid out dynamically at runtime, and this is something different than the problems most games have to solve. That sounds exactly like the problem most games have to solve. The age of fixed CPU speeds and screen resolutions is long gone. Games have to content with a plethora of dimensions along which to represent an interactive, dynamic, multimedia world.
  - kaba0 6y ago
    I think OP meant it more in terms of layouting, like vbox can be inside a hbox which has also a text object, and every object can change sizes which will cause a recalculation in everything. It is surprisingly more expensive than the GPU accelerated rendering of many many triangles. Games are complex, but the dimensions question is trivial there.

jiofih 6y ago

iOS has very fast and snappy transitions which are well suited for touch screens. And as pointed out in the article, it’s one of the few touch devices with <30ms input latency, so it can hardly be beaten by anything else. It doesn’t feel right with no animation (like Reduced Motion in settings) since spatial hints are lost.

_trampeltier 6y ago

I guess thats also the reason why old games in emulators not feel the same.

the_gipsy 6y ago

That's not fair to "young JS devs" who get inserted into a culture of product slowness.

deleted 6y ago
[deleted]
pdimitar 6y ago
I've been fired for taking the long road and preferring good craftsmanship and not idolizing shipping several times a day. Sadly most people can't afford that and the results are visible everywhere in IT.

kesor 6y ago

That is because they do inject a delay. https://apple.stackexchange.com/questions/17929/how-can-i-disable-animation-when-switching-desktops-in-lion https://apple.stackexchange.com/questions/17929/how-can-i-di... https://superuser.com/questions/455313/disable-os-x-enter-full-screen-animation https://superuser.com/questions/455313/disable-os-x-enter-fu... It looks "pretty" to the UI people.

HenryBemis 6y ago
> It looks "pretty" to the UI people. Buys them time to get stuff done under the hood while you are gazing upon the 'sands of time' (good old Windows hourglass). It conditions you/me/everyone to be impatient. I opt out of all such transition effects on my phone. I prefer that the screen goes black of freezes until the next screen comes up. This way I don't get distracted by irrelevant junk (spinning wheels, hourglasses, etc.). It is crunching bits. Don't add more junk to it. Let it crunch bits without tricking me.
z92 6y ago
Anybody else remember the speedup loop. https://thedailywtf.com/articles/The-Speedup-Loop https://thedailywtf.com/articles/The-Speedup-Loop tl;dr : programmer inserts a large empty loop in a UI, so that in weeks when he achieves nothing, he removes a single zero from the end of the loop counter to speed up things a bit.
- rbanffy 6y ago
  I would expect the compiler to get rid of that loop.
  - bee_rider 6y ago
    The story is from 1990. Nowadays you would probably have to be a little bit more clever. Maybe toss in a volatile variable?
    - rbanffy 6y ago

rayiner 6y ago

It’s awful. Everything web-based is slower on my 4.5 ghz MacBook Pro than things were on my 300 MHz PII running Windows 98. Every web page causes MacOS to complain “Safari is using a lot of power.” I was hunting for a project management web app, and one ate up 10% of the CPU just sitting there doing nothing. This has gotten particularly bad with Microsoft, with Word and Outlook on the Mac, which just kill battery life. (I think they’re using more and more JS under the hood, and I hear Outlook is slated to be replaced with a web app.) Teams is a bloated pig. The crazy thing is that all these web apps also do a fraction of the things that the native apps used to do. They’ve somehow managed to strip down all the features while making the apps slow and bloated. Watching Microsoft’s To-Do blog is comitragic. Elon Musk will be living on Mars before the Microsoft tools allow you to schedule todos by dragging them to the calendar like Outlook has done since what, 98? (You can drag a todo from the web sidebar to the calendar now—but it somehow doesn’t actually schedule the due or start date in the todo itself or even have any link back to the todo.) And I feel like that’s one thing that’s different now. I also complained that Word 97 was a slow bloated big compared to Word Perfect, etc. But back in the day there was feature bloat. Now, everything is both slow and and non-functional. I have to assume that it’s a structural thing with the industry. Machine learning, big data, security, etc., has become the hot areas, so all the “A” teams have migrated over there. I hear Apple is having trouble even getting people to do kernel work on MacOS.

pdimitar 6y ago
I have no good theory about why that is except that maybe more and more business people are under the illusion that "software is being increasingly commoditized" which is of course not true.
- mattgreenrocks 6y ago
  Their perception sort of perpetuates it. I've seen devs arguing this, though IMO that is more the devs speaking out of resignation and learning to say the right things rather than the truth.
- yourapostasy 6y ago
  > ..."software is being increasingly commoditized"... I only wish this were true; then value propositions for software could climb a value ladder. The challenge is business' are not standardized beyond some very basic functions, and new standardization comes at a brutally high cost (time and expense). So I see where office productivity has settled on Microsoft Office (though even there, I see huge fragmentation between versions, how people don't use styles, how most people have no idea of pivot tables in Excel, etc.), and we've pretty much just crawled along at a snails pace since then. If anything, judging by how little I can transplant of business processes that emerge around software from one company to another, and how much those processes mutate over time, I would assert software standardization is getting worse, because getting businesses to standardize even when moving to the cloud has been a bigger challenge than I anticipated.

__s 6y ago

I don't think young JS devs know nothing else. There are still good programs out there, & you only need to experience it once I get annoyed with Windows having the cursor randomly stutter for a split second rather than smooth motion. Or Teams taking half a second to load the conversation I clicked on. Or Powershell taking 3 seconds between initial render & giving me a damn prompt. Or the delay between me pressing the Windows button & the start menu appearing. None of these delays exist on my Linux machine where I've had the freedom to select the programs I use I've made fast UIs with Javascript & React. Like all optimization it comes down to sitting down & profiling. Not taking "this is as fast it it can be" as an answer. In short, saying "Javascript is just slow" is part of the problem Blaming languages is chasing a fad. I deal with it when people think the service I'm working on in Ruby is going to be slow because Ruby is slow. Nope, architectures are slow. If you know what you're doing Ruby will do just fine at doing nothing, which is really the trick behind speed

pdimitar 6y ago
While what you say is fair, let me introduce an additional nuance: Languages like JS and Ruby make it easier to write slower code (and harder to detect that you're doing it) by the virtue of how their ecosystem and culture turned out with time. I stood behind the romantic statement of "you are holding it wrong" when I was younger but nowadays it seems to me that the languages live and die by the culture of their communities. It rarely if ever matters if the language itself can be better / faster. So while I agree JS/Ruby might have undeserved reputation for being slow, I think you should also agree that they are easy targets because observably a lot of software written with them is in fact slow. I am looking at it empirically / historically while you are postulating a theoretical construct. I don't disagree with you per se but prefer to work with the reality that's in front of me. --- That being said, kudos for being the exception in the group of the JS devs! The web frontend industry needs much more people like yourself. Keep up the good work. <3
tamrix 6y ago
Your windows cursor shouldn't stutter unless you have io interupt problems, bad drivers etc.

fxtentacle 6y ago

I feel the same way. We have way too many people working on tooling who don't know how to properly make things fast. On some days, I manage to type faster than XCode can display the letters on screen. There is no excuse for that with a 3 GHz CPU. And yes, 200ms seems plausible to me: Bluetooth adds delay over PS2 (about 28ms). DisplayPort adds delay over VGA. LCD screens need to buffer internally. Most even buffer 2-3 frames for motion smoothing (= 50ms). And suddenly you have 78 ms in hardware delay. If the app you're using is Electron or the like, then the click will be buffered for 1 frame, then there's the click handler, then 1 frame of delay until the DOM is updated and another frame of delay for redraw. Maybe add 1 more frame for the Windows compositor. So that's 83ms in software-caused delay. So I'd estimate a minimum of 161ms of latency if you use an Electron-based app with a wireless mouse on a DisplayPort-connected LCD screen, i.e. VSCode on my Mac.

api 6y ago
161ms is longer than it takes to ping half way around the world. Amazing.
- fxtentacle 6y ago
  That's why most people don't notice any performance issues with Google Stadia / Geforce Now. They are conditioned to endure 100+ ms of latency for everything, so an additional 9ms of internet transmission delay from the datacenter into your house is barely noticeable.
aembleton 6y ago
161 ms is 1/6th of a second which I would have thought would be noticeable and yet I haven't noticed it. I assume that is mouse clicks? I'm sure Id notice if typing had that much lag on vs code. I am using manjaro Linux but I can't imagine that it would be much faster than osx.
- aembleton 6y ago
  Just trying in VS Code again, and there does seem to be a lag for mouse clicks. Not sure if its as much as 1/6s, but probably 1/10. Typing though looks as snappy as any terminal. I get electron or MS have optimised the typing path. I don't click that much in VS Code so I don't think its ever bothered me.

spdionis 6y ago

I definitely hear you. As a heavy gamer myself, and a person who likes to do things fast to avoid slowing down my train of thought, our current tools are insanely slow. The researchers telling me I don't notice 100ms delays are smoking something. Yes, human reaction time is 200ms on average but we process information much faster than that. Moreover, the delays make it impossible to do "learned" chains of actions cause of the constant interruptions. Hackers typing insanely fast and windows popping up everywhere in movies? The reason why that looks very unrealistic is just that our tools do not behave like that at all.

pdimitar 6y ago
Those researchers never played Quake2 / Quake3 / Unreal Tournament. You can absolutely detect when your ping gets above 25ms even. It can't be missed. > Hackers typing insanely fast and windows popping up everywhere in movies? The reason why that looks very unrealistic is just that our tools do not behave like that at all. Right on. That's why, even though I have an insanely pretty Apple display (on the iMac Pro) I move more and more of my day work to the terminal. Those movie UIs are achievable. Related: I invest a lot of time and energy into learning my every tool's keyboard shortcuts. This increases productivity.
- remram 6y ago
  And input lag (eg. local, mouse-to-screen lag) gets you before that.
- kmeisthax 6y ago
  I would argue that it's more noticeable in those older games where they weren't using lag compensation and you had to lead your shots in order to hit other players. If you're testing on a game which has rollback netcode then lag matters less because the game is literally hiding it from you. What task is actually being measured here matters, too. For example, while it is true that humans cannot generally react faster than 100ms or so; most actual skills being tested by competitive gameplay are not pure reaction tests. They are usually some amount of telegraphed stimulus (notice an approaching player, an oncoming platform, etc) followed by an anticipated response. Humans are extremely sensitive to latency specifically because they need to time responses to those stimuli - not because they score really well in snap reaction tests. Concrete example: the window to L-cancel in Melee is really small - far smaller than humanly possible to hit if this was purely a matter of reaction times. Of course, no player actually hits that window, because it's humanly impossible. They don't see their character hit the ground and then press L. They instead press L several frames in advance so that by the time their finger presses the trigger, their character has just hit the ground and made the window. Now, if I go ahead and add two frames of total lag to the display chain, all of their anticipated reactions will be too late and they'll have to retrain for that particular display.

api 6y ago

Native UIs could be much, much better. They've been a neglected backwater for 20 years. Blame OS vendors for refusing to get together to specify a cross-platform standard API for UIs. We have mostly standard APIs for networking, file I/O, even 3D graphics, but not for putting a window on the screen and putting buttons on it. OS vendors are still trying to play the lock-in game by forcing everyone to write GUI apps for only their platform. This is a non-starter, so everyone goes to Electron. There are a few third party cross-platform UI libraries around. They suck. Qt is as bloated as HTML-based UIs, and then there's wxWidgets which is ugly and has an awful API based on 1990s MSC. We could have something better, but it's an extremely large and difficult project and nobody will fund it. OS vendors won't because they don't want cross platform (even though all developers and users do). Nobody else will because nobody pays for dev tools or building blocks. The market has been educated to believe that stuff should all be free-as-in-beer.

pdimitar 6y ago
It's a complete stalemate. We can't force the OS vendors. The users don't like the status quo but have no choice. As for the free aspect, I feel like this ship has sailed like 20 years ago. Nobody will pay for an UI toolkit these days. This is not Unreal Engine 4, you know. That stuff only works on AAA games market, apparently (although I am curious as to why it doesn't work everywhere else -- likely thin profit margins and/or middle management greed outside of the gaming genre).
- api 6y ago
  IMHO a good cross platform UI toolkit is about as hard as a decent 3D game engine. Crazy you say? Start making a list of the features a modern UI toolkit has to have to even be considered for serious projects.
  - pdimitar 6y ago
    I'm not disagreeing with you. It's just that today's mindset makes it impossible for people to pay for GUI toolkits alone, I think.
6y ago

npteljes 6y ago

Absolutely agree and I loathe the modern UI with passion, for the speed alone. I recently booted up a single-core 900 mhz desktop PC with Windows XP, and it was so fast to respond that it felt like it knew what I wanted even before I pressed the button. Inspiringly smooth man-machine synergy that is rare to come by these days. I'm an old man yelling at cloud.

pdimitar 6y ago
And then you have the Apple II computers where the only bottleneck was the diskette drive speed. Stuff was just instant with almost everything you were doing.
hypertele-Xii 6y ago
I recently booted an old single-core PC with the latest version of Ubuntu. It ran like a glacier. Every single click took a minimum of 30 seconds to have effect.

justin66 6y ago

> This might be because I am a former semi-pro Quake3 player but these days I grind my teeth with 95% of all software. Not really. I'm sure plenty of people remember the quick feel of early PC UIs. Ironically, q3 kind of came at the end of that era. Some of the same people might even remember when, with a little training, voice recognition software could do its thing without an internet connection and a warehouse full of computers at the other end, on a PC with less RAM than the framebuffer of a modern PC or phone...

nicbou 6y ago

Websites do feel pretty slow, even when they're just a page of text. Caching helps a lot, but so does sending fewer bytes across the wire. This can be hard to achieve if you work off templates and plugins. Yet, I find it supremely important. I frequently lose my train of thought while waiting for pages to load.

pdimitar 6y ago
I'm not debating whether it's hard or not. I've worked with GUI toolkits some 16-18 years ago. It wasn't a walk in the park indeed but you had the means to produce a very snappy and responsive app. Can the same be said about Electron-based apps? I'm too losing my train of thought sometimes waiting for pages/apps to load. It's embarrassing and I'm face-palming.
- nicbou 6y ago
  I'm strictly talking about text-based pages. It's not hard for us, skilled web developers, but it is hard for people who just want to get their content online.

bluejekyll 6y ago

While I agree with you, there’s a reason the current application environments are targeting web rendering engines, it’s cheaper for development. Why develop 3-4 different applications when you can develop 1 with hardly any extra effort? Chromium is a huge boon to developers for this reason. Now there could have been a different history here. Apple after acquiring NeXT had also gotten OpenStep, https://en.m.wikipedia.org/wiki/OpenStep https://en.m.wikipedia.org/wiki/OpenStep . OpenStep was a cross platform UI development kit, even the web could be a target. Apple decided (possibly for good reasons, hard to argue with success) to kill this off. But, they had toyed with it, https://www.macrumors.com/2007/06/14/yellow-box-seems-to-exist-but-only-for-apples-use/ https://www.macrumors.com/2007/06/14/yellow-box-seems-to-exi... . So, Apple had effectively what Chromium has become. A cross-platform development and runtime environment. Would things be different today if that wasn’t killed off? Would Apple have never come back from the brink of death to become the behemoth it is today, because it would have starved its own platforms? One thing you might have had is a cross-platform “native” UI platform, and that might have meant faster more efficient UIs like you want now. Shoutout to GNUStep trying to keep the dream alive: https://en.m.wikipedia.org/wiki/GNUstep https://en.m.wikipedia.org/wiki/GNUstep Follow up question: maybe with Apple being so successful, now they could revive this and make it profitable for themselves, rather than starving their own platforms?

ip26 6y ago
The good news is this means if we make browsers & JS rendering faster, everything gets faster. The bad news is that doesn't seem likely to happen.

bitwize 6y ago

One thing you can do if you're running Linux is to not run a compositing window manager. Use something old-school like fvwm, fluxbox, or WindowMaker. i3 is also good. When the X server draws directly to the display, it is FAST and there is not the delay of at least one frame, possibly several, that compositing WMs have. You run the risk of tearing, but I think most open source X video drivers let you turn tearing off.

cma 6y ago
Better to just get a 120hz+ monitor and lower the double buffering delay that way. Sharper clarity while scrolling and or tracking other motion with your eyes with that is worth it.

snake_case 6y ago

I agree that the web is generally more bloated and slow than native apps. However, native apps don't magically become performant by being native. As an example, my grandmother-in-law has been putting up with Microsoft Jigsaw's desktop app for years. Last time I watched her load it, we sat there for awhile and had to restart multiple times because it was getting stuck loading some advertisements. The startup time was absolutely brutal and the run-time performance while playing wasn't great either, even with a decent laptop. So when I saw how slow, bloated and laggy this app was, I wanted to try to make her a better jigsaw app for the web and I think I succeeded [1]. It loads almost instantly, has no advertisements, and feels super smooth while playing... and it's mostly just js, svelte and a little bit of Rust WASM. Anyway, I do prefer a good native app over a web app when available. But with native apps, it's also harder to block ads and other trackers compared to the web. [1]: https://puzzlepanda.com https://puzzlepanda.com

pdimitar 6y ago
Sure, I'm not denying it. It's just that apparently it's very easy to produce slow-as-molasses UI with JS. I've been working with the horrors called Windows MFC and Java Swing a long time ago. It was tough but if you did it right (moderately hard) you had a very snappy app on a computer that was 5x slower and had 10x less RAM than a midrange today's Android device.
- snake_case 6y ago
  You're exactly right! Building a slow web app is only one npm install away. It takes someone who really cares about performance and monitors it to make a fast web app and to keep it that way. Unfortunately it's still too easy to accidentally make it slow.
bochoh 6y ago
I had a chance to play the demo round and it was extremely performant - well done. The only thing I'm not sure about is that on the first click of each piece it automatically orients itself to the final orientation as expected by the puzzle. Is this an "Easy / Medium / Hard" setting? Otherwise great!

ridethebike 6y ago

I know right, these days I just open browser with Gmail and youtube home page (not even watching a video) and do nothing - 10%+ CPU utilization (i7, 8 cores). Start serfing the web - laptop fans go into overdrive. It's almost like how much $ and how many cores needed to render bunch of text and images without lagging. And that's my home pc, it's blazingly fast compared to one in office with internal enterprise software installed on it.

jeffbee 6y ago
There's something wrong with your PC because nobody will be able to reproduce this result.
- hnuser123456 6y ago
  Opened Chrome, opened gmail and youtube, nonstop 25% CPU usage, fans ramped to 4000+RPM, closed chrome, 3% with Firefox with some simple tabs. The culprit seems to be chrome's "software_reporter_tool.exe". It has chewed up 3 minutes of CPU and counting. It seems to have some well-multithreaded elements, it's added 12 seconds of CPU time in 1 second occasionally.
  - JTbane 6y ago
    That's Chrome scanning your computer for malware like toolbars and such.
hypertele-Xii 6y ago
What's absolutely mind-boggling to me is that moving my mouse consumes 10% of CPU. I fought tooth and nail to keep my PS2 ports, but everything's USB now. And apparently USB consumes 10% CPU to read mouse movements.
- raindropm 6y ago
  I'm curious about this so I open the task manager and just swing my mouse wildly. It did consume around 16% (from 4% at idle) WAT.

avereveard 6y ago

> "back in my day!..." but we have waaaaaaaaaaay too much young JS devs who know nothing else. funny, java applet in the 90s gained a fame for being slow, being caused mostly by junior devs putting stuff on the UI thread

pdimitar 6y ago
I remember those times. To be fair though, there wasn't much of anything else back then...

DennisP 6y ago

Back in the early '90s my dad and I used to say in a few decades we'd all have supercomputers on our desks. Now by those standards we do, and everything is still freakin slow. This is not the future we were dreaming about.

bmeski 6y ago
It's because we let the product people in.
- pdimitar 6y ago
  They forced themselves in, mostly.

hddu 6y ago

You can disable all motion on Android. One of the first things I do is disable all the animations. Everything responds instantly. It's great.

kmeisthax 6y ago

On iOS you can disable animations - it's buried in the Accessibility section but it totally works.

kaba0 6y ago
I don’t see the hate for animations when done correctly. I just tried it, and I really prefer the normal mode of operation. On Android I did disable animations because on an older version they are not done as smoothly as on the iPhone, but they can absolutely give many information on what actually happens.

myth2018 6y ago

> We need to get back to native UIs. Is it awfully hard? Yes it is. Do the users care? No, they don't. Many people want fast UIs. I wouldn't say native UIs necessarily, IMO, but I definitely agree that something has to change. Current systems are not only getting slower and less useful, but they're also getting harder to develop, test and maintain as well -- and, consequently, buggier. The fact that there still are many old, TUI-based systems out there AND that users favor them over the newer ones exposes a lesson we've been insisting on overlooking.

Shared404 6y ago
Add that to the fact that it's reasonably simple to make a cross platform TUI, and I think you're on to something there. I'm ready to move forward to TUI's over the terrible GUI's we're all stuck with.
- pdimitar 6y ago
  I'm doing that lately -- very gradually and slowly, but I'm doing it. I've had enough of today's slow buggy messes that require gigabytes of memory and two CPU cores to show me a splash screen for 10 seconds. A lot of the TUI apps I stumbled upon seem really well-done.
  - Shared404 6y ago
    Out of curiosity, do you have a list? I'm always looking for good replacements. I'm currently using nvlc and cmus for music playback, and then of course your standard complement of text editors etc. I like Lynx et al. for some web browsing, but compatibility is a pain.
    - pdimitar 6y ago
      I just started like 6 months ago but... - `lazygit` is extremely valuable. - `lnav` for inspecting log files has turned out to be surprisingly good. - Do you use `fzf` in tandem with your shell so you can also search your command history (and not just look for files)? I use that for like a year now and can't live without it. - `mc` for TUI file management has been moderately alright. - How about `ripgrep`? Can't believe I lived without that one too. - Rust's tool `skim` (the command is `sk`) in tandem with `ripgrep` or `the_silver_searcher` to very quickly search in file contents in big directories has saved me a ton of time already (although I moved to search file contents in projects in Emacs since). To be fair, you can just use `fzf` instead of `sk` here though; I am just positively biased towards Rust. - `ripgrep_all` allows you to search in ZIP archives, PDF docs, Office docs/spreadsheets etc. Really useful. - `ht` is a Rust rewrite of `httpie`, the Python friendlier `curl`. I like `ht` much more because it doesn't incur any startup overhead and started replacing my scraping / syncing scripts with `ht` where applicable which is NOT everywhere because `curl` is extremely powerful and it doesn't often make sense to replace it. - Command-line or in-terminal charting/plotting: `jp`. I have made a CSV file out of all file sizes on my NAS (bucketed by powers of 2) and then invoked it on the input. Here's a sample CSV from a random directory: 0k,79 1k,6 2k,1 4k,166 8k,34 16k,7 32k,6 64k,3 128k,27 256k,2 512k,2 1M,3 2M,4 4M,8 8M,10 16M,135 Then do this: `cat THIS_FILE.csv | jp -input csv -xy '[*][0,1]' -type bar -height 57` And enjoy an in-terminal vertical bar charts. :) - ...And I have a ton more. But your question makes me sigh. I really have to start a blog. I am a very practical guy and people usually love my posts (scattered on different forums) where I make such lists. I should roll my own blog static web site generator in Rust I suppose, because the existing ones are either slow or don't support what I need... So, not going to happen in the next year, most likely. :(

fmakunbound 6y ago

I swear I can see the lag while typing into Slack and I feel like it is definitely getting worse the longer Slack has been running. What the hell is going on there? What are we doing wrong as a species to develop software like this?? Shit should be small, fast and simple.

capableweb 6y ago
Since we humans can, magically, make shit appear out of nothing by just writing gibberish and passing that gibberish to another program also written in gibberish, and get something that might be useful (probably not), I feel like we as a species are actually doing pretty well. I agree overall though, most developers/managers of developers/companies who write software fucking suck at their job.
pdimitar 6y ago
Agreed, Slack and Teams are particularly egregious examples.

veesahni 6y ago

Totally feel your pain here. I think a lot of has to do with current JS tech- React, by design, trades off performance for developer efficiency. I'm sensitive to latency.. first thing I do when I setup a new android phone is go into the developer settings and speed up all animations. For our own company [0], we also treat speed as a top feature, though it's not something that's easily to market. It's something that power users appreciate. I even wrote a similar blog post [1] to this. The magic number, from what I've found, is 100ms. If you can respond to a user action in 100ms, it feels instant to the user. 0: https://www.enchant.com https://www.enchant.com 1: https://www.enchant.com/speed-is-a-feature https://www.enchant.com/speed-is-a-feature

pdimitar 6y ago
Sounds like a good company to work in! :) I would immediately apply but I'm not interested in Ruby or HTML/CSS anymore (although I still know the last two rather well and plan on making a return there to author my own blog theme). Main focus are Elixir and Rust -- the latter exactly because I want to make efficient and ultra-fast software. Also very invested and averagely skilled in DevOps / sysadmin activities. I hope there are more companies like yours out there -- and that yours is thriving!

mrh0057 6y ago

I’m pretty sure if you gave the devs creating slow ui on the web would create slow native apps too. I’ve created web apps that are on average faster than the desktop apps they replaced. I’m willing to bet nice simple fast programs are way cheaper to write. Current situation is people creating abstraction at the wrong level and not understanding the performance cost of things like reflection and ORMs.

pdimitar 6y ago
Yep. Hence my somewhat dismissive quip about "way too many young JS devs who know nothing else". Kudos to you. We need more people like you.
kaba0 6y ago
I mean, ideally there should be absolutely no bearing of usage of ORM on the snappiness of UIs. It should absolutely never block the Ui thread. At most it could add longer “in progress” screens or something, but that is a different topic (also, good ORMs when used correctly, that is the developer actually knows what he/she does and not only blindly copies code, than I doubt they would cause serious overhead. But I agree that non-correct usage can cause problems)

slaymaker1907 6y ago

Ok then, everyone will just need to pay 3x as much for software. C and C++ will never return as mainstream UI languages for applications without extreme performance considerations because the cost of developing in such languages is too high. Before anyone gets their hopes up, I've written quite a bit of Rust and don't believe it changes this. Rust's type system is very difficult to teach and learn even compared to other complex type systems. Difficult to teach/learn = $$$. Even after writing a lot of Rust, I'm also still not very fast at writing it compared to my speed in other languages. The only change we might see are more "native" UIs written in C#, Swift, etc. Also, Swift will not be a suitable replacement in its current form. Any replacement needs to at minimum work on MacOS plus Windows and by work I mean you can create a UI without crazy amounts of platform specific code.

pdimitar 6y ago
There are ways to go still, I agree. But I'd argue that's because nobody wants to invest money and effort. As a fan of Rust (I'm regularly using it but I don't work for money with it currently) you are right: even if everyone agreed to move to it tonight, that wouldn't change things much because we have no cross-platform native UI toolkit. Additionally, you might be surprised what prices people could pay for really good software. I personally will pay $500 for a lifetime license of a lightweight, fast, cross-platform and rock-solid office suite. But there's no such thing.

marmaduke 6y ago

> We need to get back to native UIs. Is it awfully hard? Yes it is Not sure I agree with this. I wrote a bunch of data vis GUIs with PyQt and Pyqtgraph, all Python, with everything keyboard shortcuts and accelerators, and it was Vim-like speed except where CPU bound by data processing (NumPy). So I think it can be fairly easy yet Qt dies (frequently, on HN) on the altar of native look/feel/platform (ie doesn’t look/feel like a MacOS app on macOS).

pdimitar 6y ago
Not sure what you mean -- but I've never used Qt. I gather it's a controversial topic because I've heard exactly the opposite feedback than yours about it. Still, I bet if more people used it then its community would have an incentive -- or a kick in the butt -- to quickly fix its deficiencies and it could become the de facto native GUI toolkit? Who knows.
- kaba0 6y ago
  Qt is really quick and is used at plenty of places. Places where (critical) software is needed for internal use will be written mostly as native apps. For example monitoring and the like. And these places often use Qt. I suggest you to try out the Telegram Desktop app (I think mac has a non-qt version as well so be aware). I really like using it for it’s speed as well. My only gripe with qt is that one has to use C++ or python, other bindings are not
  - pdimitar 6y ago
    Oh, I am using the Telegram Lite desktop app. It's a breath of fresh air in the pile of slow Electron-based UIs. I absolutely love it and learned its keyboard shortcuts.

mcguire 6y ago

And cue the traditional response: "Developer time is much more expensive than computer time, so it doesn't make sense to spend any effort optimizing." :-(

pdimitar 6y ago
That might be true in isolation but repeat it enough times and it's actually much cheaper to have several highly paid programmers work on it for several years, compared to so much time and energy lost otherwise...

Daho0n 6y ago

>I'd honestly pay extra for an iPhone where I can disable ALL motion, too. I do that on my Android phone. Feels snappier than the iPhone now. Not perfect though. Scrolling sucks. JavaScript is bad but nowadays that's not the main evil. That falls on the hideous awful libraries on top of JS that everyone seem to love these days. They need to die ASAP.

bdickason 6y ago

Agreed. I typically strip every feature possible out of my phone (and run in low power mode) and gravitate towards apps/products that just get out of my way. When I built my blog, I tried to find every opportunity to reduce cruft (even stripping out extra CSS classes) so reading it would feel as close to a native app as possible. You could argue that HN succeeded because it's focused on speed above all else. (Also - fellow former Q1/Q3 player here, I competed in CPL, Quakecon, and a few other events).

XCSme 6y ago

I just realized that even minimizing HN comment threads has like 1s+ of delay. Profiling: https://i.snipboard.io/UPhtmH.jpg https://i.snipboard.io/UPhtmH.jpg

XCSme 6y ago

> too much young JS devs who know nothing else The problem is not the language or framework, is that very few people/devs/businesses actually care about performance anymore, so they just implement the quickest solution without even thinking about the performance impact.