I think you're right. Performance profile shows lots of long spans relating to that element, and deleting that element makes the page scroll much more smoothly.
There are still other issues though. The performance of this page feels pretty bad in general.
1. Click the box in the bottom right corner to create a cell.
2. Click the box just to the left of that one to create another cell.
3. Drag the cell you created in step 2 to the right. The cell on the bottom right gets pushed downwards, below the grid's lower boundary.
There's a pretty popular `python-is-python3` package in Ubuntu which aliases `python` to `python3`. I used to install that in my dev environment setup scripts, but have since stopped using it for the reasons you mentioned. I've found it best to think of Python 2 and 3 as totally separate languages, so I consider it a good thing that the binary name python3 is unambiguous in all contexts.
Yes, and those work well for smaller workloads, but if you just run 1,000,000 commands with `&` in a `for` loop, it will grind your computer to a halt (if the tasks are modestly resource intensive). GNU parallel will let you run those same 1,000,000 tasks but make sure that only (e.g.) 16 of them are running at once. It's not easy to do that in bash.
The "Problem #2" that they mention also has an easy solution.
If the "intermediate" variable / internal representation is just "the input image but with edges only," then of course you can see internal representations.
When you compute that intermediate variable for the line drawing, it will just happen to behave like the identity function for that particular case. So if you have already filtered out non-edges then the transformation is basically a no-op.
The "types" mismatching
as they mention is not a concern because the type is just "image" i.e. a big vector of HSL values or something. Edge detection is just a convolution filter so it's going to have approximately the same type as the input.
There's an option to output a yarn-compatible lockfile. In practice, I think this means you'd need a branch protection rule to disallow a change to the binary lockfile without updating the yarn lockfile. I'm not sure that complexity is worth the performance gain of the binary format, personally. I think Bun should have an option (maybe in bunrc) to always use the human-readable format, though that detracts from the "batteries included" nature a bit.
I wonder how much of the time is spent in the onclick handler. Each of those clicks has to wait for the onclick handler before the next one executes, IIUC?
I'd guess that was intended to be captured with "how valuable is the feature to target users, truly?" If target users truly find the feature valuable then I guess that means the feature is adding value to the company.
I think the word list could use some polish -- the first word it gave me was RAMCE which I have never heard, and Google didn't think it was a word either.
I don't know for sure, but I imagine that for something like Slack which already has to support multiple browsers on multiple platforms (because it has a browser version as well), not shipping a browser seems like it could be a reasonable choice.
Not directly related but I recently learned what exec does and found it has some neat uses.
When I see tutorials that tell me to run `. ~/.bashrc` after adding something to my bashrc, I run `exec bash` instead. Less finger gymnastics, and cleaner.
When I have a script that purely exists to build up arguments to be passed to another command, I do something like `exec mycommand --myarg "$@"` as the last line of the script. No unnecessary bash process lingering around.
There are still other issues though. The performance of this page feels pretty bad in general.