I was playing around with ways to use this in markdown 12 years or so ago: github.com/ForbesLindes... I remember having a lot of fun with it.
26.01.2026 08:54
👍 0
🔁 0
💬 0
📌 0
I was playing around with ways to use this in markdown 12 years or so ago: github.com/ForbesLindes... I remember having a lot of fun with it.
Runtime validation for TypeScript:
I’ve just launched a new documentation site for funtypes, along with version 6.0.0, which has a smaller bundle size, better type inference, and better error messages.
funtypes.dev
Thank you for building this. Today I was able to use it to ship a new version of www.npmjs.com/package/funt... that's ESM only. I would otherwise have needed to keep supporting CommonJS for much longer. It removes so much mess.
First and likely the most anticipated, marking require(esm) as stable. I wrote a blog post about the journey of it going from experiment to stability: joyeecheung.github.io/blog/2025/12...
It's one of my favourite TV shows. The pilot is way longer than any of the other episodes as it has to introduce everyone. The other episodes are much quicker to get into the action.
Automatically updating content can be extremely distracting, especially for users with vestibular disorders or attention difficulties. This could force users to scroll through page content to not see the animation, or to just look away. Allow animations to be paused or stopped.
That seems like it would make it a bad way to execute anything.
In many games I'm happy for my character not to share my physical limitations, but it would be nice to occasionally have the option to put more of myself into my character.
Most recently I've been playing Baldur's Gate 3, where my character carries a staff on their back, but I wish I could have them hold the staff in their hand as they walk. I assume it just didn't occur to the developers that anyone would want that, or maybe it was just too much extra work to animate.
This seems every bit as relevant today as when it was written. I use a walking stick due to a physical disability, and it's disappointing how rarely that can be represented in video game characters.
This post by @samwho.dev explaining Big-O notation in human terms with concise code samples and simple illustrative demos is a joy to read. samwho.dev/big-o/
The vite plugin (www.npmjs.com/package/@vit...) also looks like it may be a useful reference point. I imagine the article would guide you through building something like that, but the most basic possible version with the minimal features to make RSC work.
This would be awesome, and I wouldn’t mind helping out. overreacted.io/why-does-rsc... and devongovett.me/blog/parcel-... do get you a lot of the way there, but a minimal implementation of react-server-dom-yourbundler is missing, and would be extremely difficult to build on public APIs.
I think you underestimate what the community can build when you don't actively exclude them. I'm not asking you to teach anyone how to build a bundler.
It's a little disappointing that the advice seems to be "please don't try to understand this, it's too difficult for you". I think the reason people can't contribute is largely that github.com/facebook/rea... and github.com/facebook/rea... don't seem to be published to npm, and partly a lack of docs
If I have time I'll try and pick apart the webpack example. It's tricky to even work out where it's calling react though as it's referencing packages like "react-client", which I'm guessing are bundled as part of preparing it for npm.
Not sure what `npm install react-dom-<bundler>` is? That's not a valid package name.
I wouldn't want to write a PR for these docs without first having docs for the APIs that the bundler is meant to generate calls to. i.e. bsky.app/profile/forb...
It does repeatedly say things like "They are rendered before your application is bundled" though, which is either wrong, or using "bundled" to mean something different to how "bundled" is typically used in frontend development.
I think it does mostly say most of this, that's how I've got to the point of understanding what I understand so far, which I'm not confident is fully correct.
As I understand it, the only special thing the bundler has to do is to call a React API after the page loads to give React a reference to the client components it needs. I can't find any docs for that API though.
It would help a lot to document the process of using them without a framework. i.e. for a toy example, what does the output of a bundler look like for a single RSC rendering a single "Client Component".
I think it may take a page to explain what they are, but I think it's better to give people not enough information to form a full mental model, than give them info that forms an incorrect mental model.
If you're willing to make more radical changes, I'd consider something like "'Server Components' are a new type of Component that renders in an environment that's separate from your existing 'Client Components' (whether those Client Components are rendered in the browser or using SSR)."
As a starting point, I'd consider "Server Components are a new type of Component that renders in an environment separate from your client app or SSR."
i.e. remove the parts of the existing sentence that are not true in many (most?) environments.
If most devs don't understand bundling, the existing explanation is confusing because it includes bundling, which devs don't understand.
If devs do understand bundling, the existing explanation is confusing because this explanation does not correctly map to how bundling works in most applications.
Related to this, it's worth noting that SSR doesn't necessarily even run the bundles, it can be running the same code un-bundled in a node.js environment.
I think it's really more of a trust boundary than a network boundary. "client" is the untrusted environment directly handling user input. RSC is the trusted environment with potentially direct database access.
I think "Frontend"/"Backend" would be clearer, as at least those terms are not already given specific (conflicting) meanings in the React docs.
It's also reusing the term "server", which is already used in "SSR", making the docs far more confusing than they need to be. There's also a network gap within "client" between SSR and rendering in the browser, and there's not guaranteed to be a network gap between SSR and RSC.