matchu

Haha, I was writing a reply, too!

In Sam's case, it sounds like all of his social discomfort is happening entirely within free speech principles?

From what I can gather, Sam sometimes freely-speaks an idea that other people find harmful. Others then freely-speak back to him that he should stop, because it's harmful.

But it sounds like Sam's arguing not just for the right to free speech, but the right to have everyone listen to you. That right is limited by others' rights to live peacefully, and not be regularly subjected to words that harm them.

Sam's argument seems to be that one of our major social problems is that we socially disallow controversial ideas, which makes him feel uncomfortable expressing himself and stifles social progress. Therefore, we should start allowing controversial ideas.

The parent comment asserts that Sam's premise is wrong: ideas aren't being rejected for their controversy, but rather for their harmfulness. Saying that "it’s possible we have to allow people to say disparaging things about gay people" (see his previous post) implicitly draws a false equivalence between civil rights advocacy and bigotry as fair-game "controversial" ideas.

They're demonstrating Guacamole's ability to handle simple animations smoothly. Music visualizers are a solid, familiar example, despite not being a super-common use case for remote desktop.

Mm, thanks for calling out the false-negative thing! I think I misparsed that the first time around and got confused between decreasing false negatives and increasing false positives. That's embarrassing, sorry ^_^`

In any case, I think I made a mistake suggesting specific improvements to the memo; lemme pop off the stack a bit:

It's not okay to publish a document to your coworkers that will predictably make them feel unsafe. Full stop.

When you want to express an idea at work, you need to engage in empathy, and try to express yourself in such a way that your coworkers will still feel safe with you. If you can't figure out how to express an idea without hurting your coworkers, then, yeah, you don't get to express it unless you figure something out :/ That's an appropriate workplace policy, and I'm comfortable with the general idea that freedom of expression is subject to some conditions. I know not everybody agrees with that prioritization, though!

More importantly, I'm just tired of articles like this one dismissing the social consequences lens outright. There's more than one valid issue being raised in our community right now, and the importance of one doesn't invalidate the others. Let's have both conversations: how to enable expression of less common ideas, and how to ensure that we express them empathetically. If we approach the problem thoughtfully, I think we can optimize for both :)

(BTW I edited this comment a lot during the first 30 minutes, and pretty significantly changed its contents. Sorry if that ends up being an issue!)

I'm not saying don't have these conversations. Rather, have them carefully, and choose your words with the consequences in mind. There are many good and thoughtful ways to talk about potential issues with Google's gender diversity programs, but instead this memo made some especially bad choices.

For one thing, the memo focuses on needlessly contentious issues, instead of sticking to actionable arguments. It's valid to say that decreasing stress in engineering and leadership positions might attract more women, because modern women tend that value that more. But framing it as a biological issue is hard to prove, and doesn't help support his logistical point. It only has the consequence of hurting people.

The memo also presumes that Google's full-time diversity experts haven't even thought of his concerns. He asserts that seeking out women necessarily lowers the hiring bar for them, instead of asking "How are we mitigating the risk that our pro-diversity push might itself introduce bias into our ideally gender-agnostic perf evaluations?" That's a valid question, and I'm sure Google's diversity team has answers, and I'm sure that some people wouldn't be satisfied with those answers. But jumping to the conclusion that Google's women must be less qualified than the men, just because he can't think of a way to mitigate bias in the hiring pipeline, is self-centered and disrespectful.

I'm very much in favor of a world where it's equally okay to express all ideas! But that doesn't mean we should be equally okay with all modes of expression. No matter which side we're on, we need to think first, then speak. Given the meta-thesis of the memo (especially the "prioritize intent" section), I'm not convinced that the author took much time to consider needs beyond his own.

Yeah, that's a good point! It's important to consider the truth of the underlying idea, as well as the consequences of how it was expressed—though I don't like that the blog post seems to give up on the latter problem just because it's less objective. Discussions about social values and social consequences are worth having, despite not being subject to pure rationalism.

Still, while both lenses are valid, I'm focusing on the consequences lens, because we're discussing an Atlantic article that tries to invalidate it. It's not misleading to call the memo "anti-diversity", if you're focusing on the memo's role as a social artifact rather than as a dissertation, and that's a valid perspective. Words often serve both roles, and it's important to consider both.

(Incidentally, I don't find the memo's argument to be especially sound, either, so it's not just that it was expressed carelessly—but that's sorta beyond the scope of this thread.)

I haven't decided yet whether I think the memo is sexist. But I'm confident that, because of how it's written, sexist people who read it will feel validated in their sexism.

It uses the same core argument as sexism: women are less suited to certain tasks, perhaps biologically. And it reaches the same conclusion: we should roll back our pro-diversity and pro-empathy programs. A sexist person who reads this will therefore feel that it supports their views, and, because the argument seems rationalist, they'll conclude that their poor treatment of women is rationalist. That might not be the intent of the document, but it is a predictable outcome.

Words that validate sexist behavior, intentionally or unintentionally, contribute to the problem. Regardless of the merit of the underlying idea, or the valuable conversations it inspired, it's important to remember that the memo itself did harm. It's appropriate that some people are focusing on that.

It's important to distinguish between what the memo's author says, and what effect his words actually have. It is an anti-diversity memo, even if it isn't intended as one.

The author makes shaky statements about gender, reinforcing sexist stereotypes. The author applies rationalist disclaimers, which enables already-sexist readers to feel that their sexism is rational. And, most distressingly, the author asserts that Google made a mistake hiring many of the women who work there. Actively making your minority coworkers feel unwelcome is an anti-diversity behavior, and it was an obvious and predictable consequence of how he chose to communicate.

I don't claim to know the author's intent, or how he truly feels about the women he works with. But, regardless of whether he's actually opposed to diversity, we judge words by their consequences. These words are thoroughly anti-diversity in consequence, and judging them in a vacuum is dangerously naive.

Be sure to read Paul Bakaus's response, "Why AMP caches exist", to hear both sides of the issue. https://amphtml.wordpress.com/2017/01/13/why-amp-caches-exis...

(Though, actually, it's only a response in spirit; Bakaus's article was posted about a week earlier than Miessler's.)

I think the problem with the AMP cache model is that, because you need to link directly to the cached URL, you commit to exactly one cache provider. If Bing were to also implement their own validated AMP cache for Bing search results, you can't have one link point to both; you're either AMPed in Google results or in Bing results, and, by being marginally bigger, Google wins all of the pie. That's no good.

How might we change the AMP standard, or the trust model around AMP caches, to get the same performance wins while still enabling competition?

For me, I trick my brain with indirection.

When I'm just sitting around saying "am I happy yet?", I never am. It just reinforces the depression by reminding me of the challenges. Happiness, in my experience, is the sort of thing that I can't usually produce on demand.

But I can set yourself up for success. I ask myself what tends to make me happy, and then I make the hard decision to legitimately engage with it: I challenge myself to be swept up in the moment, even though it really seems like I won't be.

For example, I generally find happiness by making progress on the things I'm invested in. But, even though I am invested in being happy, I can't just dive into coding and expect it to work, because coding isn't actually what makes me happy: coding helps me accomplish things I care about, and that makes me happy.

So, first, I find a self-contained goal, like "I'm gonna work on this really cool project because it's really cool", or "I'm going to make progress in this video game because it challenges me to think in new ways". Fulfilling this goal for its own sake, because I'm legitimately invested in it, is what makes me happy. In order to succeed at happiness, I carefully choose a different target, and focus on it instead.

That's what's been working for me recently, anyway.

Hmm, okay. I'm starting to poke at the TodoMVC's compiled code in the debugger, and it's not quite the super-duper-aggressive graph conversion that I was imagining—but it's interesting to look at :)

Oh! I think I'm fundamentally misunderstanding the pitch here. Here's my new guess: Svelte analyzes my component tree to discover the graph of data dependencies… and then throws out the component tree entirely, instead outputting code that directly implements my data flow graph.

Is that correct? If so, it's a very cool idea! (I'd been tossing this idea around for a few months last year, but had trouble designing a non-awful API xP)

I wish there were a way to make the messaging around this idea clearer. I know that audiences are different, and this wouldn't work for everyone. But if the introductory blog post had illustrated the transformation from component tree to data graph, I would've immediately understood the performance implications and how this represents a huge paradigm shift in application compilation.

Instead, though, I thought the pitch was "ew, separate runtime library? let's inline it and then it'll be smaller", which seemed misguided. I had to reverse-engineer Svelte's motivation from your comment—and even now I'm still not sure I got it right. (Maybe this entire comment is wrong? Could be wrong. No idea :/)

Are y'all planning a blog post about how Svelte works under the hood? That would go a long way toward clarifying the pitch, I think.

I'm confused by the anti-runtime argument.

The file size problem is about unused code, right? If we tree-shook the runtime and shipped the minimal version that our app needs, wouldn't that be even better for most apps than inlining the framework? I'd expect that, the moment you use a feature even twice, the runtime approach yields a smaller bundle.

Or is Svelte accepting a file size penalty to avoid the performance overhead of function calls? If so, it'd be nice to see that tradeoff discussed more explicitly: in every app, there are probably features worth inlining and features worth keeping as function calls.

Really, it sounds like Svelte is trying to solve a very general compilers problem with a very specific sledgehammer solution. Sure, tree-shaking and thoughtful inlining are difficult to do well, especially in Javascript, so this makes sense as a first draft for certain use cases. I just wish it were touted as a first draft, rather than a new beautiful finished paradigm.

The tricky part is rendering the correct number of equals signs. Markdown.css fakes it by rendering a constant large number of equals signs, then setting the width so that only some are visible.

Some immutable data structures implementations perform optimizations under the hood.

For example, if you have a large game state object with mostly stable fields, but the position value changes frequently, you don't need to perform a full copy of the object when position changes. Instead, you could create a new object that only keeps track of the position field, and delegates all requests for other fields to a more stable underlying game state object.

You could also imagine an environment that, if you're going to throw away the reference to the old game state anyway, then it's safe to mutate the object directly instead of bothering with copies or proxies.

…that said, most implementations—especially if you're not careful—will probably incur performance costs, and, at 60 FPS, those matter. They're just not necessarily as bad as you're imagining :)

I'm curious about this limitation:

Descendant and child combinators are unsupported

Are conditional applications of rules also unsupported, like `:hover` and media queries? That's a big deal in terms of runtime perf, too.

Bandwidth was the major motivation for building Aphrodite, too: Khan Academy wanted to decrease the number of bytes required for the initial pageload. http://engineering.khanacademy.org/posts/aphrodite-inline-cs...

We must deliver the absolute minimum amount of CSS necessary by only sending down CSS in use by components in the server-side rendered body. This rules out extracting all the CSS used in all of our components at compilation time, as much of that CSS would not be needed for the initial page load.

Colocating styles with components is a win, but, more importantly, styles-as-JS-objects was the simplest way to get this perf feature out the door.

Interesting! I really like the architecture here. I think the next major opportunity for abstraction is all the server/client detection you still have to do. Do I want `request.headers['Cookie']` (server), or `document.cookie` (client)? Do I want to create a fresh Redux store (server), or hook into a global one (client)?

It's definitely not hard for community members to build these abstractions themselves (`cookies = (req) => req ? req.headers['Cookie'] : document.cookie`), but some of these are going to play into major use cases like authentication, so, as Next matures, it'll start to make sense to provide these especially common abstractions out of the box.

That said, these are next steps; the first release is all about showcasing the fundamental architecture, and it's looking gooood :D

I don't think that's actually part of the Cast protocol. Google just built a desktop streaming app on top of the Cast protocol, and bundled it with the client.

Certificate pinning does prevent an important class of MitM attacks, though.

I think some applications use certificate pinning when validating a certificate provided by a default certificate authority, but, if you manually install a root certificate onto your device, the app will accept the override. That's one possible middle ground.

I like that you're planning to earn trust long-term, but, if customers are entrusting their proprietary codebase to you, some more concrete promises will be important, too.

There's a difference between trusting someone not to redistribute your work versus having it in writing. Both are important.

I'm not clear on why we need to upload the full codebase.

The Privacy Policy indicates that this is because their index of public code is too large to copy to the client machine. So why can't my machine just send queries as needed, or, even better, download the subset of the index relevant to my project?

Maybe it was easier to ship the "local code" search features by building on top of the existing public code indexing, which is server-side. But, despite the extra engineering work, client-side indexing for local code would definitely make a lot more sense for most customers.

Otto replaces Vagrant for the common use case: if you're just a person who wants to run a personal dev server, they'd like you to move onto Otto.

However, Otto is just a layer on top of Vagrant that automates a lot of the decisions that a dev would usually make. Vagrant is still relevant for other use cases, so they'll continue to develop it as a standalone product, too.

Philosophically I like the idea of the user being able to choose any version of the client, but that doesn't seem sustainable: while it's generally _nice_ to support old versions of your app and avoid breaking changes to the protocol, sometimes the cost to the developer would just be way too high.

For many apps that communicate with a remote service, you're gonna have to eat _some_ update somewhere down the line.

Sounds like they only focused on short-term business needs.

Maintainability and security are definitely business needs, but they're long-term instead of short-term, so it's easy for new companies to underinvest in them.

Seems like it's trying to generate a bunch of aesthetically-pleasing 4-color palettes, and present them in a helpful way.

I suspect that the building shape is engineered to create a border between each pair of colors. (The standard alternative would be, say, 4 vertical bars, which only shows you how 3 of the color pairs look against each other.)

The noise might be working under the assumption that you're going to apply noise to the colors when you use them, too.

Yeah, I really dig those :D The concept of a "presentation component" has the exact same semantics as a pure function, so I'm excited that we're actually gonna get that abstraction.

The part that concerns me, though, is the logic component. Hierarchical state/event management seems like a hard problem, and React does it okay, but a lot of things end up coupled together: why does a component that manages a state hierarchy and event flow need to be coupled to the idea of rendering a virtual DOM tree? Can't I just declare that my TodoApp state is a composition of my TodoList state and TodoForm state without also declaring how I'll eventually render them?

I wonder if anyone's come up with a really great abstraction for this yet that checks all the boxes. I like the philosophy behind how Redux manages state, but React provides clearer encapsulation of state and doesn't make parent components think about the events that their children are handling.

Redux is even crazy younger than React, though, so there's still plenty of room to grow there, too!

Are modern CPUs really going to choke on a few thousand comparisons?

My impression has always been that, for any constant-time operation, you're gonna need to start getting into the 100Ks or even the millions to start noticing, but I don't have the data to back me up here :/

Hand-written code will always beat a framework; React isn't trying to be faster than domain-aware DOM manipulation.

Instead, React seeks to be the state of the art in maintainable view architecture. One of its secondary goals is non-sucky performance, which it does pretty well.

Most devs aren't working on apps where React is the performance bottleneck. If you are, then, well, don't use React.

I think it might be an objection to what the style guide refers to as "logic components": components that use React's `setState` to handle interactions and decide what props to forward to a "presentation component".

Personally, I feel that React is a handy tool for both of these use cases, but the fact that we're finding these two distinct types of components suggests to me that React's "component" abstraction might be doing too much.

Maybe if we break React into the pieces that are helpful for "logic" and the pieces that are helpful for "presentation" we'll end up with two abstractions that are each better suited to their task.

React's ideology is still very young, so I'm hopeful that the community will start to head in this direction, and I'm super excited to see how this plays out :)