Tagged “performance”

Performance baseline has shifted quite far up (especially network) but targeted features are still quite far behind current

Great writeup, and fun to go through the questions and explanations. I really went off the rails with grep and parsing estimates, others were mostly solvable.

HN Discussion has people alternately arguing about whether modern programs are fast, or bloated and slow.

I don't think Moore's Law is an excuse to not worry about program performance, and the current slew of slow apps (web and otherwise) is not acceptable. Many electron apps really do feel slow. Waiting for my password manager to open (either electron app or chrome extension) is frustrating. It's minor, but it's friction to something that needs to be frictionless.

That isn't to say that can't be made fast. VSCode is a good example - that uses electron but has remainined very performant. They got boot up time down real low (actually relevant for me as I open/close sessions often). BUt on my older laptop (4gb RAM) I can't have it open alongside browser, so mostly use editors in the terminal. It does still mostly work, but they have focused on perf speed rather than footprint. Still some tradeoffs to be made there, and again another hard thing to think about.

There are definite costs to the abstractions, but also benefits. But none of this is free. Perf is hard, and computers being faster doesn't mean we don't have to think about it - time has been unchanged. Only our expectations have (of features and speed).

I really like the original one, and this is a solid reply

Lot of good parts

The high performance parts aren’t React. Mapbox GL, for example, is vanilla JavaScript and probably should be forever. The level of abstraction that React works on is too high, and the cost of using React - in payload, parse time, and so on - is too much for any company to include it as part of an SDK. Same with the Observable runtime, the juicy center of that product: it’s very performance-intensive and would barely benefit from a port.

The less interactive parts don’t benefit much from React. Listing pages, static pages, blogs - these things are increasingly built in React, but the benefits they accrue are extremely narrow. A lot of the optimizations we’re deploying to speed up these things, things like bundle splitting, server-side rendering, and prerendering, are triangulating what we had before the rise of React.

todo

watching/waiting for node deps to install almost causes me physical pain

You don’t have to be a genius to write fast programs. There’s no magic trick. The only thing required is not building on top of a huge pile of crap that modern toolchain is

Users: Please complain more about slow programs. Its 2016. We carry supercomputers in our pockets. Its simply not ok for apps to be sluggish.

It is no longer 2016, but nothing else in this piece has changed :(

Possible counterpoint: if the text doesn't render due to slow perf then readability is also affected.

Though only comparisons of text-rendering: optimizeSpeed; vs optimizeLegibility are from a while ago, unsure
if this is still a legit perf issue anyway.