This week’s reading features the cycle of content moderation controversies (from a wonderful article titled “What Pornhub and Peloton have in common with Facebook”), along with thoughts on language servers and static site generators.
What Pornhub and Peloton Have in Common With Facebook by Will Oremus on OneZero argues that every online platform with user-generated content will eventually be dragged into a content moderation controversy. (And rightfully so!)
The pattern, according to Evelyn Douek of Harvard Law, is as follows:
Someone, often an activist or journalist, finds abhorrent content on Platform X.
It becomes a scandal, and pressure builds as more examples are uncovered.
The platform eventually takes action, but does so in a haphazard and reactive way, geared toward solving the PR problem rather than the underlying issues.
Sooner or later, its inconsistent approach to moderation sparks a backlash of its own.
On Pornhub, which accepts user-uploaded videos, you can imagine the horrifying forms this might take. Yet their parent company Mindgeek allegedly only employs around 80 content moderators, despite being one of the top 10 most visited sites in the world.
More and more, I’m starting to believe that Section 230 protections against user-generated content should not apply to content that has been algorithmically amplified. I’m not sure how I would define this, but I’ve been having trouble reconciling the beliefs that (1) Section 230 cannot be unilaterally repealed (2) better regulation of websites’ content practices is needed.
The article argues:
For platforms squarely in the social media business, and especially those that algorithmically amplify content, there’s no excuse at this point for treating content moderation as anything short of central to the operation.
I certainly agree. One might argue that Facebook or Pornhub is too big to moderate—but perhaps that’s exactly the problem.
Language Servers are the New Frameworks by Shawn Wang (swyx) opens with the claim:
The basic idea is that a core part of framework development is now realtime feedback. This includes things like linting, catching compile errors, and type checking. Building out support for your framework matters just as much as the framework itself, and these days that means language servers.
My personal experience backs up this post. One of the reasons that I found Tailwind CSS so easy to use is because its VSCode plugin was so easy to use.
This is happening in the very mature Python, too: Microsoft recently released Pylance, a new language server for Python that vastly outperforms existing ones. I have even more reason to recommend VS Code + Pylance to newcomers learning Python than before, because the support tooling is so good.
Why I built my own shitty static site generator by Erik Winter recounts a tale of building a SSG that is bug-riddled and doesn’t have many features—but is purely his own. Why? Tools like Hugo, which are flexible and attempt to “do it all,” are invariably complex, too.
The author’s requirements were simple:
Ideally, I want to have one folder for storing all my writing. I want to organize that folder the way I think fits best with the content. Then I want to point the site generator to that folder and it should figure out the rest by itself. What needs to be published on my site? Where should it end up? The metadata should be all that is needed to figure it out.
Sure, Hugo and Jekyll do this—but they do so much more, too. They mentioned, too, that Hugo uses Markdown … with YAML/TOML/JSON frontmatter, which isn’t really Markdown. And that the templates are complicated and hard to understand. (Absolutely true in my experience, and probably my least favorite part of Hugo.)
And so that’s why he built his own. I did too, at one point. It was a really fun learning exercise, and means that I definitely understand the author’s rationale. Eventually, I got fed up with it, though, and migrated to Hugo, which is a decision I’ve been quite happy with.