Windows Mobile came with a regular browser for years before the iPhone. There was nothing crazy about first iPhone's specs either, pretty in line with the rest of the market. While it wasn't big with regular consumers, WM had a decent smartphone market share at the time (Windows Phone would never come close). Amongst executives, managers and the likes, it was absolutely dominating. When it first came out, many WM users (including Microsoft) considered the iPhone to be a joke. At best, another player in a crowded market. Sure, people liked some features. But they were considered easy-to-replicate gimmicks (and many were indeed quickly copied by enthusiasts). WM was way ahead as a platform. iOS didn't even let you install apps! Apple PCs/laptops were fairly niche at the time too. It wasn't obvious how Apple had a defensible advantage.

Quite frankly, I still tend to think it's as much about Apple knocking it out of the park with the UX (and marketing), as it is about Microsoft doing literally everything wrong in response. WM could have become what Android is today.

Nokia smartphones had http+html browsers back in 2001. I don't know how many mobile optimized sites were there, but the browser on my 9210 was pretty usable (though not everything worked, of course). I used to save full pages on my desktop and copy it on the 9210 to read while on the go. (Well, we didn't have Pocket back then, and while I definitely wanted to develop something similar, I just couldn't make myself do it in Symbian's C++ dialect.)

I disagree in that internet on the original iPhone was terrible, and everyone I knew who bought one didn't really do much browsing on it. It was the UI/UX. Being able to touch-drag was so different from the indirectness of the buttons on previous phones, or using a pen on a squishy screen (I was the nerd that was previously into Palm and Windows CE(?) devices). I remember that what my friends who had the original iPhone showed off wasn't primarily the browser, but rather the pinch-zoom feature on the photos they took, the drag-bounce effect in apps, and of course just the whole thing of having a big screen with no keyboard or somewhat gaudy keypads.

But I agree also agree with you in that my own first iPhone was the iPhone 3G, and the 3G part and later the app store became a major thing for the device, whether it was browsing the web, or using internet-centered apps (chat, sms, reddit, etc.).

Agreed. When I didn't need to boot up BREW or whatever it was called to access google at what felt like 1Bps anymore, it was a game changer. This alone was a huge improvement - I had real access to the web all of a sudden, from anywhere.

This is a great insight, I’m reading this from my iPhone now!

Your apps UX is the language your users must learn and speak to convey their intent to software.

Having an expressive vocabulary and complex grammar is great for saying a lot quickly if they’re fluent but painfully slow for anyone who isn’t.

The capacitive touch and the accelerometer allowed them to make a web browser that could display 'normal' web pages. Up until then everyone had been dicking around with mobile web sites and the lack of ubiquity and cost of doing so... as well as the often hamfisted attempts to assume why you were on the website from mobile... all of these hamstrung mobile browsing adoption.

With this in place commerce could begin on the phone. Once everyone added mobile pay options it could end there as well. An now everyone has one, if they can.

My mom had a touch-capable phone with a resistive touchscreen and hated it. Her fingernails were not huge or anything but they were long enough she had to press with the pad of her finger, not the tip, and it crippled her accuracy.

AOL was very successful, even though it was slow and laggy, and calling the UX “meh” is being generous.

The iPhone won because it looked amazing and had the App Store. Looks and features. How did you reach the conclusion that it was speed?

One word : Gestures.

We can think of things like slide to unlock but much more importantly scrolling. If something shows more the mastery of the iphone UX of that time it is definitely scrolling, who categories it as gesture now? It's completely normalized, on all other Platform of that time, you had to play with arrows and the scroll bar. Now every platform has it.

Using a touchscreen pre-iPhone usually felt like executing commands on a computer application.

Using an iPhone felt like directly manipulating the underlying content. It was a qualitatively different experience that only superficially resembled previous touchscreen devices insofar as it used similar input hardware.

Note that Apple didn't invent the concept of a responsive UI thread with physics-based UI metaphors, for example Jeff Han demonstrated a fairly sophisticated example at TED2006[1] the year before. But to my knowledge the iPhone was the first mass-produced device with a direct manipulation interface.

[1] https://www.ted.com/talks/jeff_han_the_radical_promise_of_th...

Maybe. But the author says speed IS the killer feature (for products) so it has to be true at the higher level too. UX is the perception of the user of the product and their, well, experience using the product. If it's generic it's because it really is that generic, because users won't know why exactly they like a product.

But in the case of iOS vs Symbian:

- as others said: capacitive touch screen (this is not an OS issue, but iphone was among the firsts to use it, definitely earlier than Nokia). This is huge. Like the thing that everyone was talking about (around me) when the original iphone came out is how you could swipe to see the pictures. And it wasn't just for paging, it defined how you could interact with the phone (think pinch zooming, and rotation - not sure when these were added).

- the touch screen UI itself. Nokia played around with the touch UI before, but never really liked it. It was expressed several times internally, that touch is just a no go. But no wonder: the resistive touch screen is pretty bad, but also Symbian itself was built on the assumption that all you have is keys while iOS was built with touch UI in mind from the very beginning. (Now, of course touch was added to Symbian, but that's just not the same. Or they didn't put in the effort. Nokia even had an experimental touch phone released to the market in 2003, the 7700[1], but it was mostly ridiculous.)

- the UI just was a lot more polished, looked better, classier, the graphics was better. They had OpenGL and probably a graphics accelerator - nothing like that in Symbian, of course. (It even took the android guys by surprise, I remember reading/hearing in an interview that when they saw a demo or the release, they've realized that they had to redo the UI from scratch. Because before that they had this Blackberry-ish/Symbianish idea, they thought they were competing with that.)

- I'm pretty sure it had a better browser.

And this pretty much defines the experience, the feel a user gets from the phone. It couldn't send or receive MMS-es (some people may have used it then, but most I guess just wanted to have the feature), it couldn't receive 'push' email. I.e. you had to manually refresh your inbox, emails didn't just arrive. It didn't even have apps. Symbian had all these. It has had these for years then. It even had an app store like thing (at least you had to send in your app for verification which would then be signed by Nokia or it couldn't be installed - that was a new thing around 2004-2006, something I think nobody really did before).

[1] https://www.gsmarena.com/nokia_7700-570.php

I never saw (or see) the need to combine them. Early 2000s I figured in-ear phones (headset minus the phone) would be a thing Real Soon(tm), and then a PDA would be all I need to be productive. I still miss Palm and the apps available on it. Naturally, there is benefit to a connected PDA, but cellular? I wouldn't miss it, if my phone was just my headset.

Interestingly... too fast can be a problem too. A prime example is this site, Hacker News, on a really fast browser. I'll often sit there waiting for a navigation to load, until I realize it had already loaded (to a similar looking page), just so fast I didn't notice the transition.

That's a very normal Seiko (or similar) receipt printer. I spent a lot of time programming them. Humorously, the programming manual is marked "confidential" (I guess to make it hard for anyone to make compatible printers), but there are copies of it all over the web, and there are plenty of compatible printers ;).

The POS app that I worked on (not related to the one shown in the video) also went to pretty serious lengths to get rid of the pause between the user pressing "enter" and the receipt coming out. The store operators rightfully insisted on this, because they wanted to keep the checkout lines moving as fast as possible.

I liked those printers and remember wanting one for myself even though I had no use for it. They start at around $200 and take up space, so I managed to resist.

And yet so many are slow as mud

I don't know how Costco does it, but if you use tap to pay or insert your card into the chip reader while the cashier is scanning your items, at the end when the cashier presses the button to indicate they are finished scanning, it instantly says "approved" and prints a receipt.

Costco is the only place where I've seen this. I don't understand how it gets an authorization for any amount that fast, since it can't know the total while the cashier is still scanning items, and it's Costco, so it could be anywhere from $50 to $5,000 so surely it's getting the authorization after the transaction finishes? The flow is almost perfect. I have them scan my Costco membership, I use tap to pay on the card reader, then I or 2nd cashier move to organizing the items into the cart, and then the cashier hands me a receipt with basically zero wasted time.

They do have a very small menu though.

Yeah it definitely feels that way. I reckon it has a lot to do with the servers too though. Even netflix.com is far superior to prime video / apple tv+ browser versions. In fact it feels virtually identical to the app version.

I’m in Japan, with an English-language Amazon account, yet Prime insists on displaying Japanese subtitles on absolutely every thing I watch. Doesn’t matter what the original language of the content is, doesn’t provide an option to turn it off. Huge, bright white subtitles - much bigger than what Netflix uses. Been this way for years.

Sometimes I have fantasies about sending an email direct to Jeff Bezos just to say: dude, did you know about this?

Suffice to say, I don’t watch much Prime.

Netflix also did a bunch of deals with ISPs and essentially have mirrors of their catalogue in all the right places, and use machine learning to guess when different shows will be watched and shuffle around what they have in those caches.

Meanwhile Apple TV+ will just go ahead and try to use a super heavy 4k stream on my iPhone over 4G - won't even let me download it (at least this was the case a year ago, the last time I was out of wifi range).

There is one very niche area that Prime is quite good and it's their VR app. I have Prime on my Oculus Quest and they've really nailed the player itself, it's like being in an actual cinema. Netflix also have a very good VR app, but none of the other streaming platforms I use have put in any effort in this regard.

Prime has 4k UHD for free, while Netflix doesn't. For me, that's quite an advantage.

Also, given the choice, I'll rent a movie on Amazon because they even give refunds if they detect the quality was low.

Personally, I prefer Disney+ over Netflix/Prime as my experience is that Disney+ comes with more subtitles. Most of the time I can get Dutch subtitles while with Netflix UK that's not the case.

For me in germany prime always has instant, rock solid 4k.

Netflix also never stutters, but it starts with like 480p and gets better over time.

Nevertheless the Netflix UI is far superior.

You never used Disney Life, the decrepit predecessor to Disney+. Now that was a shoddy app. It used to forget your password every time it did an update (which was very often), it crashed all the time and didn't even have very much content. But I still subscribed because... kids. This is how they knew Disney+ would be a goer, they already had a lot of poor parents sending them nearly as much money for a TERRIBLE app with relatively little content.

Don't get me wrong, I still subscribe to all these services, because of the content.

But I'll always check Netflix for something to watch first because it's faster and easier (unless there's something specific I know i want).

Being the default first choice is very valuable, and speed is the reason they're it.

Content is more important than UX, but bad UX is a deterrent from enjoying the experience of finding or discovering what you want to watch.

I'm convinced my retirement gig will be writing nice, native apps for my platform of choice.

They won't bring in a ton of cash, but I can continue to make beautiful apps that are fast, focused, and respect the user's time and computing resources.

OUTLOOK! Jeez has it gotten slow on my mac. I am not a particularly fast typist, but I can routinely out-type outlook by a whole sentence. Moreover in the latest version, if I hit command-R and start typing it will routinely take so long to just start replying to a message that it will drop the first 90 characters I type. I've seen rumors that microsoft will replace it, and I cannot wait until that happens.

This is a specific nickpick but you won’t make me miss Outlook desktop. It’s crazy old and big, and for basic email stuff, its web app counterpart is much faster.

But anyway in the enterprise sector, it doesn’t matter whether an app is web or native, it will be slow regardless lol.

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.

Is it possible to use the web only as a platform to deliver the newest version of your native application?

- User visits website - downloads binary (preferably small size, use an appropriate language and cross-platform graphics library) - launches it (preferably without installation) - Perhaps creation of a local storage directory on the file system is needed the first time. - and voilà!

What would be the main obstacles to such a workflow? Are there projects who try work like this?

It is awful, but there are some positive tradeoffs like security and flexibility. For example, there have been a zillion vulnerabilities with native Office over the years. Visual Studio is a terrible pain to skin or customize its look and feel compared to VS Code.

The IDE is an extreme case of user interface.

You type in a letter and that starts off a cascade of computations, incremental compilation, table lookups, and such to support syntax highlighting, completion, etc. and then it updates whatever parts of a dynamic UI (the user decides which widgets are on the screen and where) need to be updated.

It almost has to be done in a "managed language" whether that is Emacs Lisp, Java, etc. and is likely to have an extension facility that might let the user add updating operations that could use unbounded time and space. (I am wary to add any plug-ins to Eclipse)

I usually use a powerful Windows laptop and notice that IDE responsiveness is very much affected by the power state: if I turn down the power use because it is getting too warm for my lap, the keypress lag increases greatly.

> DisplayPort adds delay over VGA

Surely VGA would have more latency than DP for an LCD? It's gotta convert from digital to analogue and then back to digital again at the other end.

Is the overhead of the protocol really greater than that? (genuine question)

MacOS' compositor is waaay worse than Windows'. On MacOS everything feels like it's lagging for 200ms.

161ms is longer than it takes to ping half way around the world. Amazing.

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.

And some video games with good hardware manages less than 20-30ms button to pixel response.

> Maybe add 1 more frame for the Windows compositor.

Months ago I noticed picom causing issues with keynav I was too lazy to find a (proper, pretty-window-shadow retaining) fix for, so I just killed it and — while I can’t confidently say I remember noticing a significant lag decrease — I can say I don’t really miss it (and my CPU, RAM, and electricity use almost certainly decreased by some small fractions).

Being a Go/C/Scheme coder makes me not tied to an ide, and it runs fast. Zero latency.

You pretty much nailed it here. It's not speed proper. It's the perception of speed. What the iPhone mastered was the transition starting right away. If you have no transition, the time to start, say, the mail app, will appear long, but since you started the icon blowing up to cover the screen right after your finger press was detected (by your brain) the delay feels shorter because you see something is happening. It's merely cosmetic - the app is still starting during the animation - but , to the user, the animation is part of the process.

I actually went back to normal speed. Sure, fast animations, but it makes stuttering more noticeable because there isn't a slow animation to cover them up. My phone is a bit old, maybe that's worth it if you have one of the latest flagships with plenty of computing power.

You can also disable animations in the same settings, but I found it broke some applications.

TY! I used to put my phone into low battery mode sometimes just to get the speed up from disabled animations.

I have Phillips Hue and Sengled lights at home and I usually disable the "easing" animation on them to reduce the perception of time delay when I push the button... It is maybe 100 of ms of perceived latency I can subtract.

It help a lot in that "computer user bill of rights" issue that you start to worry at some point that the button press wasn't registered and might then mash the button with unpredictable effects.

(e.g. you might get more customer satisfaction from a crosswalk button that doesn't do anything at all except 'click' instantaneously)

This is the first thing I do when I get a new phone. How the default is as sluggish as it is is beyond me.

This is just a PSA to warn people that this can fail: I just tried this in my lunch break. I have LOS 17.1 on surnia (old, I know).

These settings completely disabled my on-screen home button and other UI elements, and setting the anim scale back to 1.0 and rebooting did not fix that, no more home button for now.

I probably have to reset the phone, did not find any further info so far on how to fix it (pointers, anyone?). But the UI seemed snappy indeed at 0.5 ...

Edit: "other UI elements" including e.g. the Tab switcher in the Lightning browser. The widgets are all displayed, but totally unresponsive.

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).

Oooh, thanks for this. I just applied the animation scale on my Pixel 4A and it feels so much peppier.

Thank you. Feels like a new phone. Disabled all animations.

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.

>> Moreover, the delays make it impossible to do "learned" chains of actions

Yeah this resonates for sure. Multiple times per day i tell citrix ctrl+alt+break, down arrow, return (minimise full screen citrix, go to my personal desktop) and about 50% of the time an app inside the citrix session will be delivered the down arrow, return keystrokes :-/

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...

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.

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.

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.

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.

> Qt is as bloated as HTML-based UIs,

Bullshit. Qt is much faster than Electron, the Mumble client is really fast on my Turion laptop, that with OpenBSD.

And I say this even if I prefer Barnard IRL.

The problem with vendor-made cross platform UI libraries are that they:

1) Would need to be lowest-common-denominator by nature

2) Would quickly stagnate due to friction against changes/additions

3) Would have few allowances for platform HIGs

If it were permissible to have vendor specific additions on top of a common core, that could probably work fine otherwise this hypothetical standard UI library would share many of the problems suffered by Qt, wxWidgets, etc.

The other option I could see working is something like SwiftUI, in which some control over the behavior, layout, and presentation is ceded to the platform — basically having developers provide a set of basic specifications rather than instructions for every pixel on-screen.

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).

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

Your windows cursor shouldn't stutter unless you have io interupt problems, bad drivers etc.

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.

Microsoft probably should revoke Arkadium's right to use their brand name. Arkadium's worst of the worst ads and microtransactions, much less their poor attention to performance detail, really are making Microsoft look bad to a lot of users that just want to play Solitaire/Minesweeper/Jigsaw sometimes.

Especially after the walkbacks that Xbox Game Studios had to do after flak about scummy microtransactions in Halo, Gears, and Forza, it still seems incredible that Microsoft continues to allow Arkadium to do it to a far bigger audience (and a lot of people's parents and grandparents especially) with their brand name attached to it.

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!

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.

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.

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.

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

I know right? Learned helplessness.

Anybody else remember 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.

Reminds me of an old job writing Windows desktop software. Our flagship app was big and bloated, and it had a long load time with a nice splash screen to distract the user.

We later created a light version for a specific use case, and the product owner came prepared with a nice splash screen for this one too. The app was so lightweight that it loaded near instantaneously - so the engineer added a six second delay just to meet the splash screen requirement.

> 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.

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.

If you want buggy crap that's impossible to maintain filled with hacks to make something look like it works - game developers are the right choice. The requirements and practices in that industry are not comparable to standard app development and you would not want anything to do with that for app development.

People here crying about load times and FPS rendering are completely out of touch with reality of SW development - getting stuff to function correctly and reliably with requirements constantly changing > performance, and that's hard enough with tools that simplify SW development. Optimising for performance is a luxury very few can afford.

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.

Yeah, totally :D 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?

I disagree: think of how long it takes to bring up the PipBoy in Fallout 3. Or to open a door in Mass Effect. The amount of times I've had my character just be running into the door for multiple seconds before it finally opens...

And then they just end up using a middleware like Coherent[0] which is back to HTML+CSS!

https://coherent-labs.com/

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!

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.

It's because we let the product people in.

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)

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.

You are correct, it doesn't matter how will the improvement happen as long as it does happen.

If Electron is rewritten in C / Zig / Rust / whatever and becomes much more lightweight then I'll be on board about using it myself.

But the abusive relationship between today's software and what is essentially supercomputers has to be ended and started anew on a more respectful foot.

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.

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.

There's something wrong with your PC because nobody will be able to reproduce this result.

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.

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.

Agreed, Slack and Teams are particularly egregious examples.

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.

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.

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.

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

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...

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.

>I find the vanilla Android to be as snappy as iOS for daily tasks if not better.

"As snappy if not better" as an "old iPhone SE" though...

Using a OnePlus 7 Pro, and I tried this, and the sidebar closed instantly. How many apps and games do you have...? :)

(But yeah, this phone is super fast, and the 90Hz screen is a joy. I literally cannot switch to iPhone until/unless they get faster screens, because of post-concussion syndrome and the migraines I get from 60Hz screens.)

Fair question, here's some 2019 benchs that found similar latencies between high end Samsung and Apple devices: https://blog.gamebench.net/touch-latency-benchmarks-iphone-x... so it seems some Android manufacturers did manage to catch up finally.

I owned many Android phones over the years, beginning with the OG Droid. Had some Samsungs along the way, my last few were Pixels. My final Android phone was a Pixel 3, I switched to an iPhone SE 2020.

Maybe the total time to complete a given task is about the same, but I can seriously say I have never seen the iPhone drop a single frame. The Pixel got choppy all the time. Every Android phone owner knows the feeling of "why is my phone suddenly hot? Oh some runaway background service" or "why is this thing running at 5fps? Oh an app is auto-updating in the background".

iPhone just doesn't have these issues.

Personally I experienced a similar thing switching from a Galaxy S10+ to an iPhone XS.

Somewhat related: https://danluu.com/input-lag/

Good points about using good tools & analysis techniques - especially to get to latent sources of slowness.

But I'm not sure you can say that he's not profiling - he's using the end users' direct experience as the profiling tool, prioritizing the fixes by greatest annoyance.

Since he let himself get in the mode of being reactive, that's not a bad way out of the hole he dug himself.

Of course the best way is to design your architecture for speed, minimize all code usage & data transfer, use the profiling tools before release candidate status, and prioritizing speed & performance in the QA process.

More profiling is on the Trello board list ;)

I've done heaps of profiling.. pun intended :D

profiling is not a replacement for user feedback. You could profile some server side functions and see that X is 5 ms and Y is 8 ms. You will think all good, they're pretty fast. But the user might complain about a feature being slow, say deleting a thread, which happens to call the 5 ms function 50 times for some reason. You would then address the reason for so many calls, rather than optimizing the call itself.

Talking to your users is paramount, at the very least they will indicate where you have to add profiling

There is nothing magical about the iPhone especially not on the hardware side.

I don't know how but if you look at input response time charts, especially in the early days, the iPhone is among the best, if not the best by a large margin. Less abstraction layers? Better tuned OS? More attention given to latency? More trickery? Apple's level of integration and closed ecosystem certainly helps here, and I can easily imagine Steve Jobs pissing off every single employee that wasn't fired for the smallest hiccup. I am far from an Apple fan and I don't own any of their stuff but I have to admit that on some points, they are really good. And as a developer, I have a lot of respect for those who care about performance.

Your OnePlus 7 Pro is a beast. It is fast and smooth because it has quasi-desktop class hardware inside. That's the "solution" I was referring to.

To be fair, Android did work on smoothness. It was called "project butter". But IMHO, they still didn't manage to match Apple on equivalent hardware. I don't know about the situation right now but I hope everything is smooth considering the ridiculously powerful hardware they put in modern flagships.

The iPhone has used a 120hz touch digitizer for a long time, while Android phones have usually used only a 60hz touch digitizer. So while the screen refresh rate was only 60hz, they could start reacting and creating the animation sooner.

Thankfully JSC is also really REALLY fast, but interacting with websites is slow.

>I remember a recent tool posted here (I think for OS X: maybe an editor) here by someone who was fed up with this extreme "input lag" and was guaranteeing his program would be answering in less than 16ms (maybe was it 24ms, don't remember exactly). But that is an exception.

Mac OS 9 Lives praise Mac OS 9 against OSX because of that.

http://macos9lives.com/

Similar anecdote: I recently investigated tablets to use for drawing.

Everybody online said the non-plus-ultra was the iPad Pro, even compared to other name-brand devices from Samsung/Microsoft.

So I tried them both, and wow. 120fps and a screen optimized for low delay really makes an enormous difference.

With all other tablets, it was more a question of "well how more or less awkward does this feel to use", where that question didn't even come up with the iPad.

I know this sounds like shilling, but I recommend just trying it out on a real device sometime, even or especially if you have no intent of buying one.

I still play games in =<60fps, I see it like training in a gravity room ;)

Jokes aside, I'm happy I haven't had the same experience as you for gaming. Because then I would have to buy into high performance gaming. I can now happily play a game on something like Stadia or my old Macbook without having to feeling something is wrong or missing. Kinda like how watching movies on VHS was fine until HD came along. Now every artifact or resolution drop in a video is an annoyance.

My setup gets 20 fps in TF2 on a good day :(.

Its easy. You deliver the feature and then optimize its performance.

What they dont say is that there is never an end to set of feature requests you will get. No matter how many crappy, unusable features you throw in, there will always be a request to tweak this , tweak that.....

"Developers have expertise and know what they're doing."

Unfortunately this is not always the case. Currently there are other "developers" getting access to our sql servers that drag down performance a lot. It looks to me that they may be coming from an OOP world and now trying to force these patterns onto sql which doesn't scale at all.

So developer != developer and not all developers are good imho.

I think it might be necessary to just frame speed as a problem everyone can relate to, Ferengi as well as developers.

One possibility for speed as in latency would be to pre-agree on a latency budget (as in realtime-systems: if you exceed that deadline, your system has failed). Then have everyone be aware of how they spend that latency budget. Say the latency deadline is at 500ms for your website to full interactivity. Currently you are at 320ms. Marketing wants to include some analytics scripts. Include them in the test page, measure the added latency, then check against your deadline: added 200ms, we are now at 520ms. Do we reject marketing's wishes or do we make the design dept. cut back on their image load times, maybe they can get from 130ms to 90ms? How about investing in better caching to get 100ms?

That way you can discuss numbers and can quantify how something impacts the overall experience. Budgets is something everyone can understand, and taking a big gulp out of a limited budget is something no-one wants to be seen doing.

> Customer needs should be driving what gets added.

In enterprise, the "customer" is going to be someone who will almost never touch the product once they've signed off on it. Building something that's a pleasure to use (good UI, responsive etc) for the end-user is usually wayyyy low on their list of priorities.

Microsoft Teams isn't designed to compete on technical merit, it's designed to appeal to bean-counters who have either never used anything better, or have not used and will not use the software at all, thus slowness isn't an issue because the people it would affect (the end-users) have no say in the matter.

No opinion on Bluejeans nor Webex but I assume it could be the same as above.

Zoom isn't actually that bad. UX-wise it has some issues but speed-wise it performs better than everything else I've tried (probably helps that it has a native app instead of being browser-based or Electron garbage).

Skype is a consumer product and is left to stagnate more or less. Most likely, they don't see enough profit potential in it to make it actually better (which would involve throwing away the Electron crap and rebuilding a - or dusting off the old - native app).

Having used Teams, Zoom, Skype, Google Meet and Jitsi, I'm having a very hard time understanding why people go through the pain of Teams, Zoom or Skype.

Jitsi and Google Meet don't employ any dark patterns, they are fast, they are reliable, they are easy to use. (I do use them only in Chromium.)

Zoom desperately wants me to download their client, even going so far as to require multiple failed attempts before showing the button to join using the browser. Then it wants me to complete a CAPTCHA before letting me join. If I do use the client it opens several separate windows and asks if I want to join using desktop audio. (Of course I do, and if you still want to ask please keep it in the main window.)

I rather think most devs have overpowered hardware for developing - and simply don't notice performance drops directly on consumer hardware.

Hacker News is affiliated with YC, a startup accelerator. While there are lots of FAANG engineers and engineers from all parts of the spectrum here too, this community biases towards startups. If there is a place to discuss strategy for pre-PMF startups on the internet, this is it.

I’m not intending to generalize, quite the opposite. I’m arguing against a generalization that “speed is the killer feature [for all products]”. In my post I presented a few cases where this over-generalization is not true (pre-PMF startup and potentially large B2B product) and suggested a more nuanced and objective analysis of the trade-offs.

> You are speaking in generalities, so you are essentially implying that most people are working on software that has not achieved product market fit?

Perhaps try parsing my post as “here are a few examples of common cases where speed is not the killer feature, and a sketch of a more flexible thought process that will get you to a better answer”.

Product managers at both large and small companies use ROI and experimentation to figure out what to build (though in some ways it’s actually harder at a startup as your sample size can be too small to get statistical significance, or at least to run as many experiments as you’d like).

If you have 10 companies to invest in, each of which has a 10% chance to produce 20x returns, 90% of the engineers at these companies wouldn't really have users.

Basically, if you think that software is feast-or-famine as an investment, then this would make sense.

Also AFAIK, iPhone was first mainstream device with multi-touch.

At the time I had limited experience, but personally I thought touch screens would never work, because they were slow, imprecise and unresponsive (often worked with special pen only) and then iPhone came with buttery smooth experience and multi-touch. Mind blown.

No, HTC was the first one to explore a touch only interface.

Even before the HTC Touch, their WinMo version allowed for touch only operation for 3-4 years.

It's a joke. I'm not enough of an idiot to create a trivially manipulable security.

I didn't mean "more features are better". Sometimes, even a single killer feature is better than many features. Speed might be one of the reasons Iphone's success but how about this : If Iphone's were %20 slower than they were, would it take over the market ? I think it would. This doesn't mean being fast didn't help them. My point is, being fast is not enough all alone but being fast with a good feature set is great.