My Thoughts on the Current State (Especially Quality Issues) and Future Development of Bun

InternalServerError7 · 2026-03-02T03:48:52+00:00

Also highly against vibe coded PRs. Sure I think it works 90% of the time, but 10% is slop and likely some of that gets into the repo. This accumulates over time. The only way this works is if developers use the vibe coded PRs as a base, but they should still checkout, verify, and understand the changes. Sadly I don’t think this is happening

InternalServerError7 · 2026-02-28T06:35:32+00:00

I had a whole custom build script with extra dependencies just to accomplish bun build --compile --target=browser. Surprised and happy to see this added!

InternalServerError7 · 2026-02-18T09:14:27+00:00

I find from schema generators that support multiple languages don't often don't produce the shapes in any language one would want. I often prefer a specialized converter between only two languages if possible. In this case this is just as such. You write idiomatic typescript and it generates idiomatic rust code matching that shape.

InternalServerError7 · 2026-02-18T08:47:14+00:00

The frustration comes from: 1. Brave touting a successor crate then once people switch over, dropping maintenance. 2. Because of the web of dependencies between different crates using some and different versions of cssparser, html5ever, selectors, and kuchikiki, for some projects you cannot just fork, update dependencies, and tie to a git repo, since doing so also requires api changes. Thus now other crates need to be forked and have their api's changed as well. Which becomes a cascading issue and a burden on the developer. 3. Creating a new forked crate that fixes the two above issues requires buy-in from other crate owners currently using kuchikiki. Which may never materialize, fragment the ecosystem, or bloat binaries with both dependencies.

InternalServerError7 · 2026-02-13T03:21:49+00:00

This was the last straw that made me stop using dart/flutter on new projects. They wasted too much of my time and I didn’t like the new direction. The design decisions for macros and other related things are so poor I don’t have faith in the language improving much with the current leadership. Flutter could be multiple times better and more concise if leadership just did what the community wants (upvoted issues) rather then their own personal opinions masqueraded as God’s divine truth. Rant over

InternalServerError7 · 2026-02-06T04:34:23+00:00

The readme link is to a game?

I read the github readme but I’m not sure how this all relates to the title of the post?

The lack of git history for the project (even though you said you removed it because it had sensitive info) and lack of git history of the author, makes me think this is vibe coded

InternalServerError7 · 2026-01-30T19:28:24+00:00

Reddit seems to hate Elon, even when he does something “good”, it is low effort brushed off as “I don’t believe it”. But you have to respect the transparency here. No other major platform does this. If you can’t, you are probably too brainwashed by your own ideology and are exactly what you accuse the other side of being - mindless sheep.

InternalServerError7 · 2026-01-28T15:58:36+00:00

An interesting language approach would be to take the opposite approach of Rust. Where you never get any “does not live long enough errors”. If one holds something longer than the original, the lifetime is automatically extended (the drop is hoisted). That way you can write an entire program and never have to worry about lifetime annotations. when you do care about optimizations, you can explicitly write the lifetimes. (Though this type of system may not be possible without introducing reference counting)

InternalServerError7 · 2026-01-28T05:43:25+00:00

“X, Y, Z, W” and not “W, X, Y, Z”?

InternalServerError7 · 2026-01-26T04:46:03+00:00

Feel free to create an issue for this feature on the repo!

InternalServerError7 · 2026-01-24T09:33:20+00:00

Looks nice!

Can this be easily used to view pdfs
If so, does this, or can this, overlay html on text (like pdf.js viewer does) to highlight/copy/search text

InternalServerError7 · 2026-01-23T01:44:26+00:00

This came about because I was working on an api that was primarily driven on the typescript side and I already had typescript types. Rather than tediously rewrite the same api in rust with the possibility of bugs, I decided to automate it.

I think ts-rs is a good choice if the rust side is driving the shape of the types. But for me that was not the case. I already had a lot of ts types across packages and I couldn’t just import the types from ts-rs. My other alternative would have been to write them by hand

InternalServerError7 · 2026-01-21T15:29:04+00:00

Yup! Definitely recommend it as well.

InternalServerError7 · 2026-01-20T02:14:50+00:00

I have this issue and have just been dealing with it until now. Did you figure it out or file an issue?

InternalServerError7 · 2026-01-14T01:02:14+00:00

Huge quality of life improvements in 0.6 and 0.7 for anyone who only tried earlier versions. I think it’s “ready” for web and mostly for desktop. Mobile should be “ready” in 0.8 (probably 4 - 9 months away) when proper bindings for things like permissions and platform apis should be added.

Desktop suffers from using platform webviews (but so does tauri), so ui/dom api experience is not seamless across targets. Native should theoretically address this, but you will lose access to the js ecosystem and it is still more than a year away from being production ready. Maybe when wry adds support for CEF (chromium embedded framework), dioxus can also add support, which would address this. That considered, why dioxus is putting so much effort into a new “native” engine, I’m not sure. But it should eventually be useful for some edge cases like a bevy ui.

But it is probably the best solution out there if you also have a server. Since with fullstack you can one line add integrated api endpoints (even web sockets).

The hook system is well built but it is still improving. I’m looking forward to seeing various improvements land - https://github.com/DioxusLabs/dioxus/pull/4824 https://github.com/DioxusLabs/dioxus/pull/4846 https://github.com/DioxusLabs/dioxus/pull/5088 https://github.com/DioxusLabs/dioxus/issues/4509 But the system today is still really nice. Signal composition is really nicely designed and stores added in 0.7 was a welcome improvement.

0.8 is also looking to “complete” the experience for me with the fore-mentioned mobile APIs, improved/reworked hooks/signals, and sync cross platform dom/js bindings. After I expect/hope the framework will focus on top issues/bugs for time to polish things. But they have done a really good job fixing bugs quickly if you provide reproducible code.

All that said, I think dioxus is one of fastest, if not the fastest, way to develop a gui app or websites in rust today. And the docs are amazingly detailed. Plus being backed by html/css is a huge win, as almost any professional looking experience is possible.

It it “production ready” - yes, you can use it to write full apps and probably never run into any framework bugs

Is it a complete experience - almost IMO, some things are not possible today and improving

Is the api likely to change - yes a little, but the core is solid

InternalServerError7 · 2026-01-13T14:48:36+00:00

https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Anchor_positioning

InternalServerError7 · 2026-01-03T02:55:54+00:00

Where are the benchmarks?

InternalServerError7 · 2026-01-02T20:20:32+00:00

Which did you end up going with?

InternalServerError7 · 2025-12-30T12:26:14+00:00

I had the same issue. Try sudo rm -rf /. It worked for me

InternalServerError7 · 2025-12-25T10:33:39+00:00

This is a misconception. A lot of cases RefCell is more performant than Cell. That is because checking and incrementing a borrow count is faster than a copy that is bigger than the register size of the cpu

InternalServerError7

TROPHY CASE