DEV Community: swyx

Running Docker without Docker Desktop

swyx — Fri, 27 May 2022 19:51:36 +0000

TL;DR

brew install colima (colima replaces the docker/dockerd binary)
Install the right docker-compose binary for your chipset from the releases page
- sudo curl -L https://github.com/docker/compose/releases/download/v2.5.1/docker-compose-darwin-aarch64 -o /usr/local/bin/docker-compose for M1 Macs
- chmod +x /usr/local/bin/docker-compose to let it execute

You should now be able to run docker-compose up as per normal but without needing Docker Desktop.

Context

Although I am known for loving Docker (the containerization technology), I am also known for being a critic of Docker Desktop (the desktop UI client for Docker) for its poor performance:

// Detect dark theme var iframe = document.getElementById('tweet-1523368365728837633-568'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1523368365728837633&theme=dark" }

Docker Desktop is Docker (the company)'s first wedge into getting you to run proprietary software, so Docker strongly guides you to download it as the only way to get started:

In fact, new users can go pretty far without even realizing that you don't need Docker Desktop to run the Docker daemon. I've asked multiple people how to do it and nobody had a good answer, or at least, nobody had an answer that worked on M1 Macs, until now.

For my 2022 New Mac Setup guide I resolved to figure it out once and for all, and what you see here is what I ended up with!

Why TurboRepo Will Be The First Big Trend of 2022

swyx — Mon, 27 Dec 2021 16:08:03 +0000

TurboRepo was acquired by Vercel recently and I caught up on Jared Palmer's excellent intro demo to see what the fuss is all about:

Here are quick notes for those too busy to view the whole thing, followed by personal reflections at the end.

TLDR

See the TLDR of this post in thread form:

// Detect dark theme var iframe = document.getElementById('tweet-1475509463813529601-746'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1475509463813529601&theme=dark" }

Why Monorepos

You can refer to other sources for definitions of Monorepos (2022 edit: Nrwl just launched https://monorepo.tools/ which has their perspectives and comparisons), but we'll spend some time on covering why they are a worthwhile goal:

You can easily make cross cutting code changes across multiple applications (eg /frontend and /backend) in one atomic commit
You can easily search across all projects
Single source of truth for many environment concerns you will want to standardize across your company, for example:
- dependency management (important deps in one package.json)
- code reuse of shared packages (e.g. /design-system or /common-utils or /schema)
- configs (ESlint, TSconfig, etc)
- tests (from unit to e2e)
For library authors, it is also easier to publish packages with dependencies on each other.

Major JS ecosystem tools like React, Jest, pnpm, Next.js, and Yarn itself have moved to Monorepos, as have small startups and large companies like FB and Google.

Origin of TurboRepo

The origin story of TurboRepo started with this looongstanding open issue on TSDX from Nate Moore:

As an early volunteer on TSDX I studiously avoided this issue because I never worked at a company with a large monorepo, and thought that it should be solved by dedicated tools like yarn workspace, which at the time was just gaining traction itself.

To solve this, Jared tried to extract Lerna into a monorepo tool, and when researching how big monorepo shops like Facebook and Google did task running, discovered that a lot of their advanced techniques had not made it into the larger JS ecosystem.

So, TurboRepo was started with 3 objectives:

make a monorepo tool that utilizes as many of these advanced techniques as possible with zero config
make it easy to incrementally adopt (eg when moving from Lerna)
make sure that it scales (eg API design and architectural choices are flexible enough)

The fuller story of TurboRepo is told by Jared in this thread:

// Detect dark theme var iframe = document.getElementById('tweet-1346217789942591488-214'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1346217789942591488&theme=dark" }

What TurboRepo does

The basic principle of TurboRepo is to never recompute work that has been done before.

To do this, it generates a dependency graph from your build pipeline from a turbo config in package.json, executes each task in turn, and fingerprints the input/caches the output of each task.

When it is run a second time, if it finds work that matches a fingerprint, it restores from cache, and replays the logs.

How to use TurboRepo

The main CLI surface area is surprisingly small:

npx create-turbo@latest turbo-demo scaffolds a monorepo with apps (docs, web) and packages (design system and shared configs (eslint, tsconfig))
turbo run build builds all apps at once, but importantly, when you run this command again the second build completes in 100ms because everything is cached. There are a long list of flags you can add to modify what turbo run does and outputs.
turbo prune --scope=<target> generates a sparse/partial monorepo with a pruned lockfile for a target package.
Remote Caching commands: turbo login and turbo link (explained later)

The `turbo` config key

TurboRepo uses a special key in package.json called turbo (docs here), and it is here that topological relationships between build tasks (and where to fingerprint for cache artifacts) are defined:

{
  "turbo": {
    "baseBranch": "origin/main",
    "pipeline": {
      "build": {
        "dependsOn": ["^build"],
        "outputs": [".next/**"]
      },
      "test": {
        "dependsOn": ["^build"],
        "outputs": []
      },
      "lint": {
        "outputs": []
      },
      "dev": {
        "cache": false
      }
    }
  }
}

This helps Turbo create a Directed Acyclic Graph of your build that it can then walk in reverse for building and checking against its cache. You can even use the --graph flag to visualize your build graph with Graphviz.

(Having tried out visualization tools before, imo this is a fun demo but not practically all that useful 🤷‍♂️)

The other important thing to know is that you can run all these tasks together and Turbo will parallelize as much as possible:

turbo run build test lint

To understand what is running in parallel and debug build pipelines, you can even make Turbo output a profile with the --profile flag to inspect the traces in Chrome DevTools!

Remote Caching

Remote caching is a beta feature, but is set to be far and away the showstopper in making TurboRepo scale. Normally, caches are generated and checked locally, so if you are reviewing code that a coworker has written, you'll have to build it locally too.

Sounds inefficient? We can fix that.

Remote Caching shares that cache globally (this is secure to that extent that hashes are secure), turning TurboRepo from a "single player" experience to a "co-op multiplayer" mode. The analogy that resonates a lot with users is that this is basically "Dropbox for your dist directory".

This is where Vercel's backing comes in - they are offering free remote caching on TurboRepo builds - you'll still need to make a Vercel account, and they may charge for this later - but this works whether or not your app is built or hosted on Vercel. Brilliant move for everyone concerned! All TurboRepo users get free speedups, Vercel gets a bunch of signups (with network effect) and a possible future revenue source.

Usage is pretty simple:

npx turbo login # login to Vercel
npx turbo link

That's it! Could not be easier, and offers free speedups.

The Future

Jared ended the livestream by making a few comments on the TurboRepo roadmap

Telemetry
Sharding Parallel Tasks in other processes (currently, TurboRepo runs parallel tasks in the same singlethreaded process like Node does - to actually make use of full concurrency it should distribute that work to other processes. Temporal, the project I work on, could be an interesting tool for that in future
Presets (referred to as "Turbo Season 2")
Smaller features
- Public/private security model like npm
- More intelligent watch mode
There will probably be Enterprise features too.

You can vote on feature ideas on the TurboRepo GitHub Community as well.

What About Nx?

TurboRepo is most often compared to Nx, so I'm very grateful that Victor Savin (creator of Nx) has written a page on the Nx docs detailing the differences he sees vs Turborepo.

He's also made benchmarks for Nx vs TurboRepo you can try out:

// Detect dark theme var iframe = document.getElementById('tweet-1471209016827207689-81'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1471209016827207689&theme=dark" }

Personal Takeaways

TurboRepo is a big deal for the JS community not just because it addresses build speeds (which are always a crowd pleaser), but also that it is a well defined abstraction that brings a lot of value out of the box, with a declarative build pipeline, great debugging/profiling options, and great docs.

With 74% of its code in Go, TurboRepo is a great example of the Systems Core, Scripting Shell thesis, proving out the idea that the age of "JS tools in JS" is over because the need for speed on hot paths outweighs contributor learning curve concerns.

Many people in the JS community (like my old self) have heard about the benefits of monorepos, but have been held back by the lack of good tooling tackling this problem head on. While there is a long list of monorepo tooling tackling various parts of the problem, I see TurboRepo as leading the charge for the new wave of monorepo tooling that will rise to prominence in the Third Age of JavaScript, thanks to strong backing and great developer marketing from Jared and Team Vercel.

Followup: Nx Chat

I did a followup chat with the Nx founders to learn more about how they think about Monorepo Tooling:

Using Datasette for an ELT Personal Twitter Data Warehouse

swyx — Sun, 26 Dec 2021 20:52:14 +0000

Twitter publishes some analytics for you, and I check them about once a month, but they are extremely limited when it comes to the important things, like exploring your follower graph.

This is where Datasette comes in. Datasette is a great EDA (exploratory data analysis) tool for any arbitrary SQLite dataset. You can use it to build your own Twitter analytics!

Today, at Simon Willison's prompting, I decided to try to replicate his 2018 work in analyzing his own Twitter network.

TL;DR

You can check out my own dataset here: https://swyx-twitter-datasette.glitch.me/twitter/tweets?_sort_desc=favorite_count&_facet=retweeted&_facet=favorited&_facet=user&user=33521530&retweeted=1

Things to try:

check out the selected facets
sort/hide individual columns
search
build up sql filters (eg favorite_count > 100, retweet_count > 100)

Keep in mind that all of this is automatically generated from a sqlite table (which itself was automatically generated by running twitter-to-sqlite), greatly reducing the bar for GUI-based, SQL-based EDA.

And because it is web based and the SQL is serialized into the URL, you can easily share whatever you find with coworkers.

The How

Optional: Get Credentials

The most time consuming piece of this is going to be getting Twitter API credentials. The process is largely unchanged since 2018 - get a developer account on https://developer.twitter.com/ (some approval time may be required... so get this out of the way ASAP), then create a new app https://apps.twitter.com/ and eventually get to the four "Keys and Tokens" you will need to do this:

Optional: Test Your Credentials

You can test your credentials by writing a little Python script locally (pip install requests_oauthlib, then run python script.py. I also like to use venv)

from requests_oauthlib import OAuth1Session
twitter = OAuth1Session(
    client_key='FILL_ME_IN',
    client_secret='FILL_ME_IN',
    resource_owner_key='FILL_ME_IN-FILL_ME_IN',
    resource_owner_secret='FILL_ME_IN'
)
print(twitter.get(   'https://api.twitter.com/2/users/by/username/swyx').json())
print(twitter.get(   'https://api.twitter.com/2/users/1465910794114134018/following/?user.fields=public_metrics').json())

By default you only have access to the Twitter API v2 endpoints, though you can apply for Elevated Access if you need Twitter API v1 as many libraries and blogposts are still on API v1.

From here you can browse the Twitter API reference for what data you'd like to extract... but you don't have to, if you agree enough with Simon's opinions in twitter-to-sqlite!

Scraping your data with twitter-to-sqlite

One thing I love about how Simon has been building Datasette is the rich ecosystem of data extraction tools he has also groomed. He's got standard things for extracting data from many sources he cares about into SQLite (and, as I've already said, Datasette takes it from there all the way to a viewable explorable product).

So it is with twitter-to-sqlite:

$ pip install twitter-to-sqlite

$ twitter-to-sqlite auth
Create an app here: https://developer.twitter.com/en/apps
Then navigate to 'Keys and tokens' and paste in the following:

API key: xxx
API secret key: xxx
Access token: xxx
Access token secret: xxx

$ twitter-to-sqlite user-timeline twitter.db
Importing tweets  [#####-------------------------------]  2799/17780  00:01:39

This gives you a nice little twitter.db file containing every tweet you've ever made or liked or retweeted that is still on your timeline (timeline gets cut off after 3,200 tweets). You can also crawl your followers with twitter-to-sqlite followers twitter.db.

Deploying to Glitch

Simon's old method relies on Zeit Now, which has since been deprecated. Datasette will work wherever serverful web hosting works, but its nice to host this somewhere free since it is just a personal public data tool. Render.com or Fly.io would probably work, but I felt like trying out Glitch since that is Simon's preferred platform.

Unfortunately I ran into a bunch of problems here and took a couple of hours to fix them. TLDR; just remix my Glitch:

The important unlock here is understanding how to upload your SQLite db to Glitch for it to run. You can't just drag and drop it into the "assets" folder as that is just for CDN hosting, and you need access to this file in the Glitch build process.

The way I figured out how to do it was to clone the git repo locally (unlike that answer, there is no more Advanced Options menu in Glitch, you have to go Tools -> Import and Export -> copy your project's Git URL), and add the file to git (on a different branch, because of Glitch's idiosyncratic setup... read the instructions on the forum).

git clone https://<git access token>@api.glitch.com/git/swyx-twitter-datasette
cd swyx-twitter-datasette

git checkout -b addData

###
# add/replace your twitter.db file to this repo and commit it
###

git push --set-upstream origin addData

And then inside Glitch you'll need to open the Terminal and do:

git merge addData
refresh

And the twitter.db should show up in there.

If all goes well your project should be running like mine: https://swyx-twitter-datasette.glitch.me/twitter/tweets (you can rename your Glitch to a custom vanity subdomain) and you can explore to your hearts content!

The Why

So. That's a lot of work to navel-gaze at a bunch of Tweets. Why bother?

It's not really about the tweets for me. It's about lowering the cost of EDA. I'm putting in my reps when I don't need it, so that I can be faster/more confident when I do.

Everyone wants to operate on data-driven insights, but the cost of wrangling data is often too high and so data, especially your own data, doesn't get looked at.

EDA tools like Datasette dramatically lower the cost of data analysis, with a surprisingly simple ELT contract: You handle the Extract phase, it handles the Load, and exposes a standard UI for you to do dynamic Transforms.

Since the UI is constrained but has all the basic EDA features, it reduces the amount of custom coding you have to do, while giving you just enough flexibility to make queries and derive insights for any arbitrary need.

And since can see all your data and all fields at a glance, you can come up with questions you didn't even think to ask. ELT with Datasette is the data-driven equivalent of dumping out your legos.

How to customize your Transistor.fm Website with JS and CSS

swyx — Fri, 03 Dec 2021 07:58:15 +0000

The default Transistor.fm website is kinda ugly.

Here's mine after a bit of work: https://swyx.transistor.fm/

Here's how to customize your Transistor.fm website if you use Transistor. But also it's a simple guide to do clientside customizations of almost any website whose code you don't control.

How To Video (3mins)

Code

Head HTML:

<script>
window.onload = function () {
  let el;
  if (document.location.pathname === "/episodes") {
    el = document.createElement("div");
    document
      .getElementsByClassName("site-content")[0]
      .parentNode.insertBefore(
        el,
        document.getElementsByClassName("site-content")[0]
      );
  } else {
    // assuming index page
    el = document.getElementsByClassName("site-first-episode")[0];
  }

  el.innerHTML = `
<iframe title="swyx mixtape embed" width="100%" height="390" frameborder="no" scrolling="no" seamless src="https://share.transistor.fm/e/learn-in-podcast/playlist/dark"></iframe>
`;
  el.id = "swyxembed";
};
function makeLive() {
  if (!document.getElementById("swyxembed")) window.onload();
  setTimeout(makeLive, 200);
}
setTimeout(makeLive, 200);
</script>

CSS:

.site-intro {
  font-size: 1.25rem;
    width: 60ch;
    margin: 0 auto;
}

.site-credits {
    position: fixed;
    width: 100vw;
    bottom: 0;
}

#site-footer {
  display: hidden
}

#swyxembed {
  padding: 2rem;
}
.site-featured-episodes .site-episode,
.site-episode-detail .site-episode {
 display: block;
}
.site-episode {
  display: grid;
  grid-template-areas: "date title"
                       "date desc";
  grid-template-rows: minmax(1rem, auto) 1fr;
  grid-template-columns: 10ch 1fr;
  grid-column-gap: 1rem;
  margin-bottom: 1rem;
}
.site-episode time { grid-area: date }
.site-episode time span { text-transform: none }
.site-episode h2 { grid-area: title; font-size: 1.5rem }
.site-episode .site-episode-summary { grid-area: desc }
.site-episode nav {
   display: none;
}

Other customization ideas

Look at the css for https://gretchen.transistor.fm/

You can also use custom fonts: https://www.avillatheory.com/ https://www.youtube.com/watch?v=MFQMczanAm4&feature=youtu.be

Fave New Podcasts in 2021

swyx — Thu, 02 Dec 2021 07:25:13 +0000

You probably already know what the top podcasts are in each domain, so my hope is to give some spotlight to the up-and-comers. (These podcasts may not have started in 2021, but they are new to me this year).

Without further ado:

Best New Tech Podcasts in 2021

Corecursive - Adam Gordon Bell: really fascinating interviews with tech OG's. Many stories that have never been told. Regularly tops Hacker News. I still have the Apple 2001 episode saved.
Sourcegraph - Beyang Liu: In depth founder/engineer interviews from the CTO of Sourcegraph, exploring his own personal curiosity. Personal pick: David Cramer of Sentry.
Stevey's Tech Talk - Steve Yegge: Truth bombs from our industry's best truthteller. Personal pick: Why CEOs crash and burn.
Podrocket - LogRocket's Brian, Ben, and Kate: Interviews of the frontend ecosystem, including yours truly and yours truly! Personal pick: Kiwicopple of Supabase
Devtools.fm - Justin Bennett and Andrew Lisowski: Interviews of the frontend ecosystem, including yours truly! Personal pick: Jason Laster of Replay.io

Best New Business/Crypto Podcasts in 2021

Business Breakdowns by Jesse Pujji: Deeply researched breakdowns of big businesses. Personal pick: Moderna with Jason Kelly.
The Breakdown with NLW: daily news updates on Crypto.
Not Boring by Packy McCormick: Technically a newsletter, but still counts because he reads every essay on audio. Personal Pick: Ramp's Double Unicorn Rounds. His personal journey is also inspiring.
Bankless podcast: entertaining updates on crypto, ETH biased but not maximalist.

Best New Creator/General Podcasts in 2021

Creator Lab - Bilal Zaidi: Generic Interview Successful People podcast, but well executed. Personal Pick: Polina Marinova and Tim Urban and Rahul Vohra.
Masters of Community - David Spinks: Truly one of the top 3 best resources on learning to build/manage community on the planet. Personal picks: Jon Levy and Matthew Kobach
Talking Too Loud - Chris Savage: Great rapport and banter with Sylvie. Personal Pick: Jay Acunzo's picks of them.
Brains - Courtland Allen and Julian Shapiro: Still new, but great discussions from two of the most thoughtful creators out there, in an interesting 4-player format. Personal pick: Sam Parr and Aella
Not Overthinking - Abdaal Brothers: Ali Abdaal getting the piss taken out of him by his surprisingly attractive older brother is just amazing.

Context

In 2019 I published the list of podcasts I listen to, and last year I updated it with newer podcasts, so I'm continuing that tradition this year!

The big difference is that I now run a daily mixtape which clips from all the podcasts I listen to, so you get a live "best of" feed from me if you subscribe. I also run my own infrequent YouTube podcast and am a panelist on Svelte Radio.

Good But Dead

I had these podcasts lined up for my end of year lists, but they also died this year so I can't continue to recommend them. However, they have some backlogs worth digging through:

3 Clips when it was under Jay Acunzo - really good, inspiration for my own mixtape of podcasts
Josh Constine's Press Club - had some good early essays on creator economy
Under the Hood - Robinhood's CEO Vlad Tenev trying to be a podcaster was both awkward and interesting.
Spotify: A Product Story - Spotify's CRDO telling Spotify's own hagiography was still well told. First episode on Metallica and Sean Parker is great.

Still Good

I love good picks that last! Here are some special highlights and shoutouts from my 2020 picks:

Clublife: Tiesto is still banging out the hits for free, amazing
Conan: Conan, Sona and gang are still hilarious and great company. Their recent live show was INCREDIBLE.
Software Social: Michele has now pulled off a book launch (I liked it) and Colleen now has a job! It has been fun to follow along.
Writing Excuses: Brandon Sanderson hasn't swung by in forever, but the tips have continued flowing! I liked the episode on Audiobooks and they had some good stuff on MICE and Game/Worldbuilding.

Community Heat, or Why You Should Get Good at Events

swyx — Mon, 08 Nov 2021 01:32:56 +0000

When Apple launches a product, it doesn't come right out and say "we're launching our new MacBook next week".

They make you guess.

Predict.

Watch.

Review.

They invite people to a "Special Event", and throw up a logo or video that juuuust so slightly hints at what they're releasing. Journalists know to clear their schedule, other companies defer their own releases. Fanboys and the media lap it up, giving millions of dollars worth of earned attention.

Apple is of course a special, secretive, historic outlier, but I think even open source companies can take a leaf from their book by understanding how to shape an event, galvanize community, and become a launching pad. This was my reflection after observing Next.js Conf for the last few years, as I covered in my chat with Lee Robinson of Vercel, the "Apple" of web developer platforms:

Community Heat

Community building is all the rage, but all too often, it takes the form of Discourse forums, Discord channels, Slack rooms, Twitter hashtags. The sheer amount of always-on, background-persistent community is bewildering (and slightly stressful, to be honest). And the quality of interaction is very hit and miss; the older I get, the less patience I have to sit around in a chat room waiting for a typing indicator to resolve to "haha". Yet I stick around because sometimes it upgrades into a full-blown conversation between knowledgeable individuals you can't get anywhere else.

The difference here we are observing is "community heat", a term I've borrowed from McLuhan:

"Cold" community is async. "Hot" community is sync.
Forums and Mailing lists tend to be cold: nobody ever expects a reply the same day, if at all (exceptions exist)
Chats are a chimera; cold by default, but randomly upgrading to hot when both sides happen to have the time and mood to chat.
In-person meetups and conferences are white-hot: if someone is talking to you and there's even 1-2 second gap between responses, it would be uncomfortably awkward.
Cold communities tend to be much larger, yet far less engaged, than hot communities, for obvious reasons

Some communities exist purely cold - I'm thinking Reddit forums and the comments section of YouTube videos and others are hot-only (I'm thinking the ephemeral communities that spring up around conferences, that then disappear for the rest of the year).

My assertion is that communities are better with an annealing process, alternating hot and cold (like writing blogposts!). The "hot" event spills over into the cold community and keeps it warm, and the cold community passively builds excitement for the next "hot" event.

This is why I'm always slightly bemused when people ask me about the "Slack or Discord?" for building community. Most people know how to run a Slack or Discourse or Discord or whatever. I don't much care. If you have no events strategy there's only so much community you can build.

Get Good at Events

Below are my thoughts in an unordered list, as I do not regard myself an expert.

Venue

The days of offline-only conferences are basically over; the secret is out that content wants to be free and accessible to all. You have to be successful with online events if you want to be successful period, particularly in tech. Yet an online-only strategy is ill-advised - people are spoiling for in person connection, and you can find out so much about the customer face to face.

I think the right split of online to offline is probably 90/10, or 80/20. The overall goal should be to default to online stuff, but to identify 5-10 IRL opportunities and make each absolutely unforgettable and worthwhile; a real event rather than just an appearance.

For online confs: Hopin seems popular, but you could also roll your own with the Vercel Event Starter Kit, React Conf recently did. We run Svelte Summit purely on YouTube. I also enjoy Gather.town for the novelty element although I wonder if it will get old fast.

For online meetups <100 people, Zoom is fine; above 100, you should probably use Zoom's Webinars feature where you can more tightly control attendees and manage Q&A.

IRL venues should be planned and booked at least 3-6months out, for a combination of venue timelines and personal travel plannin.

Frequency

The ideal cadence for companies running community/marketing/devrel (yes I'm intentionally being obtuse about the difference) varies.

Yearly: Cloudflare does one Birthday Week a year, where the goal is to dominate the news cycle for an entire week, impressing people more than if the same news were dripped out over a year. However, large news may crowd out smaller news, and the arbitrarily chunky deadline forces premature launches. AWS has resorted to "dumping" smaller announcements pre-Re:invent just to keep Re:invent announcements to a few hundred truly top ones.
Quarterly: If you ship on a semi frequent basis, you may prefer a quarterly event with all your product updates, as WorkOS does.
Monthly: At Temporal, we keep it simple - one "community meetup" a month (signup, watch). It's a "meetup" because we hope it is just the first of many meetups, run by us but someday hopefully entirely run by our users. We are also seeding a mailing list of hundreds of people who have come to our meetups, so that we can get them to come to a conference when we hold one in future (I call this the GitNation strategy, because that is how they lay groundwork for conferences)
Weekly: I like this for regular livestreams and hangouts, like Netlify's Learn with Jason or AWS' Containers from the Couch. I think deeper relationships can only be built by showing up at least weekly; any less frequent than that, and reaching out to someone feels like "a whole thing".

Naming

I do think that naming matters.

We've already talked about the "Special Event" thing.
I would never be caught dead attending a "webinar", but I've shown up at many a "workshop" with basically the same content (although inauthentic marketer types who give any webinar vibes have me reaching for the red X as soon as they open their mouth).
We've also done "teach-ins" and "office hours" with similar effect.

Curation

When conferences first panic-moved online during Covid, they lifted-and-shifted the schedule and curation as well - 8 hour days, CFP process, the whole lot.

Then we realized nobody sits at their computer watching a livestream for 8 hours.

This happens with every platform shift - first the Skeuomorphism, because it's familiar, then the Nativism, taking advantage of the inherent qualities of the platform from first principles with total disregard to legacy. When Microsoft first ported Windows to mobile it moved everything, start menu, keyboard and all. Took us 10 years to find the interface native to the form factor.

With Svelte Society we did the same thing, lifting and shifting the format, for our Svelte Summit conferences in 2020. This time around we are going "native" - instead of going thru an agonizing CFP selection process, we accepted everyone and moved the point of curation down to the produced video rather than just going by title and abstract (together with optional speaker training for this new burden). We curate the best mix for our 4 hour main stage and use the infinite shelf space of YouTube to release the videos in mini events the rest of the year.

I'm certainly not holding ourselves out as exemplary; I'm just trying to give you ideas. For example I think that "purely meritocratic" selection processes are also not ideal - many great speakers have gone invite-only and will never apply to your blind CFP process even though they have the perfect topic. A good curator would proactively reach out as part of their service to conference attendees. Putting out a "request for topics" would also help.

Marketing

Only one number matters for conference marketing:

Registrations.

I'll say it louder for the people in the back.

GO FOR REGISTRATIONS.

It's the biggest number. Market the shit out of it. It's incredible. Nobody is incentivized to question it. Everyone knows the flaws but play along anyway in wonderful kayfabe. Speakers can brag about it. Sponsors can justify bigger budgets. You don't have a physical venue so you don't actually need to worry about pesky things like fire safety and refreshments logistics. Pump it up shamelessly and often.

What's incredible is the reflexivity of the whole thing. Humans are semi-herd creatures — an event will be big because it says it is big.

Marketing matters for async much more than it does for sync. Particularly when I hear that an event has 70,000 people signed up, I'm more likely to catch up on the video async. A shitty event will have like a 0.5:1 async to live view ratio, a well marketed event is more like 10:1. (It takes actually legendary talks to breach 1000:1 and beyond).

Oh and don't forget to keep them around to market the next event.

Post Production

Dumping the conference video straight to YouTube is economical, but undersells the huge amount of opportunity available to brush up the quality after the event. If your async to live ratio is 10:1 then the vast majority of people will be watching your event async, and it serves as marketing for your next event. Make it awesome and cut out all the boring. Some organizers go to the extent of shooting trailers; I don't know how yet but I'll gladly welcome recommendations I can feature here.

Any other event advice?

100 Bytes of CSS to look great everywhere

swyx — Sat, 16 Oct 2021 21:05:53 +0000

TL;DR

html {
  max-width: 70ch;
  padding: 3em 1em;
  margin: auto;
  line-height: 1.75;
  font-size: 1.25em;
}

I previously tweeted out an old version of this and accidentally got a line by line code review from 100k people:

// Detect dark theme var iframe = document.getElementById('tweet-1449472712720601088-849'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1449472712720601088&theme=dark" }

This article is the most up to date version with everyone's feedback.

Context

Dan Luu always writes fascinating posts, but the design makes it very painful to read:

A couple years ago, this post on HN was fairly popular, and I saved it on my spark-joy repo, which is a swipe file of design tips I've collected over the past few years.

However, I noticed that the original website link is dead. So I thought I would refresh it with what I have now implemented for Dan's site:

100 bytes of css to look great nearly everywhere

This should be simple drop-in css to look good on most displays:

html {
  max-width: 70ch;
  padding: 3em 1em;
  margin: auto;
  line-height: 1.75;
  font-size: 1.25em;
}

Let's break this down. I've adapted the original text with my own commentary.

max-width: 70ch: the "readable range" is usually 60-80 character widths, and CSS lets you express that directly with the ch unit. I blogged more on line lengths last year.
padding: 3em 1em: If the display's width goes under the max-width set above, then this padding prevents edge-to-edge text on mobile. We use 3em to provide top/bottom whitespace.
margin: auto: This is really all that is needed to center the page - applied on html, because Dan's site doesnt have a semantic <main> tag and <html> is more likely to exist in most sites (no judgment pls, i've heard enough semantic HTML preaching). That the top tag centers itself relative to nothing is unintuitive, but thats how browsers do.
line-height: 1.75: Spacing between the lines to help increase visual clarity. Always leave line height unitless because reasons.
font-size: 1.5em: I've noticed that recent design trends and screen sizes have tended toward bigger font sizes. Or maybe I'm getting old. Prefer em or rem over px if you want to let users scale it.

Tushar points out that you can use :root instead of <html> to guarantee that there is some selector present, but its a touch too fancy for me and uses an extra character :)

Optional 100 more bytes

If you can spare a few extra bytes of CSS, I'd also recommend margins for headers, paragraphs, and lists, and softening body text:

h1,h2,h3,h4,h5,h6 {
  margin: 3em 0 1em;
}

p,ul,ol {
  margin-bottom: 2em;
  color: #1d1d1d;
  font-family: sans-serif;
}

Applying Styles on Pages You Don't Control

You can auto apply these styles on to pages with https://github.com/ankit/stylebot. I can't vouch for their security as I only just started using it.
WaterCSS is a bookmarklet or extension or script with some nice presets: https://watercss.kognise.dev/
SakuraCSS is a bookmarklet that does the same https://oxal.org/projects/sakura/bookmark/

Eating the Cloud from Outside In

swyx — Mon, 04 Oct 2021 02:23:15 +0000

See discussions on Hacker News and InfoQ.

Cloudflare launched on September 27, 2010, and every year since, it has made it a point to celebrate "Birthday Week" with a raft of launches. By far, the show-stopper this year was the announcement of R2 Storage, an S3-compatible Object Storage service that directly takes aim at AWS' "Hotel California" business model. This has been extremely well received, going by the response on HN and Twitter. In its past 5 birthdays, Cloudflare has gone from world-class CDN to offering:

This is an impressive pace and they are now declaring that they will be "the fourth major public cloud". When your market cap is $36 billion and your next biggest competitor is worth $1.6 trillion (~45x larger, albeit not pure-play), this is a bold statement. Many startups are trying by offering specialized Cloud Distros, but all building with AWS as the presumptive winner of the "first layer cloud" rather than trying to compete.

What's Cloudflare's strategy here?

My realization: The big 3 clouds are playing Chess, but Cloudflare is playing Go.

Two Kinds of Disruption

The canonical thoughtleader of Disruption theory is the legendary HBS Professor Clayton Christensen, and a lot has been made of Cloudflare's Disruption of AWS; in fact, Cloudflare cofounders Matthew Prince and Michelle Zatlyn were students of him at HBS. James Allworth, their Head of Innovation, studied and co-authored a book with him. Prince namechecked the Innovator's Dilemma at Cloudflare's launch in 2010, and in 2021 is still proudly showing off a handwritten note from him; in short, you can be sure his lessons are never far from Cloudflare's minds.

As Ben Thompson noted in his now-famous takedown of Christensen on the iPhone, people often miss that he had two theories of disruption:

New Market Disruption: When incumbents ignore new technologies until it is too late.
- Allworth recently wrote an instant-classic application of this on Intel (x86/CISC) vs Apple Silicon (ARM/RISC)
Low-End Disruption: When vertically integrated premium incumbents get disrupted by "cheap and good enough" modular providers.

A third model of disruption comes from Kevin Kwok's Atomic Concepts, but that is a closer fit for the Cloud Distros thesis than Cloudflare.

On the first theory: Cloudflare has some excellent technologists — John Graham-Cumming, Kenton Varda and Rita Kozlov come to mind — and it is doing some cool things with V8 isolates and dynamic routing, but it doesn't (in my mind) have a clear claim on the overall new technology angle, since AWS created the modern serverless paradigm, open-sourced Firecracker, and is using Lambda for half of all new applications (though Cloudflare is also aggressively dogfooding Workers).

Most of the disruption discussion focuses on the second model of disruption, and it rings true. Cloudflare took a part of the cloud nobody valued, gave away an insanely good free offering, and quietly accumulated an 80% market share. Meanwhile, when people think of "Tier 1" AWS services, its Cloudflare equivalent, Amazon CloudFront, rarely gets any love, and the official AWS Twitter account hasn't tweeted about it in almost a year. Cloudflare leveraged their foothold into selling premium security services, and now is expanding into other value added pieces by leaning into a fundamentally different (high fixed cost, near zero marginal cost) business model the larger incumbents structurally cannot follow.

This, at least, is how Ben Thompson framed it in his writeup on Cloudflare's Disruption:

But this diagram is a little too neat. It imagines the two clouds as worlds apart. Yet R2 is explicitly designed as S3-compatible; in Prince's words, you can set it to "slurp" mode and you magically have a S3 interface with egress that is six orders of magnitude cheaper. Similarly, the original Cloudflare service could always be used together with EC2, and Cloudflare Workers have different enough usecases and limitations from AWS Lambda and Lambda@Edge that you could conceivably have a stack using all of them.

This isn't Apple vs Android; premium and vertically integrated vs cheap and modular; incompatible ecosystems, and never the twain shall meet.

This is something else.

Cloudflare and the Rules of Go

In the classic game of Go, you capture pieces by surrounding your opponents, instead of directly replacing their spot.

Storage Capture

You could view Cloudflare's Bandwidth Alliance and R2 as an "encircling" move around AWS' previously secure market position with S3. By promising to be API compatible (including offering S3's eleven-nines durability guarantee and free infrequent access), Cloudflare has cut off nearly all of AWS' remaining "liberties", putting it in "atari". If Cloudflare's offering matures enough to be seen as a strict superset, it places the final stone, capturing the "cloud storage" territory.

Product Strategy

In Chess, pieces have different values and capabilities. Bishops are worth 3 points and move diagonally, Rooks are worth 5 and move in straight lines, and so on. Pieces are best deployed in a sequence chain where higher value pieces support lower value ones.

In Go, each piece is indistinguishable from the other; it is the network position that counts, not any individual piece. Support doesn't matter so much as adjacent territory claimed; in the picture below, the four white pieces on the left do far less than the four black pieces on the right.

Compare this to public statements about how Cloudflare works. From Prince:

Since every server in our network runs every service, once we’re in for one thing means everything we do in the region gets better and less expensive to operate. This means, counter intuitively, as we add more locations to our network our costs generally go down, not up.

So while AWS has 17 ways to run containers and 7 ways to do async message processing, all overlapping and reinforcing and supporting each other, Cloudflare will tend toward introducing singular primitives, stuff them in a box, and try to ship those boxes to as many places as will possibly take them. If they could install Cloudflare on your mobile phone, they would (this gets them dangerously close to being a real life Pied Piper).

Update: I have been informed that you can in fact install Cloudflare on your mobile phone...

Territory Wins

In Chess, you only win when you checkmate the King, which in effect has infinite point value, winner-take-all.

In Go, you win by amount of territory claimed, and it is near impossible for one side to end up with zero territory. Perhaps this is more true to real life.

While AWS boasts an impressive 230+ points of presence, Cloudflare has interconnects with 10,000 networks including "every major ISP, cloud provider, and enterprise". These aren't the same thing, but it reflects the substantially different game that Cloudflare is playing. From the point of view of users, Cloudflare can be much easier to use and is much more of a painkiller than other big cloud services in their stack, despite perhaps having a single digit % of mindshare and wallet share. This puts Cloudflare within a stone's throw of Ben Thompson's other big claim to fame in Tech Strategy, Aggregation Theory (the Intro to Tech Strategy chapter in my book is free if you want my take on it).

Strategically, "Territory over Positioning" happens to be exactly the right call. In a zero-sum market that isn't growing, you want to jockey for position and take out enemies. In a positive-sum, infinitely expanding market like Cloud, you want to encircle them.

Watch for Sente

To quote Wikipedia, a move that overwhelmingly compels a player into a particular follow-up move is said to have "sente" (先手), or "initiative". In most games, the player who maintains "sente" most of the time will win.

There is a lot of speculation that AWS will have to respond somehow to Cloudflare's provocations:

// Detect dark theme var iframe = document.getElementById('tweet-1444016487304364036-383'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1444016487304364036&theme=dark" }

But beyond a standard PR response, I doubt AWS will respond to mere noise - S3 data egress revenues have to take a significant downturn before AWS will be compelled to act. But when it does, every future move of Cloudflare's will be taken increasingly seriously. Cloudflare acts and talks like it has "sente" now, but it isn't real until AWS (or the other big clouds for that matter) feel forced to specifically respond.

Conclusion: Establish, Envelop, Expand

While the tech industry is used to come-from-below disruption, and the software industry is increasingly grasping class-for-the-masses atomic concepts, I believe Cloudflare is writing a new playbook that is the little-guy counterpart of the embrace, extend, extinguish model used by Microsoft.

Because it involves API compatibility, this playbook is particularly relevant to developer tools, and is protected by the Supreme Court ruling in Google v Oracle. If I were to summarize it in three words, looking over Cloudflare's history and annual report, I might call it:

Establish: Establish a foothold in something incumbents don't care enough about
Envelop: Reverse-proxy something that incumbents don't serve customers well on
Expand: cross-sell other premium products and services until they are more customers of you than they are customers of the incumbent.

Given Cloudflare's fundamentally less-centralized approach to growing its cloud, it is no surprise that it announced its first Ethereum product this Birthday Week; although it remains to be seen if a Web2-native company can really drop enough of its assumptions to handle Web3 threats or opportunities. If we are truly in the "early Internet" days of Web3, only the paranoid might survive here. Fortunately, Prince seems to be a vocal fan of Andy Grove as well.

Why do Webdevs keep trying to kill REST?

swyx — Mon, 20 Sep 2021 14:46:38 +0000

Translations: Russian

Edit this chart

Watching recent trends in client-server paradigms, from Apollo GraphQL to React Server Components to Rails Hotwire, I've had a revelation that helped me make sense of it all: They're all abstractions over REST!

There are two schools of thought:

Smart Client: State updates are rendered clientside first, then sent back to the server.
- You can roll your own: Use a state management solution like Redux or Svelte Stores and handwrite every piece of the client-server coordination logic.
- You can use libraries that combine state and data fetching: Apollo Client, React Query, RxDB, GunDB, WatermelonDB and Absurd-SQL all do dual jobs of fetching data and storing related state. (you can see parallel implementations here if evaluating)
- You can use frameworks that abstract it away for you: Blitz.js and Next.js
- Or you can take it off the shelf: Google's Firebase and AWS' Amplify/AppSync are fully vendor provided and vertically integrated with backend resources like auth, database, and storage (arguably MongoDB Realm and Meteor's minimongo before it)
Smart Server: State updates are sent to the server first, which then sends rerenders to the client (whether in HTML chunks, serialized React components, or XML).

Of course the "Smart Server" paradigm isn't wholly new. It has a historical predecessor — let's call it the "Traditional Server" paradigm. The Wordpress, Django, Laravel type frameworks would fill out HTML templates and the browser's only job is to render them and send the next requests. We gradually left that behind for more persistent interactive experiences with client-side JS (nee AJAX). For a long time we were happy with just pinging REST endpoints from the client, ensuring a clean separation of concerns between frontend and backend.

So why are we tearing up the old client-server paradigm? And which side will win?

It's about User Experience

Ironically, the two sides have very different goals in UX and would probably argue that the other is less performant.

Smart clients enable offline-first apps and optimistic updates so your app can keep working without internet and feels instant because you are doing CRUD against a local cache of remote data (I wrote about this in Optimistic, Offline-First Apps and RxDB has a good writeup here).
- This improves perceived performance for apps.
- However their downside is tend to come with large JS bundles upfront: Firebase adds as much as 1mb to your bundle, Amplify got it down to 230kb after a lot of modularization effort, Realm stands at 42kb.
Smart servers directly cut JS weight by doing work serverside rather than clientside, yet seamlessly patching in updates as though they were done clientside. Facebook has reported as high as 29% bundle reduction.
- This improves first-load performance for sites and reduces total JavaScript sent throughout the session.
- However their downside is that every single user of yours is doing their rendering on your server, not their browser. This is bound to be more resource intensive and inserts a full network roundtrip for every user interaction. The problem is mitigated if you can autoscale compute AND storage at the edge (eg with serverless rendering on Cloudflare Workers or AWS Lambda). There are also real security concerns that should get ironed out over time.

The "winner" here, if there is such, will depend on usecase - if you are writing a web app where any delay in response will be felt by users, then you want the smart client approach, but if you are writing an ecommerce site, then your need for speed will favor smart servers.

It's about Developer Experience

Platform SDKs. For the Frontend-Platform-as-a-Service vendors like Firebase and AWS Amplify, their clients are transparently just platform SDKs — since they have total knowledge of your backend, they can offer you a better DX on the frontend with idiomatic language SDKs.
Reducing Boilerplate. Instead of a 2 stage process of writing a backend handler/resolver and then the corresponding frontend API call/optimistic update, you can write the backend once and codegen a custom client, or offer what feels like direct database manipulation on the frontend (with authorization and syncing rules).
- The Smart Server boilerplate reduction is extreme, since the syncing protocol eliminates all need to coordinate client-server interactions. Quote from a LiveView user:
"LiveView is absurd. It's the biggest change I've experienced in web development since Rails v1. I've been able to build rich, interactive, games without a single line of Javascript. It takes complicated server / api / front-end build projects and results in literally 1/10th the amount of code for the same result."
Offline. Both Firebase Firestore and Amplify AppSync also support offline persistence. Since they know your database schema, it's easy to offer a local replica and conflict resolution. There are vendor agnostic alternatives like RxDB or Redux Offline that take more glue work.
- Being Offline-first requires you to have a local replica of your data, which means that doing CRUD against your local replica can be much simpler (see below).
Reducing Boilerplate for Optimistic Updates.
- When you do normal optimistic updates, you have to do 4 things:
  1. send update to server,
  2. optimistically update local state,
  3. complete the optimistic update on server success,
  4. undo the optimistic update on server fail
- With a local database replica, you do 1 thing: write your update to the local DB and wait for it to sync up. The local DB should expose the status of the update (which you can reflect in UI) as well as let you centrally handle failures.
People. This is an organizational, rather than a technological, argument. How many times have your frontend developers been "blocked by backend" on something and now have to wait 2-3 sprints for someone else to deliver something they need? It is hugely disruptive to workflow. Give the developer full stack access to whatever they need to ship features, whether it is serverless functions, database access or something else. Smart Clients/Servers can solve people problems as much as UX problems.
- This is why I am a big champion of shifting the industry divide from "frontend vs backend" to "product vs platform". Chris Coyier's term for this is The All-Powerful Frontend Developer.
- GraphQL is also secretly a "people technology" because it decouples frontend data requirements from a finite set of backend endpoints.

Both smart clients and smart servers greatly improve the DX on all these fronts.

It's about Protocols

Better protocols lead to improved UX (eliminating user-facing errors and offering faster updates) and DX (shifting errors left) and they're so relevant to the "why are you avoiding REST" debate that I split them out to their own category. Technically of course, whatever protocol you use may be a layer atop of REST - if you have a separate layer (like CRDTs) that handles syncing/conflict resolution, then that is the protocol you are really using.

A lot of these comments will feature GraphQL, because it is the non-REST protocol I have the most familiarity with; but please feel free to tell me where other protocols may fit in or differ.

Type Safety: GraphQL validates every request at runtime. trpc does it at compile time.
- Increased type annotation offers better codegen of client SDKs that you would otherwise have to hand-write. This is a much more established norm in gRPC than GraphQL and I'm not sure why.
Bandwidth: Sending less data (or data in a format that improves UX) over the wire
- GraphQL helps solve the overfetching problem. In practice, I think the importance of this is overhyped unless you are Facebook or Airbnb. However the usefulness of persisted queries for solving upload bandwidth problems is underrated.
- Hotwire sends literal HTML Over The wire
- React Server Components sends serialized component data over the wire; more compact because it can assume React, and smoothly coordinated with on-screen loading states
Real-time: offering "live" and "collaborative" experiences on the web
- This is doable with periodic polling and long-polling, but more native protocols like UDP, WebRTC and WebSockets are probably a better solution
- Replicache (used for Next.js Live) and Croquet look interesting here
- UDP itself seems like a foundation that is ripe for much more protocol innovation; even HTTP/3 will be built atop it

There remain some areas for growth that I don't think are adequately answered yet:

Performance: One nightmare of every backend developer is unwittingly letting a given user kick off an expensive query that could choke up system resources. Complexity budgets are not a solved problem in GraphQL. It's a touchy subject, but new protocols can at least open up a more interesting dance between performance and flexibility.
Security: allowing frontend developers direct database access requires much more guard rails around security. Vendors with integrated auth solutions can help somewhat, but the evangelists for a new protocol need to be as loud about their security requirements as they are the developer experience upsides.

Not Everyone is Anti-REST

Yes of course my title is a little clickbaity; REST is perfectly fine for the vast majority of webdevs. There are even people pushing boundaries within the REST paradigm.

Remix, the soon-to-be-launched React metaframework from the creators of React Router, embraces native browser standards so you get progressive enhancement "for free", for example requiring that you POST from a HTML form (they have clarified that anything but GET is fine, and they are pro-HTTP, and neutral REST)
Supabase (where I am an investor) is a "smart client" solution that works equally well on the server, which invests heavily in the open source PostgREST project.

Followups

Transitional Apps

Rich Harris recently gave a keynote at Jamstack conf that framed his take on this issue (TLDR here):

Reader Feedback

Jonathan W: "The framing of the issue got my brain percolating a bit. The entire situation feels very similar to the first time a developer recognizes object-relational impedance mismatch—all the subtle differences that start to crop up as you layer an Application Framework on top of an ORM on top of an RDBMS on top of your business domain (you know, that kind of important topic). Each layer of abstraction is acceptable by itself, but the effects compound at each level and over time."
@thxdr: Other format efforts worth exploring: JSONAPI is a JSON REST spec, and the Relay spec is essentially a GraphQL superset spec

September 11th from Singapore

swyx — Sat, 11 Sep 2021 22:26:53 +0000

I was on the other side of the world when it happened.

My memory is curiously spotty about this major event I lived through. I remember exactly what I was doing at the time; yet I remember almost nothing else after.

Singapore is ~12 hours ahead of New York, so I was just finishing up my night class at home, walking out to our living room TV telegraphing that the world had forever changed. I remember thinking how it was a horrific accident, and then seeing footage of the second plane and realizing it was no accident. I remember the third plane crashing into Pentagon. Then the fourth. Drip-fed to us minute by minute through our local TV news, by scared reporters who barely knew any more than we did.

I don't know how I went to sleep that night. I remember looking at my baby sister, playing in her pen. Totally oblivious that the world she was born into had changed forever. (I would get that feeling again 2 years later, as SARS threatened to lock down Singapore in the first coronavirus outbreak of our lifetimes.)

I didn't have any American friends at the time so it never got personal. But we watched with horror and confusion as the stories trickled out; the Falling Man, the Flight 93 phone calls, the firefighters. I have no memory of how my parents or teachers dealt with it or moved on from it. I was myself unaware of how the military response moved from Afghanistan to Iraq and the intense debate prior and the quagmire after.

As a country with a 22% Muslim population, surrounded by other majority Muslim countries, tensions definitely were tight. First, copycat terrorists had to be preempted. Second, relationships needed to be rebuilt between faiths. We would spend the next 1-7 years doing this.

Travel didn't happen for me until about 4 years later when I went on my first international trip for a choir competition. By then almost all the security measures you have today were in place, including the shoe requirement (which now seems to have faded), although they had yet to ban water, and the X Ray machines weren't as fancy. For sure the days of Rachel casually walking up to a flight 30 minutes before departure were gone.

Later when I learned more about geopolitics we would debate The End of History vs The Clash of Civilizations at school and I recall my classmates having very strong opinions without having really read either book. It's still not clear to me that any of that was at all useful or relevant. I remember reading dire essays about the disruptive threat of nonstate actors, yet, as Noah Smith notes, state power won, once citizens gave up their privacy.

I wish I had journaled more back then. I wish I had told myself how it felt living through what I knew to be a special time. I wish I had close Muslim friends to process it with. And I wish I appreciated the difference between sudden tragedy and chronic, endemic disasters.

The Swipe Files Strategy for Part Time Creators

swyx — Fri, 03 Sep 2021 20:59:46 +0000

What if I told you there was a simple strategy that can help you slow-cook a $300,000 a year side project and kickstart your indie hacker career, on a few hours a week?

If you didn't care about money, how about >100k Twitter follows over 2 years?

Or email subscribers?

Build a swipe file

A "swipe file" is a collection of examples to copy for inspiration. The above screenshots are all real life examples from ReallyGoodEmails and MarketingExamples, both (extraordinarily well executed) swipe files.

I think it is one of the most underrated ways for Part Time Creators to build a newsletter, build a brand, and get good at their craft, without reputation, expertise, or large upfront expenditure in time or money.

Here is a Swipe File Swipe File for creators getting started.

The Strategy

Start a Swipe File
Collect examples
Offer newsletter signup
Offer login + faving
Build a Community
Hit the Media Circuit
Make Generators
Monetize
1. Sell Sponsor ads
2. Do a live workshop
3. Write a book
4. Build a course

I add some more details below but that's the essence of the progression.

I recorded everything below as a 14 minute video if that's your thing.

A Simple Directory

Good swipe files focus in on a niche but important problem, that nobody specializes in. Here is a site that only features og:image inspiration:

It is pretty simple; the design comes from others, but the categorization comes from you. Clicking on each just sends you to the site it came from; no commentary or analysis needed.

In-App Flows

Swipe files are usually static snapshots of public marketing design and copywriting, but there's no reason why you can't document the logged-in experience as well. Here's DesignVault:

Add Commentary

Swipe files lend themselves to marketing and design, because by their very nature they are visual and public. Here is swipefile.com, with just a couple paragraphs of commentary on each example:

Use a Tool

The work gets a lot simpler and faster when you use a tool that is designed for capturing swipe files. Here's Klart:

Build up Teardowns

Corey Haines' SwipeFiles.com (note the plural, different from SwipeFile.com) adds step by step commentary with generalizable lessons (scroll through this to understand):

Compelling How Tos

Switch the focus from a random assortment of "What I like about X" to a more directed "How X does IMPORTANT_THING_EVERYONE_WANTS". Title game is everything. Can you generate the "instant click impulse?"

Offer a Newsletter

Yes, people hate popups. Yes, they work. Yes, you can blanket it with social proof, like Harry Dry does on MarketingExamples.com.

Build an Auth & Storage layer

Since you have people's emails, you might as well give them a way to log in. As your examples pile up, people are going to want to save them to their collections, and you will want to use their faves to indicate popularity. See ReallyGoodEmails.

Build a Community

Since people log in and heart stuff, it'd be nice if they could chat. Circle is the best platform for that. Here's the one I maintain for Learning in Public: https://codingcareer.circle.so/c/learn-in-public

Borrow a Platform

Wow, look at you! Email newsletter, Auth, Storage, Community... you're starting to need some serious software now around your swipe file, and you STILL need to figure out your social media distribution. You don't HAVE to have a separate platform — I often use my own Twitter as a flexible social Swipe File, and Little Big Details is a Swipe File hosted on Tumblr with distribution, storage, and social features built in.

Just keep in mind that you're borrowing that platform; if you didn't build it, it's not yours, and can be taken away at any time.

Make Generators and Prompts

If you CAN code though, you can level up your swipe file by letting people play mad libs with it (aka templatize your swipe file). Here's What To Tweet from Josh Spector:

Or the Blog Post Idea Generator:

And if you get really, really lucky, you can turn these templates into a 7 figure business.

Hit the Media Circuit

With some initial success, it's time to hit the media circuit to get the attention up for the work you've already done. Conferences, Podcasts, Contributed articles.

Time to Monetize

But I Don't Do Marketing Or Design

Don't be so literal about what a swipe file is — pay attention to the spirit of the thing. Mental Models are swipe files of perspectives to analyze given situations. A tweet thread of frameworks is a swipe file of playbooks. My Cheatsheets are swipe files of code, as is useHooks:

All enormously useful, passively compounding sources of personal leverage for your creator journey.

3 Reasons to Upgrade Git For The First Time Ever

swyx — Mon, 30 Aug 2021 22:29:07 +0000

Git moves at a surprisingly fast pace - as of Aug 2021, the current version of Git (git --version) is 2.33.

I don't normally know or care what my Git version is, but over the past year this changed. The Git team must be doing something right, because I've noticed a few things trickle down to my relatively light usage:

`init.defaultBranch`

The default branch in Git is named master. As of Git 2.28, you can now configure it to anything else. Of course, this is merely symbolic but is an appreciated signal.

git config --global init.defaultBranch main

This setting will work for new repos. For existing repos, and git aliases that work nicely with BOTH master and main, you can see my Cheatsheet for moving from Master to Main.

`git sparse-checkout`

You probably know about git clone -–depth 1 [remote-url] for repos where you don't want to download the full history. Git 2.25 introduced an additional command for giant repos, where even the current version is too big. So sparse checkout is like git clone --depth 1 but for files:

git clone --no-checkout https://github.com/my/big-repo
cd big-repo/
# only files at the root
git sparse-checkout init --cone 
# only files in specific directories (recursive)
git sparse-checkout set <dir1> <dir2> ...

# do it
git checkout main

`git restore`

I needed this one today. Basically if you screw up a file and need to bring it back from Git, you can use the new git restore command in v2.23:

git restore path/to/file # discard current changes
git restore --staged path/to/file # unstage staged file
git restore --source [hash] path/to/file  ## restore from specific commit hash

⚠️ Be careful - once you run this command you cannot get back the changes you discard.

Yes, there are confusingly similar commands between checkout, restore, reset, and even switch. This StackOverflow answer clarifies pretty authoritatively:

git-revert is about making a new commit that reverts the changes made by other commits.
git-restore is about restoring files in the working tree from either the index or another commit. This command does not update your branch. The command can also be used to restore files in the index from another commit.
git-reset is about updating your branch, moving the tip in order to add or remove commits from the branch. This operation changes the commit history. git reset can also be used to restore the index, overlapping with git restore.

DEV Community: swyx

Running Docker without Docker Desktop

TL;DR

Context

Why TurboRepo Will Be The First Big Trend of 2022

TLDR

Why Monorepos

Origin of TurboRepo

What TurboRepo does

How to use TurboRepo

The turbo config key

Remote Caching

The Future

What About Nx?

Personal Takeaways

Followup: Nx Chat

Further reading

Using Datasette for an ELT Personal Twitter Data Warehouse

TL;DR

The How

Optional: Get Credentials

Optional: Test Your Credentials

Scraping your data with twitter-to-sqlite

Deploying to Glitch

The Why

Further Reading

How to customize your Transistor.fm Website with JS and CSS

How To Video (3mins)

Code

Other customization ideas

Fave New Podcasts in 2021

Best New Tech Podcasts in 2021

Best New Business/Crypto Podcasts in 2021

Best New Creator/General Podcasts in 2021

Context

Good But Dead

Still Good

Community Heat, or Why You Should Get Good at Events

Community Heat

Get Good at Events

Venue

Frequency

Naming

Curation

Marketing

Post Production

100 Bytes of CSS to look great everywhere

TL;DR

Context

100 bytes of css to look great nearly everywhere

Optional 100 more bytes

Applying Styles on Pages You Don't Control

Eating the Cloud from Outside In

Two Kinds of Disruption

Cloudflare and the Rules of Go

Storage Capture

Product Strategy

Territory Wins

Watch for Sente

Conclusion: Establish, Envelop, Expand

Why do Webdevs keep trying to kill REST?

It's about User Experience

It's about Developer Experience

It's about Protocols

Not Everyone is Anti-REST

Followups

Transitional Apps

Reader Feedback

September 11th from Singapore

The Swipe Files Strategy for Part Time Creators

Build a swipe file

The Strategy

A Simple Directory

In-App Flows

Add Commentary

Use a Tool

Build up Teardowns

Compelling How Tos

Offer a Newsletter

Build an Auth & Storage layer

The `turbo` config key

`init.defaultBranch`

`git sparse-checkout`

`git restore`