Not these days in my experience. Maybe 5-10 years ago. I imagine Google is so indundated with so much spam, and AI slop they are being more discrimantory on what to crawl and index
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?
Is Google supposed to have drastic updates to its index over 2 weeks?
reply