What was it specifically about the style that stood out as incongruous, or that hindered comprehension? What was it that made you stumble and start paying close attention to the style rather than to the message? I am looking at the two examples, and I can't see anything wrong with them, especially in the context of the article. They both employ the same rhetorical technique of antithesis, a juxtaposition of contrasting ideas. Surely people wrote like this before? Surely no-one complained?
The problem is less with the style itself and more that it's strongly associated with low-effort content which is going to waste the readers time. It would be nice to be able to give everything the benefit of the doubt, but humans have finite time and LLMs have infinite capacity for producing trite or inaccurate drivel, so readers end up reflexively using LLM tells as a litmus test for (lack of) quality in order to cut through the noise.
You might say well, it's on the Cloudflare blog so it must have some merit, but after the Matrix incident...
I find it more amusing that the benchmarks claim 530 GB/s throughput on an M1 Pro which has a 200GB/s memory bandwidth. The 275 GB/s figure for chained transforms has the same problem.
I suspect the benchmarks, if not most of this project, was completely vibecoded. There are a number of code smells, including links to deleted files, such as https://github.com/jasnell/new-streams/blob/ddc8f8d8dda31b4b... an inexistent REFACTOR-TODO.md
These AI signals will die out soon. The models are overusing actual human writing patterns, the humans are noticing and changing how they write, the models are updated, new patterns emerge, etc, etc. The best signal for the quality of writing will always be the source, even if they are "just" prompting the model. I think we can let one incident slide, but they are on notice.
Never heard of them either. But the link in the title is to Jack Dorsey's tweet. Now him I have heard of. Didn't know he was involved in that company too.
I think it's okay to complain about the design and presentation of the ads even on a free service. It's unreasonable to expect sites not to have some form of monetization of users that are not going to pay for the content, but that monetization should be reasonable and thoughtful. Of course, we can simply avoid that site altogether.
> but grammar privilege? That's certainly a first.
Here is what I don't understand, and what is not addressed in the post.
After you get a response from your boss that reads, "K let circle back nxt week bout it . thnks", doesn't this free you up to relax your style to your comfort level? If you see that your addressee doesn't seem to care for meticulous style, is there much point in stressing over it (and thus, in continuing with the privilege narrative)?
Unfortunately there is a double standard at play. When people see a sloppy email from a powerful person, they think “they must be so busy that they don’t have time to check grammar”. But when it comes from a low-level employee they think “oh they must be careless or uneducated”.
except it's sort of true and a reasonable assumption to make? Just as when a master painter makes something that looks "sloppy" to the layman, one immediately assumes there is some deep artistry behind it as opposed to poor technique, whereas when a child does it, one does not extend the same charitable attitude.
Sure I think there's some truth the that. You've gotta learn the rules first to know when it's ok break the rules. Somebody with a lot of experience should be able to judge how their message will be received, and what amount of effort is "good enough". Whereas someone with less workspace experience may lack such judgement, and is probably better off erring on the side of "too good" rather than "not good enough".
But it's definitely also very much tied to status, power, and privilege. The same people who have no qualms about firing off a sloppy email to their subordinates often spend a lot more effort on emails to their bosses. But even this discrepancy is justified, I think, given that a manager represents their subordinates to the higher ups. And the potential consequences of a bad impression or misunderstanding are more severe when communicating up the chain of command.
No, I read that they know they have the power so they don't care, and I'm not powerful enough to not. It's like listening to your boss's boss talking about his heli-skiing adventures.
> Letting google implement a new language for the web would probably result in something even worse than javascript.
Why? Javascript was famously written in ten days, was intended for casual scripting, and has not made up its mind whether it wants to be a Java or a Scheme. What could google invent that would be worse?
> It (and also React) gets worse if you add a state system like RxJS.
I don't understand this sentiment.
Client-side applications often have a need for global state. It could be as simple as whether the user is logged in, or as complex as, say, the shapes that you have drawn in excalidraw canvas, and the drawing tool that you have selected. State changes over time, and so it seemed plausible to model it as a stream of states over time (hence rxjs). There are more robust ways to deal with the state, which is why angular has now moved to signals; but what is so bad about the state?
RxJS is far more robust than signals (things like backpressure operators, scheduling operators, and more). Angular's move to signals is just another sign of what Angular was doing wrong with RxJS all along: Angular could have used the robustness of RxJS to make a better framework but at many decisions along the way chose to not trust RxJS to do its jobs, skipped operators for the sake of leaking imperative state back out into the world and/or treating RxJS like heavyweight Promises (which indeed they are heavy and unweildy in that context). Signals enshrine the imperative leaks as the preferred and final path forward, further crippling the robustness RxJS could have offered and yet also doesn't entirely eliminate RxJS as a dependency.
Angular was born broken in how it made use of RxJS. A lot of developers have a bad impression of RxJS simply because Angular led them to so many RxJS worst practices, bad performance, and taught them that RxJS was just "heavy Promises".
RxJS has an intrinsic diamond problem (multiple events fired when several sources update simultaneously), which led to occasional glitches. Signals are guaranteed not to have that problem. This is a strong argument in their favor.
But yeah; I am amazed and amused by how, during the past couple of years, the interest to rxjs has plummeted. No more conference talks on this topic. And even though Observables have been released natively, there is no activity in the rxjs repo to update the library accordingly.
As with most RxJS problems the diamond dependency problem can often be fixed/solved with the right combination of even more advanced operators/combinators. Often the easiest solution is `combineLatest`, but as mention that will over-fire depending on your update patterns. Sometimes a simple `throttle` is all the backpressure fix you need on that to reduce diamond over-firing, especially in combination with a cool scheduler such as `animationFrameScheduler` [0]. However there are also other domain-specific replacement options for `combineLatest` if you know the general event firing pattern such as `withLatestFrom`, `zip` [1], `join` [2], or `and/thenDo/when` [3] (in increasing complexity). (ETA: Not to mention that many diamond dependency problems are just fan out problems that can be solved by refactoring computations to an earlier point in the pipeline before the fan out rather than trying to fan back in.)
> And even though Observables have been released natively, there is no activity in the rxjs repo to update the library accordingly.
I believe this is still reversed: "native" Observables, the WICG Observables Proposal [4] is still marked as a Draft Group Report (not even officially a Proposal, still, ouch). The Issues of the RxJS repo still seem to indicate that everything is still in a holding pattern waiting for that to move.
I still cynically think this is yet another case of WICG holding the football in front of RxJS and just as likely as Lucy would do to Charlie Brown, will pull that football again right as they try to kick it, again. The WICG has acted like there is renewed interest in Native Observables but my cynicism thinks they are just rehearing drafts on it to appease the Observables crowd just long enough to claim more interest/easier implementation in Native Signals and try to get a Native Signals Proposal passed without good Observables interop. (But again, I'm a cynic here.)
The entire npm package is 4.5 MBs uncompressed, and that includes a lot of files that won't be included in a modern bundle. A simple `npx esbuild --bundle ./node_modules/rxjs/dist/esm/index.js --outfile=./vendor/rxjs.js --format=esm` gives me a 141 kb file before compression.
If you are seeing 18 MBs in your bundle from npm you may have more than copy or something else wrong.
I will complain that RxJS still doesn't have a proper ESM build in 2026 for even better tree-shaking because that is apparently waiting on the WICG Observables "Proposal" to complete, and cynically I still don't think it is going to happen and I would love real ESM from RxJS someday like yesterday.
I think digressions about React dilute the message. Ok, we get it, react bad; but what is the actionable message here? What are the robust alternatives? There is a section on how changes to react (the introduction of hooks and of the concurrent mode) necessitated significant code changes almost amounting to rewrites; but which alternatives, other than vanilla web platform, can promise long-term stability? Which alternatives are better suited for which kinds of applications (roughly, an e-commerce site vs excalidraw)?
> And the new framework is so niche it's now hard to hire for it.
Why do you need to specifically "hire for a framework"? Wouldn't any front-end developer be able to pick up any front-end framework (unless it's outside the javascript space entirely, and requires knowledge of purescript, rescript, elm, rust, clojure, scala, etc.)
I don't want to dox myself by getting too specific, but yes it's essentially a frontend framework for backend engineers in a niche lang (at least, niche for frontend). So they'd just hire more backend engineers in their language of choice.
I think this might actually be fine for internal tooling, but this is a customer-facing web app. It's now incredibly clunky and every feature takes an age to get out. Full page reloads for everything, etc.
> The browser ... wasn’t architected to run applications.
Could you explain this? What prevents the browser from running applications? How should it have been architected otherwise if running applications was the goal?
If you move the data (the M and the C) entirely out of react, and only pass it in via props, there would be only one place — the root react node — where the props could get into react. Is this what you have in mind? Or are you envisioning multiple root nodes?
Well, i've always been a fan of the island architecture that effectively mounts root nodes as little islands of isolated state, yes.
Mainly this avoids the hell that global state SPA patterns produce: redux, reducer patterns in general, and 8 thousand context providers.
I do think there's use cases that warrant global in-memory state, but it's such a pain in the ass to maintain and evolve, i'd always plan against it. Every html node in your app does not need to know about literally everything going on and react instantly to it. it just doesn't.
Just make another page!
Also: so the islands pattern can be as fancy or rudimentary as desired. they can bootstrap themselves via async endpoints, they can be shipped as web components even, or they can be static, pre-hydrated in some manner.
Do you need react at this point? Isn’t it just html/css/components?
I remember the birth of React was because Facebook had a problem - you would add a comment and your notification bar would sometimes not get updated.
They had so many bugs with normal html / css that they wanted to solve this on the application layer - to make inconsistent UI elements unrepresentable.
So they came up with react with global state - because in their use case changing one thing does affect a bunch of other unrelated things, and they all need to sync together.
I mean honestly that’s what I use React _for_ - especially with contexts it’s very easy to express all of this complex interconnected state of a webapp in a consistent way.
And of course there are other ways to solve it - for example with elixir/phoenix you just push all that complexity to the backend and trust in websockets and the BEAM.
I just feel that if you really don’t need global state, then react kinda isn’t needed as well…
> I just feel that if you really don’t need global state, then react kinda isn’t needed as well…
I don't know, in my mind "re-render (efficiently) when state changes" is the core point of react and similar frameworks. That requirement still stands even if I have a smaller, local state.
The islands pattern is underrated for maintainability. I've found the biggest win isn't even the state isolation — it's that each island can have a completely independent upgrade path. You can rewrite one island from React to vanilla JS (or whatever comes next) without touching anything else.
The global state SPA pattern fails for a more fundamental reason than just being painful to maintain: it creates an implicit contract between every component in the app. Change one reducer and you're debugging side effects three layers away. Islands make the contract explicit — each one owns its data, full stop.
The one gotcha I've hit is cross-island communication. PostMessage works but gets messy. Custom events on a shared DOM ancestor end up being the cleanest pattern for the rare cases where islands genuinely need to coordinate.
That is the classic Flow model or Redux model (if you prefer the common implementation name over the Facebook paper name). Build a central store. Pass the single store down to all necessary components via prop-drilling, then later Contexts (and HOCs) to skip layers as a nice-to-have.
Redux is a lot less fashionable today, but hasn't entirely disappeared as an M and C option.
I think the parent wants to separate the V from the M/C. If you smuggle signals inside of components to avoid prop drilling, you would be coupling the M/C and the V. I suppose that's not what the parent has in mind.
M stands for Model layer. This layer handles business logic and knows nothing about UI. It does not have any html or CSS.
V stands for View. This layer handles HTML and CSS. You can use React here.
C stands for Controller. Controllers know about Views and Models and which model objects to instantiate for which view. It makes REST API calls and does caching, and handles errors. Controllers know about the application state and decide what page to display next.
In the original MVC architecture, the fundamental idea was that the model was responsible for storing the application state, a view was responsible for rendering output to the user, and a controller was responsible for responding to user interactions.
The model can be completely unaware of any specific views or controllers. It only needs to provide an interface allowing views to observe the current state and controllers to update that state.
In practice, views and controllers usually aren’t independent and instead come as a pair. This is because most modern UIs use some kind of event-driven architecture where user interactions are indicated by events from some component rendered by the view that the controller then handles.
My go-to example to understand why this architecture is helpful is a UI that features a table showing some names and a count for each, alongside a chart visualising that data graphically. Here you would have a model that stores the names and counts as pure data, and you would have two view+controller pairs, one managing the table and one the chart. Each view observes the model and renders an updated table or chart when the model state changes. Each controller responds to user interactions that perhaps edit a name or change its count — whether by typing a new value as text in an editable table cell or by dragging somewhere relevant in the chart — by telling the model to update its state to match (which in turn causes all views observing the model to refresh, without any further action from whichever controller happened to be handling that user interaction).
In practical terms for a React application, we might implement this with a simple object/Map somewhere that holds the names and values (our “model”) and two top-level React components that each get rendered once into some appropriate container within the page. Each component would have props to pass in (a) the current state and (b) any functions to be called when the user makes a change. Then you just write some simple glue logic in plain old JavaScript/TypeScript that handles keeping track of observers of the model, registering an observer for each top-level component that causes it rerender when the state changes, and providing a handler for each type of change the user is allowed to make that updates the state and then notifies the observers.
There are lots of variations on this theme, for example once you start needing more complicated business logic to interpret a user interaction and decide what state change is required or you need to synchronise your front-end model state with some remote service. However, you can scale a very long way with the basic principle that you hold your application state as pure data in a model that doesn’t know anything about any specific user interface or remote service and instead provides an interface for any other modules in the system to observe and/or update that state.
reply