davepeck

Yes, of course; that was clearly the high-order bit.

But even if it was dominant my hunch is it was unlikely the only factor: Bluesky also rapidly outgrew Mastodon, without a Meta-like advantage.

I think of Django's templating system as a great tool for a previous era. I'm hopeful that PEP 750 [1] gets accepted and a modern ecosystem of template engines emerges in Python-land. For the moment, I tend to use in-python builders like htpy [2] when I want back-end Python code to generate some HTML.

[1] https://pep-previews--4124.org.readthedocs.build/pep-0750/

[2] https://htpy.dev

Yeah, absolutely. Despite its growth, IMHO Mastodon is still a usability mess in the sense that a typical user will find it needlessly complicated compared to any alternative that is perceived as equivalent. The confusion starts early, with onboarding. I think this is one of the reasons why, for instance, Threads became a larger social network in its first ~24 hours than Mastodon had in its entire 6-ish year run to that point.

Alas, this is par for the course in the Fediverse. Mastodon is the only ActivityPub-using social network I'm aware of that has broken away from this. (Maybe Lemmy, to some degree?)

Social networks that focus on people and user experience have a shot. My hunch is those -- like PeerTube -- that focus on technical, political, or philosophical motivations will always be niche at best.

(Which is not to discourage experimentation! This seems to be a fantastic moment to experiment with social media design.)

Yes! I’ve had my eye on it but haven’t had a chance to use it (yet).

Beautiful.

And: it’s exciting to see more mass timber construction in the PNW. Closer to home for me is the University of Washington’s Founder’s Hall: https://www.archpaper.com/2022/10/lmn-architects-completes-u...

I really like Astro:

1. It's the most flexible yet easily configured static site generator I've used to date

2. It's reliable. The docs are well maintained and, mirabile dictu, the real behavior of the system matches its documented behavior

3. It's stable. Lots of new features are getting added, but (so far) upgrades don't break things

4. It has good tooling for editors like vscode

5. Many of my current projects take the form of "big data pipeline, followed by intermittent job to rebuild a static site and push it live"; astro fits very nicely in this role

Caveat: I use exactly none of Astro's backend features. I understand why they've added them but, for me, it's all about static site generation.

About the only thing I don't like is the weirdness of the boundary between astro components and framework components. I get it, but still. It's something to carefully consider when building each new astro site.

It's a genuine tragedy.

We were members. It was a fun and interesting place to go to with kiddos every now and then -- particularly on a rainy day. Kids could goof off or, if interested, actually learn. And it was a great resource and community for us local adult nerds.

Okay, one photo of my (then much younger) daughter, for old times' sake: https://davepeck.org/random/kiddo-lcm.jpg

Rectangle (OSS), Moom, and Magnet are all good options if you want to go beyond what Sequoia supports. I've used Moom for years and particularly like its behavior when external monitors are added/removed.

Peewee never quite got there IMO, and it hasn't kept up with the times (modern asyncio, etc.)

I may be the wrong person to answer, alas. I nearly entirely avoid the machinery of web components.

With the stack above, I typically write small classes that derive from HTMLElement and implement a couple key callbacks (usually, connectedCallback and disconnectedCallback). In those, I typically (a) initialize state by reading attributes from the DOM and (b) configure event handlers. Pretty simple.

That's... about it. I'm templating elsewhere, so I avoid using web component templates. And the less I think about the shadow DOM, the better.

For this, the MDN documentation on custom components is enough.

I'm excited to see more projects like Rio exploring the full-stack python web dev space. There are definitely categories of users for which the approach makes sense.

---

For me personally -- and I'm guessing for a bunch of other HNers -- writing full-stack web apps strictly in python is a non-goal.

I've settled on a comfortable (for me) stack for smaller projects that need python on the backend that combines:

1. Litestar (or another lightweight HTTP framework of choice like flask, etc.)

2. HTMX

3. htpy.dev (an in-python HTML builder)

4. Custom web components implemented in a plain-old JavaScript ES6 module loaded directly by the browser

A typical project only needs a handful of components. HTMX and htpy.dev both play very nicely with web components.

When I want zero build steps, I write plain JavaScript + JSDoc comments. JSDoc is... okay-ish, but it ain't no typescript.

If I need a database, I'll grab SQLAlchemy. I wish there were a mature lightweight solution here; maybe Tortoise ORM will get there soon?

There's nothing in this stack that couldn't strictly be done in javascript-land. JSX syntax with HTMX is pretty great and much better than any in-python HTML builder. But often my projects have other requirements (like ML) where python is, at least today, inevitable.

Sleep apnea detection is coming to the series 9 too.

If you've already got k8s set up and you're comfortable with it, I'm not sure that Dokku offers much?

But... wow. For my single non-k8s server at home, Dokku makes getting stuff running behind HTTPS about as simple as I could hope for!

Third party tools (mypy, pyright, etc) are expected to check types. cpython itself does not. This will run just fine:

python -c "x: int = 'not_an_int'"

My opinion is that with PEP 695 landing in Python 3.12, the type system itself is starting to feel robust.

These days, the python ecosystem's key packages all tend to have extensive type hints.

The type checkers are of varying quality; my experience is that pyright is fast and correct, while mypy (not having the backing of a Microsoft) is slower and lags on features a little bit -- for instance, mypy still hasn't finalized support for PEP 695 syntax.

“X is unsuitable for large projects” when there are many readily discovered existence proofs to the contrary (including but not limited to $1B+ businesses, massive communities, deep thoughtful and disciplined engineering spokespeople, etc.) strikes me as a common trope here on HN.

(Which is not to say X is flawless even at scale or a clear best fit along all axes. That is true for no X that I know of.)

Always nice to learn about new Seattle startups. Curious who funded you?

Yeah, the lack of HTTP/2 support has been a long-standing issue with Heroku.

They just shipped HTTP/2 terminated at their router [0], and have it on their roadmap [1] to support HTTP/2 all the way through. But it seems like it's at minimum a few months off.

(As for VPC peering: the moment you need that, it sorta feels like Heroku is no longer the right place to be, even ignoring the costs.)

[0] https://blog.heroku.com/heroku-http2-public-beta [1] https://github.com/orgs/heroku/projects/130

Yes, completely agree; I'm equally surprised by the poor DXes.

(And: bugs. I'm also surprised by the kinds of issues I run into on some of those sites in my list -- problems that, even if not show-stopping, feel like revealing indicators of quality.)

Mostly that I don't have enough experience working with Astro on things that are more sophisticated than "interesting CMS-backed blog or publication" to really comment. Secondarily that there are plenty of tools, some quite venerable at this point (Rails! Django!), that have the more complex terrain covered already.

I do, as do several startups I advise.

Despite interesting competition, my feeling is that the Heroku of 2024 remains... Heroku.

I feel this way even though -- depending on how you segment -- the list of "interesting" competitors is quite long at this point: Render, Railway, Northflank, Fly.io, Vercel, DO App Platform, etc.

I think Astro is great for building small mostly (or entirely) static sites. It doesn't assume that you're building a blog, but it's plenty flexible enough to support it.

This said, blogs feel like a nice sweet spot for Astro. The current version of my blog came together without much fuss. (I've studiously avoided using Astro DB, or using Astro to build an API backend, etc. and so can't comment on them.)

Overall I've found Astro to be highly reliable. I identified one unexpected behavior (I think a bug, related to when CSS is rendered) while building my blog and was able to work around it but, other than that, Astro behaved exactly as documented.

There were days I wished that astro components didn't exist and, instead, I could just use the client:* attributes in (say) my Preact components. That said, astro components are well thought out and the tooling in vscode is solid.

25 years last month.

Hand-spun HTML on day one; cobbled-together scripts for the next many years; Jekyll once it hit 1.0; today, Astro.

It feels like a real "moment" where people are reconsidering blogging and personal domain names; I'm excited to see what comes of it.

The OP seems targeted at devs who are already quite familiar with Temporal and are interested in using the new Python exposure.

FWIW, as someone who has never previously encountered Temporal, and has only a vague sense of the specific problem set it's trying to tackle and architectural approach it has taken, I find the post to be fairly impenetrable.

I'd love to read a proper introduction to Temporal by way of Python (and probably also by comparison to Celery).

I took this course ages ago, along with the follow up Crypto II. Dan is a great instructor, and his courses helped fill in a number of gaps in my knowledge. Highly recommended!

Is anyone else running into problems with Cloudflare? All I see when visiting the leaderboard is a Cloudflare error page saying "Please unblock challenges.cloudflare.com to proceed."

But as far as I can tell, challenges.cloudflare.com isn't blocked by browser plugins, my home network, or my ISP.

Related: executeprogram.com is an excellent learning platform that combines spaced repetition with interactive lessons targeted at professional developers.

That rings a bell although fuzzily: as the new kid from school, I was pretty disconnected from the politics of the moment. I do seem to remember that the MineSet team departed en masse, but IIRC that departure roughly coincided with broader layoffs in the org.

(With apologies for reviving 90s IRIX/Solaris snark in my earlier post. :-)

Yeah, the O2 definitely was too expensive for what it was. And while it was the least cool and powerful of the lineup by far, as a recent college grad, it was still the coolest computer I had ever had on my desk. ;-)

Yeah, makes sense.

I’m also in a phase where I get to start a lot of new low-stakes web projects, so I’ve made a point of adopting at least one new-to-me tool for each. I love typescript, and am generally happy with modern front-end tooling, but the node back-end ecosystem drives me bonkers — too many paper-cuts from too many tools along the lines you’ve documented here — and has me regularly retreating back to Python or Ruby land.