Here is why you SHOULD NOT use Vercel's `ai-element` library in production AT ALL: it is violating basically every rule of React.
@skk.moe
zh-CN & en-US / Gen Z / http://git.io/sukkaw / http://skk.moe / https://blog.skk.moe / Vibe Code Cleanup Specialist / Senior FE dev / Contributing to OSS and creating PRs for fun / All opinions are my own, literally all of them.
Here is why you SHOULD NOT use Vercel's `ai-element` library in production AT ALL: it is violating basically every rule of React.
It really shocks me that @vercel.com 's `ai-elements` library violates so many Rules of React:
- Read and write ref during render.
- Calling setState directly inside useEffect.
And this is a company who claims they write the best React.
Here is the speed you get from the $299 priced #UniFi flagship Wi-Fi AP: only 324 Mbps down, while 1012 Mbps up.
The UniFi support engineer agrees that my test methods are legit, but can't give any help on improving the Wireless performance.
Here is what @ubiquiti.bsky.social $299 #UniFi Flagship Wireless AP can get you: only 324 Mbps down and 1012 Mbps up. Their support engineer can't give any help. DO NOT BUY anything from #BugFi, they can't even beat $20 Wireless Routers. They really do help you #RethinkingIT.
You may already know that, in React, updating what the parent (e.g. global layout) should render from child components (e.g. page) is bad, because it breaks one-way data flow.
But do you know React Portal is the rescue? There is a ready-to-use utility now: foxact.skk.moe/magic-portal/
Why is Safari the modern IE? This is discovered by @rschristian.dev , and here I am quoting again:
> for us to continue to develop WebKit we now need to use Firefox or another non-WebKit browser to land pull requests.
bugs.webkit.org/show_bug.cgi...
BTW, `requestIdleCallback` is still missing.
# The Frustration of Developing a Plugin for Next.js Developing a Next.js plugin can be and will be an absolute nightmare, thanks to Vercel's complex and opaque nature of the framework's internals, unorthodox conventions, and lack of documentation/communication/explanation of the framework's convoluted infrastructures, leaving developers like me to reverse-engineer spaghetti code without any support. As a former Next.js enthusiast, top 47# contributor of Next.js with over 80 merged PRs, was featured in Next.js Conf 2024 as a distinguished contributor, was invited to Vercel's `#external-next-contributor` Slack channel, I still got zero useful responses from the Next.js team or Vercel when I desperately sought answers. Now, imagine the hell for average users who aren't insiders: they could be doomed to endless frustration, hacks, and broken features. Vercel's opacity and silence have crushed my passion for Next.js, turning what should be an empowering open-source tool into a betrayal of its community, especially those of us who poured our hearts into it. This isn't just about complexityโit's neglect that sabotages innovation and leaves contributors feeling utterly abandoned.
I have spent the past months developing a plugin for @nextjs.org and App Router. It is an absolute nightmare.
The image contains all the bullet points. But if you are interested, here is the link to the article containing the full story behind the struggle: github.com/SukkaW/style...
That's only 3 weeks. Look at my dead simple PR toward @nextjs.org , took them 3 months to merge: github.com/vercel/next....
#TodayMyPullRequest
Make @fastify.dev's etag 70% to 110% faster on medium (2 KiB) to large (2 MiB) inputs:
github.com/fastify/fast...
As I said, @pypi.org already supports setting up a trusted publisher while creating a new package. It demonstrates it is doable.
The real problem is why @npmjs.bsky.social / @github.com not implementing the same.
Why is @github.com and @npmjs.bsky.social 's the trusted publisher feature stupid? The simplest thing: how do I set up the trusted publisher if I am creating a brand new package?
In the meantime, @pypi.org allows you to set up the trusted publisher before/while creating a new package.
Announcing eslint-react.xyz v2.0.0: Now ESM-Only
eslint-react.xyz/docs/release...
Every element on the Wi-Fi setting page of macOS 26 is misaligned.
I already know macOS 26's new design is suck, I didn't know it would end up this kind of suck.
But what happens if you opt in for a package because of its needs, and then it gets compromised after you trusted it?
Once again, my proposed github.com/pnpm/pnpm/is... would protect the community against such attacks. Yet @pnpm.io refuses to implement this.
Multi-threaded linting creates extra challenges (and overheads) for many popular ESLint plugins: typescript-eslint, eslint-plugin-import(-x), etc.
See github.com/un-ts/eslint... as an example.
#TIL It finally happens! @MacHomebrew's Parallel downloading feature has already landed and can be enabled right now with the environment variable "HOMEBREW_DOWNLOAD_CONCURRENCY={int}". This will be enabled by default in the future.
See GitHub Issue github.com/Homebrew/bre... for more.
ๅจ Fediverse ๅ่บซ่ฟ่ก็บฆไธๅนดๅๅ๏ผๆๅฐๅจ Bluesky ไธ็ๅ่บซๅผๅงๆต่ฏ่ฟ่กใๅไฝ Bluesky ็คพไบคๅนณๅฐ็็จๆทๅฐๅฏไปฅๅจๅนณๅฐไธ็ดๆฅ่ฎข้
ๆฌๅฐๆดๆฐใ
ๆไปฌ็ๅธๅทๆฏ๏ผ @thecascading.bsky.social
ๆฌข่ฟๅ้ฆ้ๅฐ็้ฎ้ขๅๅฏน้ข้็ๅปบ่ฎฎใ
#today
fxtwitter.com/tencentcloud...
The notorious copypastor Tencent Cloud grabs all articles from my blog and posts them on their website without my permission, yet they want me to promote their tools in my blog.
Go to hell, Tencent and Tencent Cloud.
Now, who needs to be sacked for the cost efficiency of all~
It still shocks me that no one has #RIIR the homebrew yet. The slowest package/dependency manager/tool these days (no parallel casks downloading, no multi-threads downloading, and no parallel attestation verification).
So @pnpm.io's onlyBuiltDependencies feature is flawed by default: you don't re-approve to update dependencies.
Let's say you use @rspack.dev and add "rspack/core" to the list, what happens if rspack is compromised and releases a malicious version? It is still "trusted" by pnpm.
Oracle justified its JavaScript trademark by claiming Node.js โ now it wants that ignored
#FreeJavaScript
deno.com/blog/deno-v-...
v8.dev/blog/spread-...
I am pretty sure this is "against" spec anyway.
Others' vacation plans: traveling, eating, meeting friends...
My vacation plan:
I don't care about ops or percent. As long as destructure is consistently slower, it is slower.
It makes sense why array index access is way faster: destructure requires extra overhead from the iterator protocol, while array index access doesn't.
ๆทๆ v8 ๆฒก็จ๏ผ่ SpiderMonkey ๆฉๅฐฑๆ็ไบใๆไปฅๅช่ฝๆทๆ React Compiler ไบใ
It still shocks me that JavaScript runtime nowadays still does not optimize array destructure access.
This means `let [v, setV] = useState('')` is way slower than `let t = useState['']; let b = t[0]; let setV = t[1]`).
So it's React Compiler's turn: github.com/reactwg/reac...
I must admit, GitHub Actions's new hosted arm64 runner (currently in public beta) is FAST, about 100% faster than the amd64 ones. Though there are some issues, one of them is EACCES: github.com/actions/part...