That's incredibly concise. I see you're perturbing vx and vy randomly and updating location accordingly on every frame. Is the perturbation also per-frame or is that block of code just executed once? Is randomf a floating-point number between 0 and 1?

After all, there are 6000 particles in total. Their positions are updated depending on the speed at every frame. Also the speed of each particle changes because of the gravity. Only the oldest about 30 particles, which have already fallen down, are shot away again from the position (50,0), whereby the position and the velocity vary slightly. Yes, randomf returns a value between 0 and 1.

This is really cool. Do you also plan to show the code before compilation / allow it to be edited and be compiled on your demo page?

Thanks. As for the code compilation, that can be tested and seen in https://sucrase.io/

The demo page is only to show how we can transpile JSX in browsers.

Your point of view is very clear: it's not a feature you're interested in. But it doesn't mean that it's not a good feature for the person who has opened the issue.

Instead of convincing them that it's a bad feature or talking about why it's uninteresting to you, just point them to a CONTRIBUTING.md and stop engaging with them after that. If they're actually serious about the feature, they can implement it in their own fork (which then you can request as a PR if you want it in your repo).

It's useful to know who they think the book is written for, to get the most out of the book.

Books are not individualized, so it's a very difficult ask to publishers and writers to write something in that section that perfectly applies to you.

You're right! Even I tried to post it. This is what I observed:

1. After posting, I'm redirect to https://news.ycombinator.com/newest where the link works 2. I click to open the discussion, now on this page link no longer works 3. Going back to /newest, the link no longer works!

looks like a class 1 problem

Would you rather implement `leftPad` or use the npm package?

I'd use standard String.prototype.padStart. For anything more complicated, but not too complex (say "libraries" with 100-300 lines of code), it's very tedious and time consuming to find something on npm that satisfies the specific contraints of my app precisely. This certainly fits in that category.

For libraries above 1-2k lines of code that can be quite complicated (eg. things like database connectors), it starts being reasonable to mold expectations of my app around the library.

Also using coherent large utility libraries is something worthwhile (or was in the past), libs like underscore/lodash, etc.

But composing app from random underdocumented 2 function "libraries" from npm is just pain if you know what you're looking for. 1) you can't trust the code, so 2) you have to read it anyway and reading is often slower than writing

Searching for a package on npm is more time-consuming than writing 300 lines of code? Perhaps your app has some very specific constraints, but for a simple library like this, I have a hard time believing you could code something up on the fly faster than it would take to npm install the package in question.

I have absolutely written a diffing algorithm like this faster much than it would take to find an appropriate version on npm.

Every so often I try to reach for an npm library, only to find out that it's suboptimal, doesn't handle my edge cases, or just plain worse than the code I would have written.

The last time I tried to do this, I wanted a hash map with custom equality functions on the keys, since JS doesn't have one built-in by default. I searched for about 2 hours and didn't find a single one that actually worked (several claimed to be, but actually didn't work...)

So I wrote my own in about 100 lines. [0]

Data structures and algorithms tend to be really awful on npm.

[0] https://github.com/magcius/noclip.website/blob/master/src/Ha...

In the long term, having to manage all these dependencies, keeping track of incompatibility, testing updates, or worse, the lack of management, is time consuming.

For trivial functions, I'd rather just copy them into my source code.

Let's say I maintain dozen of packages, then I would rather like to write it once and include it everywhere. I could copy and paste all the common functions instead of including, but if I notice a bug or have to upgrade the code for some reason, then I have to edit the code dozen times. But if I only have to maintain one package, then I prefer the copy&paste approach.

the titled should be updated to say "the Linux community" at the end, as on the original page

The original title was too long

1. Would it be correct to describe memoized DOM approach as combination of direct manipulation (like hand-written jquery, or what svelte compiles to) + a mechanism to avoid invoking selectors by caching references to DOM elements? Or is there more to it?

2. It'd be a good experiment to separate out the memoized DOM implementation from imba codebase in a way it can be used by different frameworks, just as virtual DOM libraries got popular after react. If someone were to attempt this, where would you recommend that they start with the imba codebase?

Suggestion: title should be renamed to "Protocol Oriented Programming and Testing in Swift".

"Swift Protocol" is something else entirely https://docs.openstack.org/swift/latest/