ctidd

It’s called layout shift.

This is an inherently inefficient design, where that inefficiency means increased 1) battery use and 2) tire wear.

From a cyclist’s perspective, this is fundamentally a stopgap product for “curious” customers dipping their toes into e-bikes. I don’t say that necessarily to criticize it. There’s a place for a product that someone can put on any old bike and see if they want to buy a more expensive long-term solution. But that doesn’t make it a product I’d recommend.

The tire wear problem is significant enough that there are heat resistant tires specifically for this type of drum application (designed for old-style indoor trainers, not for use on the road), because use on a drum will cause premature wear for normal road tires.

It’s a very strong convention in bicycle photography. The drive side is considered nicer looking, it’s where you get to show off the components, etc.

Independent of what humans may do with the same prompt, training datasets will be full of traditional bike photos, which will all be drive side.

It’s also one of the easiest yellow flags to look for in used bike listings (not low-end, but anything enthusiast level). If a bike is photographed on the wrong side, there’s a non-negligible chance it’s stolen, because the seller is presumed to know better if they’re an enthusiast themself.

There are multiple MIPS systems. The early ones were like you described, with a distinct feeling of too much plastic. Newer ones (e.g. Integra) are much more seamless. There are also other companies doing different types of rotational tech, like Lazer with an integral foam-based shearing design.

If you have only tried first-gen MIPS, I recommend giving it another shot.

CSRF can compromise the non-mutating path as well to exfiltrate data, but the mutating path and non-mutating are different, hence the OPTIONS preflight required prior to sending mutating requests.

The browser enforces the same-origin policy by preventing read on non-mutating (i.e. “simple”) request responses and preventing sending of mutating requests (i.e. non-“simple”). CORS provides a protocol for a service to loosen these controls.

All CORS does is allow for selective loosening of anti-CSRF controls. CORS is a mechanism for a service to tell a client “I’m CSRF-resistant” so that that the client doesn’t need to protect its user as tightly when interacting with that service.

CSRF exists as a consequence of insecure-by-default browser handling of cookies, whereby the browser sends the host’s cookies on requests initiated by a third-party script to the vulnerable host. If a script can fake all headers, it’s not running in a browser, and so was never exposed to the insecure browser cookie handling to be able to leverage it as a vector. If no prerequisite vector, then no vulnerability to mitigate.

You want lax for the intuitive behavior on navigation requests from other origins. Because there’s no assumption navigation get requests are safe, strict is available as the assumption-free secure option.

CSP is a defense in depth mechanism which can be (among other capabilities) used to preempt the capability of inline scripts. This mitigates rendering bypasses, in the event that unsafe rendering occurs. For example, imagine you have an insecure markdown renderer, where a user can manage to escape some HTML and inject it into the DOM in a comment thread of some sort. If they can do so, then they can embed JS inside that HTML and get XSS on other users. Adding a rule to disallow all inline scripts mitigates this, assuming the first layer of defense fails.

> Similarly, why is an online event handler considered a security risk? I just don’t see the difference between that and using a named function?

It is a vector for script injection, and should be disallowed with a strong CSP (no “unsafe-inline”).

Putting the blame on cyclists for dooring requires missing problems up the chain which cause them to be in the door zone. Road designs (marked bike lanes that are 80% or more in the door zone) and automotive traffic overtaking unsafely are two contributors that directly or indirectly push cyclists into an unsafe space.

To ride out of the door zone in many cases requires taking the lane and riding outside of a marked bicycle lane, if present. Cyclists can and should do this, but it is no surprise that many don’t, and it is no surprise that drivers complain of those who do.

The implicit premise in this argument is that safety is an add-on that you buy or install like an antivirus package. If we designed to encourage less dangerous forms of transportation from the start, there may be cost savings that aren’t surfaced in the “add-on safety” cost calculation.

The other part of this decision not to protect human-powered mobility (pedestrian, bicycle, wheelchair, etc.) is that we allow or encourage automotive traffic as a constant, and _then_ we choose not to protect people. It’s a two step process where we make an active choice to create danger and then a second choice not to mitigate the danger.

I want to respond to this constructively, because you highlighted a useful interface I'd never taken note of previously; maybe we can focus this discussion on a technical level. Meanwhile, if you haven't had a positive response to technical feedback directed to JS engineers about this, I would encourage rereading the comment you wrote. I genuinely hope this is useful feedback, as I very much value insight from other languages and levels of abstraction, and I'd love for you not to get turned off to sharing that insight by a bad response from JS engineers. JavaScript is high level, and it's too easy to get disconnected from all of the work the engine and underlying computer are doing to make a program work in this environment.

---

As I understand the interface, practical use of the EventListener interface boils down to the implementer performing a form of event delegation, where you'd wind up delegating from a single `handleEvent()` method on a class to handle different event types and/or events with different target elements -- as opposed to a single click handler in a simple button click example. I'd love to understand and quantify the benefit of this. If it's a significant improvement, it'd be doubly unfortunate, as many callback-based interfaces in JavaScript APIs and libraries at a higher level don't support such a model.

Assuming there's a strong benefit, I also wonder if there's an opportunity for build-time tooling to rewrite code from ad-hoc callbacks to more efficient delegation along these lines. Tangentially, I also don't know about `Function.prototype.bind` vs wrapping arrow functions in terms of performance; that's also something I'm curious about, as they're often a 1:1 analog.

I'm tempted to test a few of these things out myself, but if you have references, that would be helpful.

As a heads up since you mentioned "class method syntax", methods are one of the most important places to have lexical `this` binding in many scenarios.

Take the following example, which is a normal class method:

> alertSum() { alert(this.a + this.b); }

And here we have an arrow function used to create an instance method (just an arrow function assigned to a property on the instance):

> alertSum = () => { alert(this.a + this.b); }

Then let's say we want to pass the method directly as callback:

> this.button.addEventListener('click', this.alertSum)

The first example (class method syntax) won't have the necessary `this` context unless it has its context bound to the instance through `Function.prototype.bind`. There are other patterns to avoid this (e.g. wrapping all callbacks in arrow functions when passing them), but it's useful to consider that classes methods can easily create confusion because that's _exactly where_ someone more used to a different language may assume the `this` context is bound lexically.