How much your computer can do in a second

Yeah, spot on. What's really important is answering the question of what's necessary, that's really the key. Sometimes you do know that optimization will be necessary in the future even when it's not needed right now. If that's the case, the earlier you attack it, the better. But all of us (me included) tend to spend time on things we believe are necessary that turn out not to be.

> For these situations its like taking a loan for technical debt. In the future you may need 10x the resources to fix but in many environments that's acceptable

Definitely. There is the gamble that if you don't know for sure and you wait it might cost a lot more later. But I would go a lot further than that. The problem is that if you take the other route and optimize early on the wrong thing, it makes optimizing the right thing 100x more expensive in the future, not just 10x. It can be more expensive to optimize the wrong thing than it is to optimize the right thing late. This is because optimizations often require a different way to slice the code, to feed the limiting system with a different batch size, or to invert your high-level looping structure and swap the inner loop and outer loop.

If you've ever done image processing in Python, I always think of numpy vs PIL as a good example of slicing your batches a different way -- if you do it the easy way in PIL, you can write cool stuff in an hour, but your code might take 60 seconds to run on an image. PIL loops over pixels, and you put complex ops inside the loop. Numpy is opposite, you put the operations on the outside, and the loops on the inside (to allow the loops to be run as native compiled code). Numpy's harder to learn, the code is inside-out from PIL, it takes longer to write & debug, but something that takes PIL 60 seconds will take less than 1 second using numpy.

Most of my serious optimization efforts in C++ have ended up feeling very similar to the PIL vs numpy issue, and what happens is that it takes a ton of effort to optimize the right way because I have to invert my whole program's structure. When I've done that only to discover I didn't optimize the right thing, it's a huge mess to un-invert and re-invert the right way.

> I've been amazed what the top engineers in the field can design and implement getting things right the first time without additional effort. Simple, minimalist, high performance implementations that don't sacrifice much.

Same here, some people seem to hit the right balance with less effort. Sometimes it's experience and good guesses, but often (from what I've seen) it's because if you watch the best engineers work, they spend more time communicating up front to make sure they're doing what's really needed, and they spend more time checking their assumptions as they go, writing tests, profiling, and talking with their peers and their management about what they're doing. They're able to recognize quicker when they're spinning their wheels on problems they want to solve, and not problems that the team or product really truly needs solved.

We're using the shittier tools from the 70s, because the better tools died off - which is sad, because we still didn't manage to recreate some of the features those tools offered. The success of UNIX and C seems to be caused by the same phenomenon that causes Electron to succeed and bloat to proliferate - what wins aren't good solutions, but those which get popular quickly.

Oh if you need the pixels back, you can certainly get them using glReadPixels(). It's a bit expensive in WebGL land, though it is much less expensive than looping over pixels using JS. And often there are ways to get around needing the pixels back, depending on what you're doing.

You can also do loads of non per-pixel tricks, including filters that need the surround, using multiple passes and clever shaders, you are not as limited with WebGL 1 as you think.

https://5013.es/toys/dithering/

https://www.shadertoy.com/view/MslGR8

This is what I'm talking about, you have to slice your program differently if you optimize it. Your high level structure and outermost loops will look different if you use WebGL instead of JS. And yes WebGL 2 is even better.

But, this is all much trickier than writing your straightforward loops in JS. That's the price you pay for performance, your architecture will be kinda crazy if you do it in WebGL, and it will not be easy to go back if you discover you optimized for the wrong thing.

To pick on your example - it is interesting that you have to go back 20 years to find a feature beneficial for the everyman, and that you are still wrong: Just about every word processor starting from MS Word 95 came with inline spell checkers. (And indeed I prefer the snappiness and identical feature set of my copy of Office 2003 to the ribbon-laden gigabyte-guzzling mostrosities of Office 201x, just as I prefer a 15-year-old Winamp to the latest Itunes player.)

"O(0)" is pretty much meaningless.