ctidd

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.

The goal makes sense, but more specific questions can get substantially better responses. An example of what I'd find to be a more effective line of questions with a similar goal:

1. Is there a substantial technical or organizational change your company/org/team is currently executing? (Choosing scope based on who you're talking to.)

2. (If not) What was the last one you executed successfully? (Alternative: unsuccessfully)

3. What problem is/was this change aiming to solve?

4. Did the change introduce an anticipated or unanticipated tradeoff?

The goal would be to understand what the company currently or recently found challenging and what they're motivated to solve. It can also gauge the company's realism in evaluating the outcome.

Can you acknowledge real problems and tradeoffs, drive a change, and know when it's accomplished (or when it's time to rethink it)?

Forcing your children to eat things they aren't comfortable with is not a hack. Please do not do this. There is a significant difference between providing a positive environment for your child to encounter new foods and forcing them, physically or otherwise, to eat them.

As a counterexample to consider, I would suggest that a client-side web app is coupled to any remote data source intrinsically by a latency-sensitive connection over the network. As soon as you have enough data, you need to defer portions of it and load them on demand based on user interactions. So now the ways in which data was or wasn't factored in a way that mirrors the app impacts it.

Now, there are tradeoffs we can make to deliver an end state to a user: we can normalize and incrementally hydrate the data shown in the client and increase visible jank in the process, or we can realign the app's experience and/or data source around each other.

Decoupling UI components from business components is of course valuable, but that's different from taking that a step further and decoupling business components from the data source. The latter is a significantly more challenging proposition.

Also, there's some fuzziness here in what we mean by decouple. REST vs SOAP vs GraphQL as transfer layers can be abstracted away as implementation details, but I'd place a higher emphasis on the shape of the data and how it has to be traversed in the client. If you have a paginated list, for example, and you only want to load it once, but you need to display both a summary and load it incrementally, things can get complicated as more functionality is built out from that starting point, regardless of transfer layer.

If I follow your statement, it doesn't appear correct. JS Promises are eager, and the work underlying the promise will begin executing prior to being awaited. Await is just blocking on that execution's resolution.

    // Given:
    const fooPromise = asyncFoo();
    const barPromise = asyncBar();

    // Then this...
    await fooPromise;
    await barPromise;

    // ...is equivalent to this:
    await Promise.all([fooPromise, barPromise]);

If you're not familiar with the term, this image viewer pattern is generally called a lightbox rather than a carousel. I generally don't see the two used interchangeably, but there's similarity to the prev/next controls, of course.

Since you provided a concrete scenario, I should probably do the same to clarify what I'm referring to in re-parenting or hoisting hooks. It doesn't really map to the statement "replace a global store with localized hooks", so I'm probably doing a poor job communicating. Similarly, I do not assume "you can simply replace a global store with localized hooks", because like you say, that's not true, and I can appreciate you clearly understand how hooks work.

At the same time, unless I'm really misunderstanding the example you shared, I can't see the problem or mental overhead you're mentioning where we need to be vigilant about having the same hook used in multiple places or understanding the scope of the hook's "local" state and callbacks. That's the point of hooks as a unit of encapsulation -- just like with a class, each use of a hook is a different instance, and the scope is that of the instance (and hook instances are scoped/bound to the lifecycle of the containing component instance). The code in the problem you showed is equivalent to calling setState on the one component instance and expecting that to show up on another instance which happens to be of the same component class. If we understand how React component instances work, that's clearly not the case (state isn't broadcast across instances), and the same goes for hooks.

Looking at what I mean by the improved portabiliy/hoistability of hooks I mentioned in previous comments, let's say we have three components: App, Foo, and Bar. App renders Foo and Bar as children.

We have a business requirement that Foo has some behavior which contains multiple pieces of state and bindings to multiple React lifecycle events (e.g. mount). What we don't know is whether we'll ever need to share that behavior with Bar.

React class API: We need to write bindings for this behavior against class state and lifecycle methods, intermingled with other code. This intermingling means you know there's a good deal of refactoring to do to move the behavior upward to App if we ever need to share the behavior with Bar. As a component grows, more and more logic intermingles on those lifecycle methods and makes refactoring more challenging.

  class Foo extends React.Component {
    state: {
      behaviorState: {...},
      unrelatedState: {...},
    };

    componentDidMount() {
      initBehavior(this.props.input);
      initUnrelated();
    }

    ...
  }

  const Foo = ({ input }) => {
    const behaviorState = useBehavior(input);
    const unrelatedState = useUnrelated();
    return ...;
  };

If this example sounds trivial, I've packaged up 500+ lines of functionality in a single self-contained hook before, and that's all exposed as a single function that consumers can treat as a full encapsulation of all of that functionality, while not worrying if they need to hoist that function call up and pass the output down at some point in the future.

I'm not talking about calling the same hook in Foo and Bar (these are different instances), nor sharing local state sideways across different invocations of hooks, but rather having full confidence it won't be hard to re-anchor that hook upward in the component tree if need be.

That's not a bug with hooks, but almost a complete misunderstanding of how hooks work (*on the part of anyone who writes that code thinking it will behave otherwise). Hooks are effectively instantiated on a specific component instance. Calling useState multiple times like this is multiple instances of useState, whether or not it's wrapped in another function.

And I'd like to be very clear that I strongly advise against cutting through layers with context because I wholeheartedly agree with your assessment there. You can plumb down those handles explicitly through props and enforce they're provided in a type system.

It sounds like you're talking about network resolved state. I like to share this sort of state using a subscription model, where components subscribe to a property of a state root (which anchors/owns the state and how to fetch it), resolving that property's state when mounted. Where that root is in the tree determines the lifecycle of the state (e.g. it's gone when unmounted), and multiple subscribers to the same property can mount, unmount, etc. at any point during that lifecycle without duplication.

I believe this model has similarities to both Apollo and Angular services, though I don't have direct experience with either.

One of the problems Redux is used to solve (as a global store) is peace of mind that you won't need to refactor large swathes of component trees to reparent state and callbacks that need to be shared or persisted across different subtrees as new business requirements arise. Hooks (especially custom hooks, which are just a composition of other hooks packaged together as a single function) make the reparenting/hoisting/anchoring of state and callbacks trivial compared to other mechanisms, providing similar peace of mind that you're not boxing yourself into an inextensible component tree. (This is regardless of context; passing down props isn't a large pain point, and is often misguided to try to solve because it leads to importable components and hidden contracts.)

Render props and HoCs solve similar problems for composition/reuse of functionality (these are all mixins at heart), but the hoistability of hooks is really the distinguishing mark in my experience.

I feel compelled to step in here and hopefully provide some insight on what that report means, because it doesn't appear to be what you implied.

* Edit: The header image failed to load for me and complicates much of what I said in the following paragraph; it isn't as cut and dry as it first appeared.

First off, that automated WAVE report is stellar for GetCalFresh. The color contrast here is an excellent example of strict conformance to WCAG 2.0 AA contrast requirements. (Most of the site is hitting AAA contrast requirements, which is above and beyond.) The report identifies a issue for an image element's contrast in the footer. Please note that this is a false positive; the actual visual contrast meets the requirement.

Heading levels are always a bit of a mess as projects get larger, but as the linked report shows, they could easily be improved slightly in this case. That's not going to outright break the site or render it inaccessible; however, it is a slightly less navigable experience for a user.

Finally, it's important to look at both the spirit and practice of conformance to accessibility standards. In spirit, these are usability standards. You can build something that checks all the automatically enforceable, auditable boxes in the standards, but is unusable in practice. Or you can focus on delivering a strong experience to users, focusing on the POUR principles, and I'd argue that's what an accessible experience should look like (not to exclude ensuring the more baseline elements of conformance, of course).

And options help with solidifying input contract as well as the output. Knowing what's an acceptable input via a type system is just as relevant as knowing what is a potential output.

Looks like an interesting project. I know the website isn't responsive, but adjusting the current meta viewport declaration would go a long way while you're working on a full solution. The minimum zoom of 1 makes it unusable in practice right now on a small mobile viewport due to the amount of panning it forces you to do.

If seems like you discount portability as a concern, and if that's appropriate for your use case, that's a fair decision of course. But there are many use cases for which that's a priority.

The concern the BEM and component-based CSS approaches aim to address is the composition of arbitrary chunks of DOM without implicit side effects. By having chunks of DOM explicitly opt in via classes to being styled in a given way, they never accidentally receive styles they weren't meant to, and they're fully portable to arbitrary contexts.

In something like an web application as opposed to a document-oriented website, the ability to compose components and avoid quirks of things that randomly break or look different inside other things is beneficial. Using a component in a new place shouldn't (in the application development context) require adding new selectors for it because it's not "where" your selectors expected it to be.

If you build sites that can support arbitrary viewports, extrapolating to arbitrary scaling factors on a given concrete viewport does not create an explosion of scenarios to manually test -- all you need to know is that your scaling works, and if you always build your functionality responsively, the scaling and responsive layout together just work. (I'm talking about building the whole layout with rems, not just using them for font sizes. For the latter, I'd agree with you that it's brittle and falls apart quickly.)

It's fair to point out that the browser feature is not widely used, but when it is used, it's likely by users who benefit most from the small amount of effort it takes to support it. (It's really a few lines of CSS, plus simply using rems as your websites unit whenever you'd otherwise use px. It's even easier in terms of avoiding weird 16px-based rem calculations if you make your rems 10px for a default 16px browser preference by applying a straightforward conversion on the root element.)

I've written a series of very similar articles, and seeing as some of the ones in this site don't seem to be available yet, and otherwise as another point of view, they may be of interest to anyone looking at this: https://ctidd.com/2017/css-ui-patterns/content

On the topic of rems, when using them for layout, you'd use a body font size rather than the root element's font size to control the size of text in your page.

At that point the root font size exists only as a scaling factor, decoupled from the base font size of content within the page, but allowing the user to control that scaling factor via their browser's global default font size preference. In fact, you could think of the rem as root scaling factor unit rather than root font size unit. (The use of the font size property to set the scaling factor is a quirk of the spec.)

This solves the concern you noted on maintainability, while allowing a user to globally opt into larger or smaller text and correspondingly scaled layout across the web, arguably a win for enabling an element of accessibility by default on any website.

Cars are designed for humans, then infrastructure is designed for cars.

That step of removal from being designed for humans conflicts with any idea that designing for cars is design for humans by proxy: disproportionately catering to automotive concerns has negative affects on humans relying on their infrastructure to facilitate other forms of transport, or otherwise to not excessively distort either the urban or natural environment they are members of.