
Can modern software be snappy? (2008) - avasthe
https://blog.brush.co.nz/2008/06/snappy-software/
======
bob1029
I feel that many times my source of fatigue can be traced back to my tools
being laggy pieces of shit for no good reason.

I don't understand what prevents actors like Microsoft from doing a clean,
lightweight, native rewrite of tools like Visual Studio for people who are
looking forward into the .NET 5 horizon, and don't care about being able to
debug VB.NET apps written in 2009. There is no reason there has to be any
delay at all in the UI. Graceful degradation of intellisense is acceptable
depending on project complexity, but there should never be any sort of
perceptible hitching or delays when moving code windows around, scrolling,
typing, switching tabs, minimizing/maximizing, etc. If my PC can display the
complex 3d scenes of Overwatch at 2560x1440p@180FPS with <5ms input latency, I
cannot comprehend any rational argument for my IDE being unable to achieve
even 10% of that performance objective.

I understand that use of frameworks like ElectronJS make it virtually
impossible to achieve my stated objectives, so perhaps we need to dust off
some APIs and re-learn old tricks. Think about the aggregate developer hours
that could be saved with 1 heroic implementation effort. Imagine if you could
load a VS solution in less than a second and immediately start clicking
through the UI in any direction without any fear that it is about to sandbag
your ass with frustratingly-arbitrary UI delay soup. That is the kind of UX
that inspires confidence and encourages a developer to charge forth, instead
of compelling them to fuck off on HN for the 20th time of the day.

~~~
pjmlp
React Native for Windows/macOS team keeps showing performance charts where
Electron has a 300x performance loss against React Native.

I keep wishing for the day that VSCode team finally replaces its engine with
one based on React Native and then Electron gets its first fatal blow.

Meanwhile, [https://www.windowscentral.com/xbox-app-pc-gets-speed-
boost-...](https://www.windowscentral.com/xbox-app-pc-gets-speed-boost-
ditching-electron-react-native-uwp)

~~~
coldtea
> _I keep wishing for the day that VSCode team finally replaces its engine
> with one based on React Native and then Electron gets its first fatal blow._

Which would be never, since tons of VSC functionality is based on the ability
to create ad-hoc widgets (through HTML).

~~~
pjmlp
Ad-hoc widgets can be equally easily created in React Native.

~~~
coldtea
If you mean combining a few existing ones to make a custom component and
adding some style yes.

If you mean ad-hoc widgets, the kind you can create in HTML or a native UI,
then no.

~~~
pjmlp
Yeah, because React Native is frozen in time without any extension API to plug
into.

~~~
coldtea
Yeah, because "extension API" != "easily" as in HTML...

------
darkhorse13
Sublime Text is one those modern tools that I would call snappy. I pray that
it stays that way. I tried Atom once, but every key press had tiny lag, drove
me insane.

~~~
ben-schaaf
I can say with confidence that Sublime products will always have a focus on
performance. We generally treat any performance issues as high priority and
you can see the result of that with most updates shipping some kind of
speedup. Sublime Merge 2 for instance has shipped GPU rendering which has seen
massive improvements at huge resolutions like 8k. Disclaimer: I work for
Sublime HQ.

~~~
badhombres
1\. I can say I really appreciate the fact that you guys focus so much on
performance.

2\. I understand that sublime is closed source and respect that, but would
sublime ever release or talk about how they develop their GUI? What libraries
and techniques they use?

~~~
ben-schaaf
There's a fair amount of information scattered around about how parts of our
GUI toolkit work, but there may be a blog post or two about that in the
future. In general though it's not a particularly novel design on the toolkit
end - the basics are all pretty similar to others. We just tend to put a lot
of effort into making things work well and work fast.

------
skizm
Notepad++ is still one of if not the best and most reliable pieces of software
I’ve ever used. Better than sublime IMO. VLC coming in at a close second.
These two are probably the last “snappy” pieces of software I use, besides
maybe terminals.

I’m sure there are others but these are the two the come to mind.

------
jacquesm
That's quite timely. I'm writing a soft real time piece of code for use in the
browser. It's a nightmare. So many layers underneath that it is very hard to
get any kind of idea where latency and throughput issues are coming from.

~~~
PaulDavisThe1st
>soft real time piece of code for use in the browser

Maybe you should reconsider.

My definitions:

    
    
        * hard real time: people will die or things will be destroyed if a certain block of code is not executed within N msecs of something happening
    
        * soft real time: nobody will die but things only really work correctly if a certain block of code is not executed within N msecs of something happening
    

Why anyone would think that a _web browser_ (equipped with whatever VM
abstractions you care to name) is a suitable platform for even soft real time
is completely beyond me.

I write soft real time for a living (a multiplatform DAW). We have to go to
great lengths to ensure performance, and we do things that you will NEVER(1)
be able to do in a browser.

(1) for any reasonable definition of NEVER

~~~
svantana
That sounds overly dramatic to me. I'm writing a DAW of sorts for the browser,
and while I wouldn't use it on stage, it works well enough to produce music
on. I didn't even add AudioWorklet support yet, and I will probably release
without it and consider it if users complain about stutters etc.

~~~
renaicirc
Have you tested on a variety of platforms? In my experience, some are very
good about this (e.g Chrome on macOS) and some are a common source of problems
(e.g. Firefox on Linux, at least with PulseAudio).

~~~
svantana
It seems to work well on the popular platforms (chrome, safari, ios, android)
although I haven't tried linux yet. Wasm performance can vary between browsers
though, which will impact the experience a lot.

------
quelsolaar
Fast software is not the same as small executable. I don't care how many
instructions an executable contain, I care about how many are needed to be
executed to do what i want. There are plenty of times where a larger
executable means faster execution (Loop unrolling is an obvious example).

There are plenty of reason why a lot of modern software is slow, but size of
executable isn't even in the top 10.

~~~
PaulDavisThe1st
It does have quite a bit to do with slow _startup_ , however, which was also a
part of the author's complaints.

------
pjmlp
Depends, how much Electron instances are you running?

[https://mspoweruser.com/xbox-pc-app-gains-huge-
performance-g...](https://mspoweruser.com/xbox-pc-app-gains-huge-performance-
gains-after-abandoning-electron-framework/)

------
sys_64738
It's cheaper to buy faster computers nowadays. Code optimization for speed and
size is a lost art as the programming world is filled with layers and layers
of libraries and frameworks nobody knows what happens under the covers.

~~~
pbourke
Sometimes it’s not possible to buy your way out of the problem with better
hardware. If the issue is locking, or inefficient data structures, or
interpreter overhead then there will be a floor to your gains. That floor
might be quite high, and throwing hardware $$$ at it might not lower the floor
by much. Web browsers can be pigs on core i5’s and monster Threadrippers.

------
jdc
cf. Dan Luu's page on computer latency:

[https://danluu.com/input-lag/](https://danluu.com/input-lag/)

