> They chose to use a react rendering to native TUI renderer, which was a source of a lot of performance issues.
That's such a stupid engineering choice that it really makes one question if the people working at Anthropic have any software engineering ability at all. There's no excuse for running React in a freaking TUI.
Which is equally terrible and has earned them every single rendering engineer in the world taking the piss out of them when they proudly announced it was as complicated as rendering a video game.
Do these hacks make bun less secure than other runtimes? I find it a little hard to believe you can get much more robust and performant than V8 or SpiderMonkey without cutting some corners that notably went uncut by either for all these years.
Bun uses JavaScriptCore, which is Safari’s JS engine, for the actual interpreter portion of its runtime.
Which makes the parent comment’s “Bun performance hacks and optimizations” sound a little far-fetched, at least in this scenario I don’t think that’s gonna be the deciding factor. Their vendored JSC is also not touched by this port-rewrite at all whatsoever (still Cpp), so I’m not sure if it’s even possible to hack-improve all that much there.
yes, especially compared to deno bun does not have proper isolation or permissions at runtime layer which is why anthropic tries to fix the lack by a mixture of app layer (build into claude code) and os layer (srt) however using runtime permissions would allow much better security if done right.
Yes, but it’s slower on non-bun runtimes. Nowadays, I believe they bundle bun with CC
They chose to use a react rendering to native TUI renderer, which was a source of a lot of performance issues.
AFAIK, they have written a new renderer.
> They chose to use a react rendering to native TUI renderer, which was a source of a lot of performance issues.
That's such a stupid engineering choice that it really makes one question if the people working at Anthropic have any software engineering ability at all. There's no excuse for running React in a freaking TUI.
>AFAIK, they have written a new renderer.
Which is equally terrible and has earned them every single rendering engineer in the world taking the piss out of them when they proudly announced it was as complicated as rendering a video game.
because their js code is so bad and slow that they need the bun performance hacks and optimisations.
Do these hacks make bun less secure than other runtimes? I find it a little hard to believe you can get much more robust and performant than V8 or SpiderMonkey without cutting some corners that notably went uncut by either for all these years.
Bun uses JavaScriptCore, which is Safari’s JS engine, for the actual interpreter portion of its runtime.
Which makes the parent comment’s “Bun performance hacks and optimizations” sound a little far-fetched, at least in this scenario I don’t think that’s gonna be the deciding factor. Their vendored JSC is also not touched by this port-rewrite at all whatsoever (still Cpp), so I’m not sure if it’s even possible to hack-improve all that much there.
yes, especially compared to deno bun does not have proper isolation or permissions at runtime layer which is why anthropic tries to fix the lack by a mixture of app layer (build into claude code) and os layer (srt) however using runtime permissions would allow much better security if done right.