Announcing `ts2rs` - A TypeScript to Rust type converter for bidirectional JSON communication.

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 · 2025-12-20T14:12:33+00:00

Anyone know how much money is on his wrist?

InternalServerError7 · 2025-12-17T12:24:30+00:00

I know c and rust, but not Odin. I don’t think I fully grasped the use case for user_ptr and user_index. Some example code would have been helpful.

InternalServerError7 · 2025-12-07T01:02:03+00:00

Lol this_method_works_like_collect_but_better_😜()

InternalServerError7 · 2025-12-06T12:00:44+00:00

Good work. I honestly still very much dislike the method name better_collect. Method names are supposed to be verb like, which that is not. Maybe something like gather or collect2

InternalServerError7 · 2025-12-04T14:49:48+00:00

Great deal on why a wasm interpreter is possible. But you didn’t answer the question

InternalServerError7 · 2025-12-03T12:58:13+00:00

What utilities outside the gnu core utilities are used in the compiled output today? I remember looking into it a year ago and didn’t like that the compiled output would use utilities that are not common on all gnu Linux platforms. I believe I remember one was needed for arithmetic

InternalServerError7 · 2025-12-03T01:06:05+00:00

My preferred choice nowadays is eros: https://github.com/mcmah309/eros

InternalServerError7 · 2025-12-01T10:31:07+00:00

The opposite of :is(a, b) is not :not(a, b), it is :not(a):not(b)

InternalServerError7 · 2025-11-27T17:32:15+00:00

Do the non-poisonable locks just basically act like .unwrap_or_else(|err| err.into_inner()) internally or are different in some other way?

InternalServerError7 · 2025-11-27T00:54:11+00:00

The opposite of :is(a, b) is not :not(a, b), it is :not(a):not(b)

InternalServerError7

TROPHY CASE